Maximizing Your Virtual Machine Density in Hyper-V (Part 2)

If you would like to read the other parts in this article series please go to:

In the first article in this series, I explained that maximizing your virtual machine density is something of a double edged sword. On one hand, achieving the highest possible virtual machine density pays dividends when it comes to your server hardware investment. Simply put, an organization won’t have to purchase as many host servers if they make the most efficient possible use of the ones that they already have. On the other hand however, there is a fine line between using creative techniques to achieve the maximum practical virtual machine density per host and cramming so many virtual machines onto a host server that performance begins to suffer and VM and core virtualization functions begin to break down. The trick is to use your host server resources efficiently, but without pushing the hardware too far.

The key to achieving this delicate balance is to always take resource contention into account. Any physical server (whether it is acting as a virtualization host or not) contains a finite amount of hardware resources. The server only has so many CPU cores. The server only has so much memory. The point is that any physical server, no matter how powerful, has its limitations.

When a physical server is acting as a virtualization host, the server’s physical resources are shared among all of the virtual machines that are running on the server, the hypervisor, and the host operating system (if one exists). All of these components are competing for hardware resources. It is this competition for hardware resources that is known as resource contention.

Of course this raises the question of how hardware resources are distributed to virtual machines and to the hypervisor and host operating system. Some resources are allocated in a way that allows a virtual machine to essentially own the resources that it has been assigned. For example, a physical network adapter can be directly assigned to a specific virtual machine by way of a dedicated virtual switch.

Resource contention isn’t directly an issue for hardware resources that are directly assigned to a specific virtual machine. After all, if a hardware resource is dedicated to a specific virtual machine then that resource has essentially been reserved specifically for that virtual machine. Other virtual machines that are running on the host do not even try to use the reserved resources because the hypervisor enforces the resource reservation.

If you look carefully at the wording that I used in the first sentence of the previous paragraph, you will notice that I said that “resource contention isn’t directly an issue for hardware resources that are directly assigned to a specific virtual machine”. What I meant by that statement is that even though the virtual machines aren’t actively competing for the resource, contention occurs in a different way.

Suppose for example that you were to assign a physical network adapter to a specific virtual machine. The other virtual machines that are running on the host server will not attempt to use the network adapter because it has been reserved for use by a specific virtual machine. However, the remaining virtual machines could potentially suffer the effects that they might if resource contention were an issue. This can happen if the remaining virtual machines are not receiving sufficient network bandwidth, partially as a result of some of the available bandwidth being locked away for one specific virtual machine’s exclusive use.

Keep in mind that I am not saying that you should never allocate hardware directly to a specific virtual machine. On the contrary. There are a number of situations that warrant exclusive resource assignments for performance or security reasons. What I am saying is that resource allocation is a tradeoff. If you reserve certain resources for use with one specific virtual machine then those resources are not available for use elsewhere. Therefore, direct resource assignments must be done in a way that gives each virtual machine the resources that it needs, but without allocating excessive resources to the virtual machine or depriving other virtual machines of the resources that they need.

Although some types of resources can be reserved for use by a specific virtual machine, other resources are shared. The exact methods used by the hypervisor for allocating the use of shared resources is complex and far beyond the scope of this article series. However, the process often boils down to queuing. When a virtual machine needs access to a shared resource, it sends a request to the hypervisor, which queues the request . The hypervisor uses an internal algorithm to determine how the queued requests should be processed, thereby controlling virtual machine hardware resource usage.

Earlier in this article, I stated that hardware resource allocations were a delicate balance. Resources should ideally be allocated in a way that achieves the highest possible virtual machine density, but without causing problems related to resource over utilization. Resource over utilization occurs when hardware usage requests are queued more quickly than the requests can be fulfilled. At that point, resource contention begins to impact the overall system performance.

Of course all of this information raises the question of how you can make efficient use of the available hardware resourced, but without going overboard. Some administrators try to solve this problem by estimating each virtual machine’s hardware requirements and then matching those requirements to the physical hardware’s capabilities.

Over all this approach works, but there are two factors that are easy to accidentally overlook. I briefly discussed the first of these factors in my previous article, The problem is that virtual machine resource consumption is not linear. As with a physical server, there are spikes in demand during certain parts of the day. For example, a virtualized domain controller will typically see a demand spike when everyone logs in in the morning, or when everyone returns from lunch. A virtual server that has been provisioned with minimal hardware resources might be ill equipped to deal with these types of spikes in demand. I will talk a lot more about demand spikes later in this series.

The other consideration that is easy to overlook is that you can’t assign 100% of the server’s physical hardware resources to virtual machines. The hypervisor also needs hardware resources in order to do its job.

Hyper-V will not allow you to assign resources directly to the hypervisor, so you just have to remember not to use a portion of the available resources (thereby making them available for use by the hypervisor). As a general rule, I recommend reserving two physical CPU cores and 2 GB of memory for use by the hypervisor and the host operating system. The hypervisor might be able to function with fewer resources, but you should be careful not to shortchange the hypervisor because doing so can adversely affect every virtual machine that is running on the host.

Conclusion

The entire concept of maximizing your virtual machine density comes down to monitoring resource contention. In Part 3 of this article series, I will continue the discussion by showing you some techniques for performing hardware resource assignments.

If you would like to read the other parts in this article series please go to: