- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Speedy Live Migration (LM)
The process of copying the memory of a running VM from one host to another whilst tracking the changes to the memory of the running VM and continuing to copy those changes as well is a network intensive operation, especially for large VMs with lots of memory or those with a lot of changes. The new Hyper-V now offers two options to speed up the process. The first is LM compression which monitors each host for CPU load and if there’s sufficient spare capacity available the data stream is compressed on the source host and decompressed on the destination host, effectively trading some CPU overhead for less bandwidth requirement.
If on the other hand you have RDMA (Remote Direct Memory Access) network cards these can now be used for LM traffic for phenomenal LM performance. In testing the Hyper-V team found that one, two and three 56 Gbps RDMA NIC provided linear performance increases, whereas the fourth didn’t provide for faster LMs. The bottleneck turned out to be the bandwidth of the DDR3 host RAM!
Microsoft recommends that if you have less than 10 Gbps bandwidth you should use compression and if you have more than 10 Gbps, RDMA transfers would be more appropriate.
To truly unlock the potential of a dynamic datacenter with VMs moving from host to host with ease the new compression and RDMA options for Live Migration provide superior performance.
Building on the exceptional support for Linux VMs running on Windows Azure (which runs on Windows Server 2012 Hyper-V), 2012 R2 provides full dynamic memory support for Linux VMs, the ability to resize VHDX files while the VM is running (just as for a Windows VM), full VSS support for online backup of VMs and a new video driver for an enhanced GUI experience. The backup piece is particularly attractive and provides a good backup experience for Linux VMs, compared to the common approach which is a script to copy critical files to another drive on a scheduled basis.
This fantastic feature for cost effective Disaster Recovery was added in 2012 with some limitations, each VM could only be replicated from a primary to a secondary host and the frequency of replication was fixed at five minutes.
In 2012 R2 the replication can be multistep, from one end of the datacenter to another and then a third replica could be housed in an offsite location. The replication frequency now has three settings, every 30 seconds for situations where you have plenty of bandwidth available (within the same data center), the normal five minutes and the extreme 15 minutes for when you are on the other side of a slow and unreliable WAN link. The automatic injection of new IP addresses on the replica side in case the replica VM needs to be activated used to only work for Windows Server 2012 guests, now Linux VMs are catered for as well.
You can now resize a VHDX file while the VM is running, both making it larger and smaller (not beyond what’s needed for the data storage of course). This can be done for Gen1 VMs on data disks but not the boot virtual disk, with Gen 2 VMs the boot disk can also be resized.
The VHDX format has also been improved, it can now expand up to 10 times faster than the old VHD format could when a dynamic disk needs to grow and this leads to Microsoft for the first time recommending to use dynamic disks, not fixed disks for production deployments.
You can also clone a running VM, which could be very useful if a piece of software inside the VM is malfunctioning but the application is still providing adequate service to end users. Restarting the VM means down time for end users but troubleshooting an application on a production VM might be impossible. This way you can work on a clone and ascertain the root cause and then implement the solution in a predictable manner.
In the next post I will cover VM Storage and Shared VHDX.