System Center Virtual Machine Manager for Beginners (Part 1)

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

One of the most common misconceptions about Microsoft’s Hyper-V is that it is fully self-contained. It isn’t exactly a secret that Hyper-V is included with the Windows Server operating system and that the Windows Server license includes the ability to use Hyper-V and the various management tools that come with it. Depending upon what version of Windows Server you are running, the operating system license might even include licenses to run Windows Server on virtual machines.

On the surface, it would seem that you have everything that you need in order to deploy and manage virtual machines. As you may discover later however, there are some things that are missing from Windows Server.

In some ways, the idea that Windows Server includes everything that you need for Hyper-V is absolutely true. Windows Server 2012 R2 allows you to install Hyper-V and create and manage virtual machines. If you have Windows Server 2012 R2 Standard Edition then you are licensed to run Windows Server 2012 R2 as a guest operating system on up to two virtual machines (assuming that the host operating system isn’t being used for anything other than Hyper-V). If you have the Datacenter Edition then you can run Windows Server 2012 R2 on an unlimited number of virtual machines on that Hyper-V host.

Of course even small shops tend to discover eventually that a single server Hyper-V server is inadequate. Even though a single Hyper-V server can host a number of virtual machines, the host server itself can become a single point of failure. If the host were to fail then all of the virtual machines that are running on it will also fail, thereby resulting in a major outage.

Microsoft provides two different methods that you can use to help avoid this problem. The preferred method is to deploy failover clustering. Failover clustering treats individual virtual machines as clustered resources. If a host server were to fail then clustered virtual machines are able to fail over to a different Hyper-V server where they can continue to run.

Of the other solution to preventing the Hyper-V server from becoming a single point of failure is to create virtual machine replicas. Replicas do not provide real-time failover capabilities the way that failover clustering does, but they do allow you to have a nearly up-to-date, standby copy of your virtual machines on a separate Hyper-V server.

In case you’re wondering, failover clustering capabilities are made available through Windows Server (through the Failover Clustering Manager) and the Hyper-V replica feature is exposed through the Hyper-V Manager. So what could possibly be missing?

In a word, the thing that is missing is scalability. The Hyper-V Manager was never designed to be scalable. It is intended to provide a host server level view of the virtualization infrastructure. Similarly, the Failover Clustering Manager is also somewhat lacking when it comes to scalability. Microsoft has done a lot of work around the Failover Clustering Manager in Windows Server 2012 R2 to make it more scalable. Even so, there are major portions of the virtualization infrastructure that are not exposed through the Failover Clustering Manager.

This is where System Center 2012 R2 Virtual Machine Manager comes into play. Whether you are using failover clustering, Hyper-V replication, or simply multiple Hyper-V hosts, you are using multiple physical servers. System Center 2012 R2 Virtual Machine Manager (which I will refer to throughout this article series as Virtual Machine Manager) is a management tool that is designed to make Hyper-V a lot easier to manage these servers as the size of your Hyper-V deployment increases.

In all fairness, Virtual Machine Manager also exposes a number of Hyper-V capabilities that cannot be accessed through the Hyper-V Manager or through the Failover Clustering Manager. I will discuss some of these capabilities later on in the article series. For right now though, I want to talk about scalability because Virtual Machine Manager was originally introduced as a scalability solution for Hyper-V.

In order to really appreciate the capabilities that Virtual Machine Manager gives you, I want to take a look at the limitations that are present with the Hyper-V Manager. If you take a look at Figure A, you can see what the Hyper-V Manager looks like.

Figure A: The Hyper-V Manager provides a somewhat limited view of your virtualization infrastructure.

As you can see in the figure above, the Hyper-V Manager is divided into three vertical columns. The column on the left lists the host server. The upper portion of the middle column lists all of the virtual machines that are running on the host. Although this particular arrangement seems logical enough, it is flawed in terms of scalability. As previously explained, most organizations that use Hyper-V in a production environment have more than one Hyper-V server. Even so, the Hyper-V Manager only displays the local server and the virtual machines that are running on it.

This isn’t to say that there is no way to populate the Hyper-V Manager with information about your other Hyper-V hosts. If you want to make the Hyper-V Manager aware of additional Hyper-V hosts, you can do so by right clicking on the Hyper-V Manager container (located in the upper left portion of the console) and choosing the Connect to Server command from the shortcut menu. By doing so, you will be able to provide the Hyper-V Manager with the name of another Hyper-V Server. As you can see in Figure B, it is possible to manage multiple Hyper-V servers through the Hyper-V Manager.

Figure B: The Hyper-V Manager can display multiple Hyper-V servers.

Although multiple server management capabilities do exist in the Hyper-V Manager, there are a couple of problems with using the Hyper-V Manager to manage large scale Hyper-V deployments. First, connections to the various Hyper-V hosts have to be established manually. I was able to connect the Hyper-V servers shown in the figure above in a matter of a couple of minutes. Even so, imagine how long the process would have taken (and how much room there would be for errors or omissions) if I had to manually connect dozens of Hyper-V servers to the console.

A bigger problem with this approach is that it does not address the scalability issue. If you look back at the figure above, you will notice that the Hyper-V Manager displays the virtual machines for the currently selected host. So what happens if you need to locate a specific virtual machine? The Hyper-V Manager does not contain a search box. Going by memory isn’t an option either, because Hyper-V virtual machines have the ability to live migrate from one host server to the next. As such, the host on which a virtual machine resided yesterday might not be the same host where the virtual machine resides today.

If you got a large number of Hyper-V host servers and you need to locate a specific virtual machine, you have three options. The first option is to manually scroll through the list of virtual machines contained on each individual host server. Needless to say, this isn’t a good option in large environments because it is time consuming and error-prone.

The second option is to use Windows PowerShell. You can use the Get-VM cmdlet to locate a virtual machine by name. Although this technique works pretty well, a lot of administrators are not comfortable working in PowerShell.

The third option is to use Virtual Machine Manager. Virtual Machine Manager can give you a consolidated view of your virtual machines across all of your host servers. It is even possible to use Virtual Machine Manager to view virtual machines that are running in VMware environments.

Now that I have taken the opportunity to talk a little bit about the advantages of Virtual Machine Manager, it’s time to start learning how Virtual Machine Manager works. In the next article, I will show you how to deploy Virtual Machine Manager and I will also begin walking you through the Virtual Machine Manager interface.

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