Migrate database from Hyper-V to VMware
-
@iroal said in Migrate database from Hyper-V to VMware:
Last year I moved a Vm from HyperV to Vmware, It had Sql Server with a database of 300Gb, for Ms Ax.
I just stopped all Ms Sql Server services and migrated using VMware Standalone Converter.
After the migration I started all Sql services again and everything worked.
This is just a normal V2V conversion. Which many of us have already discussed, but it adds to what would need to be converted.
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
Yes it's simpler, just convert the entire block device, but it adds a some risk that there could be a broken system within whatever gets converted and started up.
-
Not to mention the amount of downtime required to convert the working system to the VMWare standard. Which may not be acceptable for the business.
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Not to mention the amount of downtime required to convert the working system to the VMWare standard. Which may not be acceptable for the business.
This downtime will, likely, not be particularly different than the offline time to backup, transfer, and restore a 1TB database.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Not to mention the amount of downtime required to convert the working system to the VMWare standard. Which may not be acceptable for the business.
This downtime will, likely, not be particularly different than the offline time to backup, transfer, and restore a 1TB database.
I was simply accounting for the OS size as an additional amount rather than creating a new system with a SQL system ready to receive a database.
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Actually, no. Because these types of things are usually, setup once 5 years ago with vendor support, type scenarios.
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
It is a V2V, nothing is happening in production.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Actually, no. Because these types of things are usually, setup once 5 years ago with vendor support, type scenarios.
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
It is a V2V, nothing is happening in production.
I like to lean on the "you have support for your production systems, right?!" argument. . . .
And it would be production if it was powered on and running for a while with entries being written etc that are no longer on the hyper-v installation.
I've seen weirdness (Hyper-v 2008 specifically) that VM's migrated had a lot of remanent hyper-v drivers and registry entries that have caused issues.
Are you saying you've not seen these?
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Hyper-v 2008 specifically
Um hi ancient history...
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Actually, no. Because these types of things are usually, setup once 5 years ago with vendor support, type scenarios.
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
It is a V2V, nothing is happening in production.
I like to lean on the "you have support for your production systems, right?!" argument. . . .
And it would be production if it was powered on and running for a while with entries being written etc that are no longer on the hyper-v installation.
I've seen weirdness (Hyper-v 2008 specifically) that VM's migrated had a lot of remanent hyper-v drivers and registry entries that have caused issues.
Are you saying you've not seen these?
Hyper-V 2008 was a horrible platform. Everyone knows it.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Hyper-v 2008 specifically
Um hi ancient history...
Yea, but we can't say for certain he doesn't have an old hypervisor, nor the potential for weird bugs either during a conversion process.
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Hyper-v 2008 specifically
Um hi ancient history...
Yea, but we can't say for certain he doesn't have an old hypervisor,
You have a comprehension problem.
@nerdydad said in Migrate database from Hyper-V to VMware:
We are going from Hyper-V 2012 to VMware vSphere 6.5U2
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Actually, no. Because these types of things are usually, setup once 5 years ago with vendor support, type scenarios.
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
It is a V2V, nothing is happening in production.
I like to lean on the "you have support for your production systems, right?!" argument. . . .
And it would be production if it was powered on and running for a while with entries being written etc that are no longer on the hyper-v installation.
I've seen weirdness (Hyper-v 2008 specifically) that VM's migrated had a lot of remanent hyper-v drivers and registry entries that have caused issues.
Are you saying you've not seen these?
Hyper-V 2008 was a horrible platform. Everyone knows it.
Yeah, that was almost unusable.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Actually, no. Because these types of things are usually, setup once 5 years ago with vendor support, type scenarios.
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
It is a V2V, nothing is happening in production.
I like to lean on the "you have support for your production systems, right?!" argument. . . .
And it would be production if it was powered on and running for a while with entries being written etc that are no longer on the hyper-v installation.
I've seen weirdness (Hyper-v 2008 specifically) that VM's migrated had a lot of remanent hyper-v drivers and registry entries that have caused issues.
Are you saying you've not seen these?
Hyper-V 2008 was a horrible platform. Everyone knows it.
LOL I read this line in my favorite Donald Trump voice.
-
@zachary715 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Actually, no. Because these types of things are usually, setup once 5 years ago with vendor support, type scenarios.
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
It is a V2V, nothing is happening in production.
I like to lean on the "you have support for your production systems, right?!" argument. . . .
And it would be production if it was powered on and running for a while with entries being written etc that are no longer on the hyper-v installation.
I've seen weirdness (Hyper-v 2008 specifically) that VM's migrated had a lot of remanent hyper-v drivers and registry entries that have caused issues.
Are you saying you've not seen these?
Hyper-V 2008 was a horrible platform. Everyone knows it.
LOL I read this line in my favorite Donald Trump voice.
That makes it so much better.
