Hyper-V has come a long way since its humble beginnings nearly a decade ago. Although Hyper-V has been improved in almost every way imaginable since its debut in Windows Server 2008, there are some common Hyper-V related issues that continue to affect virtualization administrators. These issues tend to be unrelated to bugs in the hypervisor, and have more to do with the way Hyper-V works. Below, I’ve outlined some of the common issues…
Virtual Machines Are Slow
As someone who has written multiple books about Hyper-V, I receive a lot of emails from readers, asking about various Hyper-V issues. One of the questions I am asked most frequently is why virtual machines run so slowly.
Virtual machine performance problems are almost always related to resource contention. In other words, the host server has limited hardware resources available, and those resources must be shared among the virtual machines and by the hypervisor itself. Any time inadequate hardware resources are available, performance can suffer. This holds true whether all of the host’s resources have been committed, or there are plenty of resources available but insufficient resources have been allocated to a virtual machine.
The resource that tends to cause the most problems with regard to performance is storage. The only way to prevent a storage bottleneck is to ensure the underlying disks can meet the I/O demand of the virtual machines. To address this problem, consider placing virtual hard disks on flash storage, or use a RAID 1+0 array to distribute IOPS across multiple disks, while also providing storage redundancy.
Running Out of Physical Storage Space
Another problem that Hyper-V administrators commonly have to deal with is that of running low on physical storage space. The most common solution to this problem is to use dynamically expanding virtual hard disks.
Virtual hard disks are really nothing more than files that act like a physical hard disk when attached to a virtual machine. A dynamically expanding virtual hard disk is a special type of virtual hard disk file that starts out at a very small size, regardless of how much space has been allocated to the virtual hard disk. This file grows as data is added. For example, a default dynamically expanding virtual hard disk is 127 GB in size, but initially consumes less than 1 GB of physical storage space.
Although using dynamically expanding virtual hard disks is the commonly prescribed solution to the storage capacity problem, there is another solution. Check your physical storage for the existence of orphaned virtual hard disks. When you delete a virtual machine through Hyper-V Manager, Hyper-V does not delete the corresponding virtual hard disk, which means that the remnants of the virtual machine are still consuming storage space. You can get this space back by deleting unwanted virtual hard disks.
Host Can’t Start All of the Virtual Machines
If a Hyper-V host is unable to start all of the virtual machines, it means the host’s hardware resources have been depleted to the point where there are not enough resources remaining to start the VMs. To fix this problem, you will either need to add additional hardware to the host or decrease the VM’s hardware allocations.
Since memory tends to be the biggest limiting factor for virtual machines, many administrators over commit memory resources by using the Hyper-V Dynamic Memory feature. Although you do have to be careful about over-committing memory, memory over-commitment can help to increase VM density.
Checkpoints Are Corrupt and Unusable
I have heard of several situations lately in which an administrator attempted to apply a Hyper-V checkpoint, only to discover the checkpoint was corrupt and could not be applied. Hyper-V checkpoints are normally reliable. However, checkpoints can be invalidated if a virtual hard disk for which checkpoints already exist is mounted independently of (outside of) the virtual machine.
Brien Posey is a 13-time Microsoft MVP with over two decades of IT experience. Prior to going freelance, Posey was a CIO for a national chain of hospitals and healthcare facilities and has served as a network engineer for the United States Department of Defense at Fort Knox. Posey has also worked as a network administrator for some of the largest insurance companies in America.
You can follow Brien on Twitter at @BrienPosey