It turns out the answer for that question is not as easy as you may think. It absolutely depends on the Hyper-V environment you have. Shared storage, failover cluster, Windows Server version number — everything should be taken into consideration. The combination of those factors can be tricky, but it’s essential and the only way to find out the truth. Let’s have a quick look at some options.
Yes, it’s not a live migration of the Hyper-V VM, however, it’s something that is included in all versions of Hyper-V from the very beginning and something that can get things done no matter what. The functionality is pretty simple, you can right-click on the VM (it can even be running) in Hyper-V manager, select “export VM,” choose the folder where you’d like to export and Hyper-V manager will perform the operation for you. Then you should simply copy VM files to another site and make a “VM import” there by using a special wizard. This method, however, will require some downtime, so it can’t be named “live,” so we should try something more advanced such as failover cluster.
Failover cluster for Windows Server 2008 R2
Failover cluster is a set of computers which are working together in order to provide the system with some redundancy while ensuring high availability of system resources. Servers (nodes) are connected by physical cables and managed by failover cluster software. When one node becomes unavailable, the rest are taking charge of it and begin to provide services themselves. Sounds good, right?
Nevertheless, Failover Cluster in Windows Server 2008 R2 requires shared storage, some steps for pre-configuration of the systems and setting VMs to “high available.”
Shared storage, however, is somewhat not being presented for every virtual environment. And even you have it, you might not want to spend time playing around with servers and settings. And reconfiguration can certainly be difficult in some cases.
Failover cluster for Windows Server 2012(R2)
With Windows Server 2012 (R2), Microsoft introduced new rules toward VM live migration and invented the “shared nothing” feature which at the end doesn’t require you to have a shared storage. But there are still some requirements:
- Similar processor family among servers
- Servers must be a part of the same domain or be part of separate domains that have established trust between domains
- VMs cannot use physical disks, but Virtual hard disks or Virtual fibre channel disks
- And other requirements
If you meet the requirements and know how to configure settings, this is a very reliable way to go. I recommend it.
Using Veeam Replication
All previous operations have something in common. They require some sort of reconfiguration of the system and might not possible because of missed requirements or lack of time. Should you be worried in this case? Absolutely not! Third party software such as Veeam Backup & Replication works here perfectly.
Migration of a Hyper-V VM with Veeam is an asynchronous process and, moreover, isn’t literally “live.” However, it has flexibility and doesn’t require much preparation. In order to migrate a VM with Veeam, we need to make the replication of the VM first. Create a Replication Job task, pick a VM, select the target host, provide the administrators’ credentials for VSS-aware transactional consistent copy and run the job. Once it’s done, you will have an idle replica VM on the remote host which you can now failover to.
Failover is a specially designed process of migrating from the original VM on the source host to its VM replica on the target host.
During failover, Veeam Backup & Replication powers on a fully functional VM with a specific restore point on the remote host. As a result, you’ll have your VM up and running within a couple of minutes with minimum disruption for the system.
To perform failover for a particular VM, you should launch failover wizard from Veeam console, select a VM and restore point and apply changes by clicking finish. Veeam Backup & Replication will take a protective snapshot on the VM replica, then power it on and provide it for your use.
As a result of failover, the state of the replica in Veeam GUI is changed from “Normal” to “Failover.”
In Veeam Backup & Replication, the actual failover is considered a temporary stage that should be further finalized or discarded. In our scenario, after you test the VM replica and make sure the VM runs stable, you should apply a permanent failover to confirm changes.
This is the step to confirm that everything is going smooth and you’d like to leave replica and operate in full mode on the new host. VM replica no longer exists as a replica and takes over the role of the original VM.
When you decide to do that, Veeam Backup & Replication removes the replica restore points from the list of replicas in the console, cleans up all associated files, deletes the protective failover snapshot in order to unlock the original disk files and commit the changes within the next VM reboot.
As a result of the operation, you will get a VM migrated to another host without any issues.
Hint: If you want to automate migrate operation and run everything by PowerShell scripts, check the following article.
Don’t forget to make backups of your VMs before any operations you perform with them and no matter which way of live migration you decide to choose.