Problem solve Get help with specific problems with your technologies, process and projects.

Windows Server 2012 Hyper-V missing features and potential fixes

Windows Server 2012 Hyper-V is chock full of new features, but there are some glaring omissions. Luckily, for Microsoft, we’ve provided the fixes.

For all the new features and enhancements to Windows Server 2012 Hyper-V, the virtualization platform still has...

its shortcomings.

More on Windows Server 2012 Hyper-V

Top five Hyper-V 3.0 features that will excite IT pros

Hyper-V 3.0 virtual RAM: Massive memory allocation has its faults

Shedding light on Hyper-V 3.0 resource monitoring

Having worked with Hyper-V since the early betas, I appreciate the speed at which Microsoft adds new features. With each Hyper-V release, however, I still see a few areas of improvement that could add key functionality and ease administration. Below, I look at three of these shortcomings in Windows Server 2012 Hyper-V and offer some practical fixes.

1. Poor Quick Migration between hosts with different processor architectures

It’s possible to migrate virtual machines (VMs) between Windows Server 2012 Hyper-V hosts with different processor types, as long as they are within the same family (e.g., Intel to Intel or AMD to AMD). But it’s not possible to move VMs between processor vendors without first shutting down the VM and moving it to the alternate host. The problem is, if a VM has a large Virtual Hard Disk, the amount of downtime can be lengthy, as it’s moved to the new Windows Server 2012 Hyper-V host.

How should it work?
For Windows workloads, I understand there needs to be some recognition of the new processor architecture, so a reboot or two may be necessary. But the method below would potentially cut the downtime from hours to minutes.

    1. I foresee Microsoft using the same method of Live Migration between Windows Server 2012 Hyper-V hosts or a similar process to that of Quick Storage Migration in Windows Server 2008 R2 SP1, which takes a Hyper-V VSS Writer snapshot of the VM and moves the data to the alternate host, while the source VM is still running.
    2. Once the data is moved, the new VM restarts offline, allowing for the VM to recognize the processor architecture, then shuts down.
    3. Next, the source VM shuts down, and a final Hyper-V VSS Writer snapshot is taken. Any remaining changes are transitioned over, and the VM on the destination host is restarted and brought online.

The process is very similar to a physical-to-virtual migration, where you keep an Intel or AMD architecture host online and migrate it to a virtual host with a different processor.

Benefits of this method
This process would be good for migrating large VMs between hosts, because large VHD/VHDX files can take a long time to move. It would also benefit low-bandwidth environments, because the source VM would stay online during the migration.

2. Inadequate Live/Quick Migration of VMs between different Hyper-V versions

Hyper-V’s rapidly evolving features have kept up with the needs of modern application resource requirements. But this fast pace also creates a constant need to migrate hosts and VMs to the latest Hyper-V version.

In most cases, this process requires a shutdown of the VMs. Then, you must migrate them offline to the updated host and install the new Integration Components.

How should it work?
Similarly to the above scenario, migrating VMs between Hyper-V versions probably necessitates a reboot to install new Integration Components. But extended downtime should not be part of the process. Below is how I see it working in the future.

  1. Hyper-V performs a Hyper-V VSS Writer-assisted snapshot and moves the data from the source VM, while it is still running, until all data is moved to the new host;
  2. It then automatically starts the new destination VM offline (the virtual NIC is not connected) and installs Integration Components; then
  3. Shuts down the source VM once the first pass of data is moved to the destination host;
  4. Moves the remaining changes from the source VM to the destination VM, so both virtual machines are synchronized; and finally
  5. Restarts the destination VM.

Benefits of this method
The source VM remains online until all data is moved to the new host. At the same time, this method reduces downtime and any strain that causes.

3. Imperfect hot-add memory allocation with a running VM

It should come to no surprise that, over the years, server workloads have consumed more resources, including disk space, CPU and RAM. Microsoft added a hot-add disk capability to Hyper-V in Windows Server 2008 R2, and hot-add memory is now supported in Windows Server 2012 Hyper-V, as long as the VM utilizes Dynamic Memory. But it is still not possible to hot-add memory if the VM uses a statically assigned or fixed-memory allocation.

By only enabling hot-add memory for VMs that utilize Dynamic Memory, Microsoft misses workloads that would most likely need an uninterrupted memory increase such as databases or even Java-based applications. The latter are not recommended for use with or supported by Dynamic Memory, because they use memory resources fully and cannot call for more memory from the dynamic range set for the VM.

Workloads that are memory hungry are usually configured with a fixed amount, and they are just the ones that could use more memory on the fly, without interruption. For those reasons, I still think the addition of hot-add memory is incomplete and only partly reduces the administrative burden for IT pros.

How should it work?
Using the capabilities already in Windows Server, Microsoft should include the ability to adjust the memory maximums for fixed-memory allocations.

The results of this fix
This capability would eliminate another manual process that incurs downtime. It would also allow for more automated remediation processes (with the use of System Center Operations Manager), which would accommodate the periodic need for memory-hungry workloads to receive additional resources. Finally, it would meet the needs of workloads with unpredictable memory requirements, such as databases, that are the most sensitive to downtime.

Don’t get me wrong: Windows Server 2012 Hyper-V includes some excellent additions. But, with every release, there are bound to be a few features that miss the cut. The options above would dramatically reduce migration and administrative time, but they are unfortunately not available…yet.

This was last published in June 2012

Dig Deeper on Introduction to virtualization and how-tos



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Are these Windows Server 2012 Hyper-V shortcoming a deal breaker?
The Windows platform provides the best integration for an All Microsoft shop and has the best technical support accross the board.
I am very encouraged by the advances MS has made. Because of these advances, we have based our Enterprise IT strategy on MS instead of VM Ware
It is strange that virtualized servers are so sensitive to CPU hardware architecture.

I think that the 2nd and 3rd points should have been included by now.
vSphere can do any of these things either in it's latest version so even though they are great suggestions for improving the product in future releases or service packs I'm not sure why this would be a deal breaker.
Each of these seems more like checklist items in the VMWare race than practical items needed by most admins on a day-to-day basis. Support for more cores per host, more virtual CPU's per guest, and more guests per host are the big hits in the upgrade.
Techtarget has outdone themselves. One of the worst articles ever written. I'm not sure if someone has an ax to grind, if VMware just paid them off or both, but the bias is obvious. There are so many great new features in hyper-v 3 (been testing at my company since beta) live migration over Ethernet, storage migration, huge vms (cpu, memory, disk) and the new vswitch. You guys are just way off.
Processor compatibility was included in Hyper-V R2 - before Hyper-V 2012.
don't want to
All good :D
The article was "Much ado about nothing"
I love VMWARE especially VMWORKSTATION 8, the big difference for us is we spend $600,000 a year on VMWARE licenseing and not a penny on Hyper-V. We have a mixed enviroment, but we will be moving to Hyper-V over the next serveral years to save money.
It has been a long evolution, but it could happen in the R2 release if the demand is there from the user population
Title is misleading somewhat. These are not day to day shortcomings. A more accurate title would be migration shortcomings.
For me I am using Hyper-V as my only server virtualization solution and will continue to assess VmWare but cost and learning curve may make me slow to change
I don't believe these shortcomings are that significant.
We are moving towards Xen and Linux for web servers.
Im not really into hyper-v but honestly these are not really that significant, and to the person who is shedding $650,000 per year for vmware, why are you spending that much? for support?, or are you spending that much on vmware workstation? that is really impractical IMHO
Get real
A system administrator would love to have this freature at hand.
at whose cost to fix this problem
So many years behind...
HyperV is just not up to the same level that VMware can suply.
Virtual machines are still light-years in front of the old physical server problems we used to deal with. This hypervisor is really only a couple of years behind VMWare and is free: hard to beat.
Why MSFT when VMware has long-since solved these issues and are the clear visionary and market leader? A superior product and superior company.
To many unknown issues.
For small and medium companies - definitely no...
Not a deal breaker
What idiot really uses hyper-v anyways?