moving VM across sites (another vcenter)

[yloon]

Hi Guys,

I have been reading around moving VM across esxi host or vcenter.

ultimately there are 2 ways we can do it, either we scp it or we use the method of OVA / OVF to export, copy then deploy.

SCP will definitely work but it moves the thick drive instead of the thin drive.

I am having 2 TB thick disks with the used of 400GB of used diskspace.

I going to move the production server with database in there.

so my question are:

1) Is the database will continue to work if we use OVA/OVF method?

2) Anybody tried OVA method on Sybase, MS SQL servers?

[julienvarela]

hi,

1) Is the database will continue to work if we use OVA/OVF method?

Yes ovf , is just a transport method. So your VM will be exported to an ovf format. And then , you will reimport it on your vCenter. But don't worry, nothing is changed on your Guest OS. So your VM will start again without issue.

2) Anybody tried OVA method on Sybase, MS SQL servers?

I already used this method with a VM that contained a SQL DB, no issue, because for create a OVF , you need to poweroff the VM. So when i have re-imported the VM , my DB was consistency.

Regards,

Julien

[prabuvmware]

As Julien said, its a transport method. It depends on your network bandwidth, copying the huge data over the network...

In general, copying huge OVF data is not recommended.

[TomHowarth]

another advantage of OVF is that it is device agnostic, if you your sites are only connected by slow links, you can move the ovf to a disk or DVD (if small) and Currier them to your new site.

[ScreamingSilenc]

Use esxReplicator from Vizioncore and check link for supported features

Vizioncore, Inc. Announces esxReplicator for VMware ESX Server : VMblog.com - Virtualization News and Information for Ev…

[yloon]

Hi Julien/prabu,

can you comment the new imported VM will have a new SID or existing SID?

do we need to re-join domain for the imported VM from OVF?

[julienvarela]

Hi,

Your VM will be exported thats all, no modification will be apply to your VM. So no need to re-join or anything else. It is exactly the same. The VM will not see a difference :smileyhappy:.

Regards,

Julien.

[TomHowarth]

Agreed, however this is a costed option and most likely needs a level of knowledge and infrastructure to get it going

[ch1ta]

Another way to go is to utilize Veeam Free. With it, you can either use Quick Migration or VeeamZIP functionality.

Veeam Quick Migration allows prompt VM migration between ESX(i) hosts/cluster, datastores or both. It allows migration of VMs in any state with a minimum disruption to
business operations and end user access to services. Using this feature you will be able to migrate required VM from one site to the other.

As to VeeamZIP, in a nutshell, it’s zip utility for Virtual Machines that might be especially useful when you are after one time backup. VeeamZIP is similar to full VM
backup. Nevertheless, when you perform backup with VeeamZIP, there is no need to configure a backup job and schedule it; instead, the backup process for
selected VMs can be started immediately. Minimum settings are required during this type of backup: backup destination, compression level and enabling or disabling guest quiescing.

So, you can VeeamZIP given VM first and then restore it to whatever location you’re willing to.

Cheers.

[jgover]

I am performing this task now (old hardware and  vCenter 5.x to new hardware and vCenter 6.5) as there is a old license vSphere Scheme "Essentials" that I have to cold migrate VMs to vSphere "Standard"

- I am comparing VMware Stand Alone Convert performance to Veeam Quick Migration.

- I just noticed that Veeam Quick migration automatically does "thin" to destination.

- VM Converter you have to set it on the job queue as you create it.

- Currently VM Converter is winning in the speed of the migration.

-- Converter: 14:37 minutes to convert 20GB Think to reult of 5.5GB thin.

-- Veeam Quick Migration : 44:06 minutes; although the compression ratio ended up better with the VM as 1.4GB thin

The original estimates from Converter are out of whach as it stated that it would take 5 hours plus; this quickly tapered off during migration.

Jeff