Migrate database from Hyper-V to VMware
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
We're looking at 1 TB of data including the database and all of the transaction logs.
1TB of data or 1TB of transaction logs? Your transaction logs should be tiny if you schedule this after a backup.
1 TB of data. A little bit more than 500 GB of transaction logs on the database.
So that is 1.5 TB to transfer. also WTF on 500 GB of transaction logs. What kinds of rollbacks are you trying to be able to handle.
They are merged into the database nightly. This systems manages everything between our accounting, to customer service, to raw materials, to boxing and shipping.
-
@nerdydad said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
We're looking at 1 TB of data including the database and all of the transaction logs.
1TB of data or 1TB of transaction logs? Your transaction logs should be tiny if you schedule this after a backup.
1 TB of data. A little bit more than 500 GB of transaction logs on the database.
So that is 1.5 TB to transfer. also WTF on 500 GB of transaction logs. What kinds of rollbacks are you trying to be able to handle.
They are merged into the database nightly. This systems manages everything between our accounting, to customer service, to raw materials, to boxing and shipping.
So if you schedule your downtime for post merge, then you only have 1TB to move.
-
As for how to do this.
I would simply schedule extended downtime after backups run, shut down the database access and migrate the backup file.
Obviously, this would be done after simply spinning up the new system with a backup file and confirming any other steps that you need to take.
You have no HA now, why try to implement some half baked HA just to migrate?
-
Could you restore the backup on the new server whilst the old server is still live and after it is restored on the new server shut down live and do a differential backup and then restore the differential backup on the new server?
That would minimise downtime as the differential backup will be much smaller than the full 1TB backup. Although with 500gb of transaction logs, maybe not so much.
-
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.
-
@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.
