Fotolia
Consider Hyper-V live migration requirements before configuration
An effective live migration setup is key to a complete Hyper-V configuration. Consider these expert recommendations, such as limiting concurrent live migrations, to ensure success.
Before configuring a new Hyper-V deployment, IT administrators need to take into account Hyper-V live migration requirements to ensure efficient live migration. Hyper-V host configuration plays a direct role in the speed and efficiency of live migrations.
Individual VM configurations are most important. Hyper-V live migration requirements make it so that admins can't live migrate a VM unless the destination host can accommodate the VM's hardware configuration. For example, a VM configured to use pass-through disks can't be live migrated because the pass-through disks don't exist on the destination host.
Pass-through disks aren't the only hardware component that requires consideration. Other examples include Peripheral Component Interconnect pass-through devices and dedicated GPUs. Of course, virtual hardware also plays a role. The destination host must, for example, contain a virtual switch that has the same name as the virtual switch that the VM is attached to on the source host.
Limit the amount of concurrent Hyper-V live migrations
One of the first Hyper-V live migration requirements is to establish the number of allowed simultaneous live migrations.
Some people dismiss this setting as unimportant because of the way Hyper-V live migrations work. Unless it's a shared-nothing live migration, there are only two things that transfer as part of a live migration: the VM's ownership and its running state. Live migration operations don't require that you transfer the virtual hard disk contents -- except in a shared-nothing live migration -- so some IT pros believe that there is little reason to limit the number of simultaneous live migrations.
Windows Server 2012 R2 Hyper-V live migration
The problem with this belief is that when a Hyper-V live migration transfers a VM's running state, the contents of the VM's memory transfer as a part of that state. Even a modestly sized VM might have several gigabytes of memory provisioned. Conversely, a large Generation 2 VM running on Windows Server 2016 Hyper-V can have up to 12 TB of RAM. Copying 12 TB of data from one server to another is not a trivial operation.
The more memory VMs have, the longer a live migration will take to complete. While several large VMs could live migrate concurrently, this would take a considerable amount of time to complete. As the duration of a live migration operation increases, so too does the chance that the operation will fail.
Hyper-V live migration performance options
Since the introduction of Windows Server 2012 Hyper-V, Microsoft has offered three different performance options for live migrations. These performance options determine how the contents of a VM's memory will move over the network to the destination host during a live migration.
The default performance option is TCP/IP. Using this option essentially tells Hyper-V to transmit the VM's memory to the destination host without making changes to the data or migration method.
The second option is to use compression. With this option, admins can compress the VM's memory contents before transmission to the destination host. This compression reduces the total volume of data that will need to move across the network, which enables faster live migration.
The caveat to this is that compressing a VM's memory contents is a CPU-intensive operation. Typically, this won't be an issue because most Hyper-V hosts have plenty of CPU resources, but if a host is running CPU-intensive workloads -- to the point that the host is CPU-bound -- then using the compression option might not be the best idea.
The third option is the server message block (SMB) option. With this option, admins can send the VM's memory contents to the destination host using SMB Direct. This option usually provides the best performance for Hyper-V live migration, but it's also the most restrictive. This method is only available if the network cards in the source and destination hosts support remote direct memory access.
Some Hyper-V versions also prohibit the network cards from being teamed or bound to a virtual switch. Even so, this Hyper-V live migration requirement is something of a moot point, as it has long been a best practice to use a dedicated network adapter for live migration traffic.
The authentication protocol is the final Hyper-V live migration requirement to examine. Hyper-V provides two choices -- Kerberos and CredSSP. In almost every situation, admins should use Kerberos because it's more secure and because it doesn't require the initiation of the live migration directly from the server's console. If admins choose Kerberos, however, then it will require constrained delegation configuration.
All too often, Hyper-V live migrations are an afterthought. Ideally, admins should plan around Hyper-V live migration requirements and settings before deploying the first host. Even so, admins can configure live migration later on if necessary.
