Manage Learn to apply best practices and optimize your operations.

Using Virtual Machine Manager for Hyper-V management

In this section of our guide on managing Hyper-V, we explore using the Virtual Machine Manager service console to manage Hyper-V.

Thus far in this guide on installing and managing Hyper-V in Windows Server 2008, we've discussed the benefits of Hyper-V technology, hardware requirements for Hyper-V virtualiation and how to install the Hyper-V role in your environment. Now we'll take a look at the System Center Virtual Machine Manager service console that helps manage Hyper-V.

System Center Virtual Machine Manager 2008 R2

An installation of Hyper-V alone can be managed using the Hyper-V Manager console. This console enables administrators to work with individual instances of Hyper-V, creating virtual machines and virtual networks, interacting with those virtual machines, and doing the central tasks of VM management.

But the native Hyper-V Manager console suffers from a limitation: It works with only one Hyper-V server at a time. When your number of Hyper-V servers goes much beyond a single server, you may quickly find the Hyper-V Manager console to be limited in the features it provides.

System Center Virtual Machine Manager (VMM) is Microsoft's solution to this management limitation. This System Center product arrives as a solution that layers on top of your entire Hyper-V infrastructure. Sitting logically on top of every Hyper-V server at once, VMM can manage each virtual machine in a group. Using this solution, you can define configurations on multiple machines, work with virtual machines no matter where they are hosted, and quickly build and deploy virtual machine templates from VMM's built-in library.

System Center Virtual Machine Manager also offers features such as physical-to-virtual server (or P2V) migration and virtual-to-virtual (or V2V) server migration capabilities. These tools provide for the conversion of physical machines to Hyper-V VMs. They can also convert VMs that are hosted atop VMware ESX hypervisor to Hyper-V's .Virtual Hard Disk format. VMM also operates as a multiple-hypervisor solution, managing Hyper-V hosts alongside ESX hosts through the same console.

When connected with an instance of System Center Operations Manager, VMM gains can monitor and react to virtual machine behavior. Performance and Resource Optimization (PRO) tips are a feature of this integration. These tips alert administrators with actionable intelligence on when virtual machines should be migrated, turned off, or other activities should be taken based on VMs' real-time behavior.

Adding VMM also brings a set of important System Center security features. While it is possible to configure roles and permissions in Hyper-V alone, the process using the Windows Authorization Manager (or AZMan) is complex and scoped to only a single host at a time. Conversely, roles and permissions in VMM are configured through an easy-to-use graphical interface that can manage multiple machines at once, ensuring that security settings are cohesively set across your entire infrastructure.

Using VMM requires an additional purchase on top of the licenses used for Hyper-V; however, its widespread management reach makes it a must-have for environments who desire to use Hyper-V in anything but the smallest of environments.

Cluster Shared Volumes

Cluster Shared Volumes is a new feature in Hyper-V R2 that improves the operational management of Hyper-V VMs. While not intended to improve server cluster performance, this new feature makes it possible to fail over individual virtual machines from one host to another when their disk files are colocated on the same storage volume.

It is easiest to explain this important feature by first discussing how cluster resources work within Windows Failover Clustering. A Windows Failover Cluster itself exists as two or more cluster "nodes" on which the Windows Failover Cluster service has been installed and configured to operate as a cluster.

Once created, a cluster can then host any of a set of cluster resources. Those resources can be services and applications such as a DHCP server, a file server, or a Hyper-V virtual machine. Within each service or application are additional resources that enable the service or application to do its job: For example, a file server resource might include "network name", "IP address", and "physical disk" resources. Among those resources, dependencies are created to identify which resources depend on which other resources. In this example, the network name might have a dependency on the IP address. As such, if the IP address fails, so will the network name, and ultimately the file server resource itself.

Within this architecture lies the problem with Hyper-V R1: This original version was only capable of failing over a physical disk resource all at once. This means that when a virtual machine needed to be failed over from one node to another, any other virtual machines which shared its physical disk would be failed over at the same time.

The net result was that this configuration made it operationally difficult to install multiple virtual machines to a single attached disk. As a workaround, Microsoft's recommendation with Hyper-V R1 was to create one physical disk per virtual machine and manage them as individual units. This practice created additional work for storage administrators, required the creation of large numbers of small-sized SAN disks, and ultimately complicated the use of Hyper-V in a clustered environment.

Cluster Shared Volumes eliminates this problem by making the cluster aware of the individual files within a physical disk resource. By enabling Cluster Shared Volumes, the cluster gains the ability to fail over individual virtual machine .VHD files rather than the entire physical disk at once. This change now enables administrators to create smaller numbers of very large physical disks with the goal of storing multiple virtual machines on each disk.

Cluster Shared Volumes is not enabled by default, and must be specifically enabled for this feature to work. It can be done by right-clicking the Cluster Shared Volumes node in the Failover Cluster Manager and selecting Add Storage. In the resulting wizard, select the storage you wish to enable. Be aware that Cluster Shared Volumes is currently only supported for use by Hyper-V virtual machines.

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 Improving server management with virtualization

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.