Understanding Hyper-V's failover settings in Failover Cluster Management

Virtual machines that are colocated onto hosts can pose compliance risks. There are workarounds, including the use of Failover Cluster Management, to secure Hyper-V environments.

The previous article in this series discussed the hidden dangers of virtualizing networks atop Microsoft Hyper-V. Those security problems add to the list of new threats to prepare for when virtualizing an infrastructure. The ubiquitous hypervisor creates a distributed single point of failure across every virtual host. Dormant virtual machines create the potential for exposure when they're not updated like the rest of an environment.

But did you know that running virtual machines (VMs) can pose a hidden danger as well? Specifically, the colocation of those VMs onto their virtual hosts can create a security hazard or regulatory compliance problems if not properly managed.

Different regulations provide different levels of guidance for actual computer configurations. The Federal Desktop Core Configuration standard and the Payment Card Industry Data Security Standard (PCI DSS) are very specific about configurations and architecture. Others, like the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act, are more general in their requirements. TechTarget contributor Michael Cobb has discussed PCI DSS and its impacts on virtual environments in an article.

In that article, he notes that PCI DSS 2.2.1 states that a server should provide only one function. A virtual host that runs multiple colocated virtual machines could be in violation of the regulations. Other, more general statutory requirements specify that preventative, detective and corrective controls must be placed within computing environments for data assurance. These controls ensure that user activities are logged, computer connectivity is segregated, and alerts are raised when changes occur.

This problem is challenging enough in the physical world, often requiring multiple products to achieve compliance goals. But in the virtual environment, the challenge can grow even more complex.

VM colocation is not a static problem but relates directly to the level of dynamism in a highly available virtual environment. Consider such an environment with Hyper-V that has multiple nodes in its cluster. Over any period of time, it is likely that virtual machines will be live migrated from host to host for load balancing or to recover from a host failure. Normally, this is considered a good thing, because the high-availability architecture ensures that VMs remain available even after faults.

Yet as the previous article in this series noted, virtual networks are not like physical networks. The capabilities in a Hyper-V virtual switch are a subset of what people are used to seeing on Cisco devices. Some established network access control lists (ACLs) hit a dead end as they enter the virtual network switch on a Hyper-V host. While these ACLs may protect traffic as it exits the virtual host, they do little to protect traffic as it bounces from VM to VM on that same host and through the virtual switch. In effect, the network protection from isolating computers from one another disappears once those computers share the same virtual switch.

Certain highly secure or compliance-relevant VM workloads should never be placed on the same host. This can be prevented in a number of ways. The first option is to specify which nodes are acceptable for hosting a particular virtual machine. This can be done by identifying the possible owners of that VM's cluster resource in the Failover Cluster Management wizard. If you have only a few virtual machines that shouldn't colocate, you can configure their possible owners to be mutually exclusive, preventing them from ever failing over to the same node.

A second alternative is to use Microsoft's host-level firewall capability in the Windows operating system. This service will block virtual machines from one another as they move around, but the security policy of many environments simply doesn't support the use of Microsoft's host-based firewall as a singular protective measure.

The third alternative is to create multiple virtual host clusters based on the security level associated with those clusters. VM workloads tagged as highly secure or compliance-relevant can be isolated into their own clusters, where rules can be set for each cluster. Less-critical machines, such as those that provide infrastructure services, can then be relegated to a lower-security environment.

My goal with this series has been to help you recognize that virtualization adds as many challenges as it overcomes. Although virtualization does wonders for consolidating physical computers, saving money on space, power and cooling, and it can improve manageability of an IT environment, it can also introduce a set of security problems that must be planned for. Virtualization administrator must recognize that virtual environments are much different than their physical counterparts and prepare accordingly.

About the author

Greg Shields, Contributor

Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specializes in Microsoft administration, systems management and monitoring, and virtualization. He is the author of several books, including Windows Server 2008: What's New/What's Changed, available from Sapien Press.


Dig Deeper on Microsoft Hyper-V management