Migrating a Virtual Machine across vCenter Servers with Veeam Quick Migration

Today, on twitter, someone asked the question “What’s the best way to migrate VM’s from 1 vcenter to another?”.

In this question it is assumed that both vCenters, and related hosts, have IP connectivity between each other and that there is no storage shared between them.

There were a few replies with different suggestions.

One of suggestions was to use OVFtool as described in this article. OVFtool requires that the virtual machine is switched OFF. It will create a copy of the Virtual Machine on the destination host.

Another suggestion was to disconnected the host from the first vCenter server and connect it to the second vCenter server with the VM still associated with the host (i.e running or not). Then perform a Storage and Host vMotion of the VM from the first ESX/i host to another. Although this solution may not cause any downtime, it may not always be possible to do. Initially there could be an issue with licensing. Storage vMotion feature requires at least the vSphere standard license to be licensed. If you have the Essentials or Essentials Plus this would not be possible, without downtime, plus you can only have one instance of vCenter server with this license. If you can allow downtime then you can migrate the VM to a different host and datastore without issues. Another thing is that it is not always possible to release a host from a cluster/datacentre. Availability issues could arise. I must admit that although, with this method, there could be no downtime, it would not be my first preference.

Someone suggested using Veeam Backup and Replication and replicate the VM from one Vcenter to the other. This is a good option but if you are not familiar with the process, it may take some time to understand what it does and how to fail-over from one site to the other. It is not difficult but it needs to be done properly. You would also need a licensed version to do the replication, be it the Free 30 day trial, NFR license for MCP or VCP holders,or a Purchased license.

The option I suggested was to use Veeam B & R and perform a Quick Migration of the Virtual Machine. I like Quick Migration because it is fast, reliable and very straight forward to do. I takes care of moving, or copying, the VM and de-register and delete the source, if specified. It also registers and powers ON the VM at the destination. This method will cause minimal downtime. I cannot quantify this downtime because it depends on the size of the VM and the resource available to the hosts and backup server.

If the CPUs in the source and destination hosts are not compatible, a cold migration is performed, meaning the VM is shut down before registering it on the destination. If they are compatible, the VM will be put in Suspend before registering the VM.

The data moving can be done while the virtual machine is powered ON and the downtime is only required until; the source VM is powered OFF, the VM on the destination host is registered and updated with the latest changes and powered ON.

Quick Migration is available in the Free Edition of Veeam B & R and is able to migrate VMs across standalone Hosts aswell without requiring a vCenter license.

Before suggesting it, I wanted to try it out so I deployed an other instance of vCenter Appliance and a Nested ESXi Host in my environment.

I already had Veeam B & R installed with an NFR license on a VM. So I used that to test. The process in the free edition is very similar

The first thing I did was add the second Vcenter server to the Virtual Machines/Infrastructure/VMware vSphere in Veeam B&R

Specify the hostname/ip address of the vCenter server you would like to add. In my case I already had one added and just needed to add the destination. You may need to add both source and destination if you do not use Veeam.

Once the vCenter server is listed make sure that you can view all the VMs and hosts.

Right click on the VM you wish to Migrate and click on Quick Migration

The Wizard will appear. It will ask you to add more VMs. Once all VMs are added, click Next.

Next Choose the Destination Host, managed by the second vCenter Server, and choose the datastore you would like the VM to be placed in. If you click on “Pick datastore” at the bottom of the window, you can pick and place individual VM disks to different datastores. otherwise all disks will be placed in the same datastore.

In the next screen, Transfer (not shown), you can choose any proxy you would like to handle the migration. I left it on Automatic Selection as I didn’t need to change anything and clicked next.

The Ready screen gives a summary of what is going to happen. It also gives you the option to Delete or Keep the Source VM files. I prefer to keep them and delete them manually once the process is finished and I am satisfied with the result. The Cold Migration Mode indicates that the VM will be switched off, rather then suspended, because of incompatible CPUs. Click Finish

The process will start by creating a snapshot of the source VM. Then a VM is registered on the destination. The name of the VM will be source name plus a random generated GUID.

At this stage the data is being moved.

Tip. If you close the progress window, you can open it from the Backup and Replication Tab, under Last 24hrs/Running

Once the VM is copied a set of tasks are executed, sequentially. The screenshot below gives a clear picture of what is happening.

1. Since it is a cold migration, the source VM is shutdown.
2. Snapshot files are copied to the destination.
3. The Source VM is renamed to <source name> _migrated
4. The destination vm is reconfigured and renamed to the <source name>
5. The snapshots are consolidated and the VM is powered ON.
6. The heart beat is received via VMware tools. Make sure the service starts in the VM, if not start manually. Other wise theMigration may change and everything could be reverted.

The only thing you may need to do is edit the Virtual Machine settings and change the network settings to connect the network card to the proper vSwitch. This is especially required if the vSwitch names do not match.

As you can see the process is smooth and simple. Configuration only took a few minutes without interrupting or changing anything in the infrastructure.

Let me know your views on this process and any other suggestions you may have.