(Part 1)
This article explains the Hyper-V Manager console’s limitations with regard to managing multiple Hyper-V hosts, and then goes on to examine other options for managing large numbers of virtual machines.
Introduction
One of the challenges of working with Hyper-V is the fact that most Hyper-V deployments consist of multiple host servers. Unfortunately, the Hyper-V Manager is really only designed to manage a single host server. That being the case, I decided to take the opportunity to talk about some techniques that you can use to manage multiple Hyper-V host servers.
Before I Begin
Before I get started, I need to point out that the techniques that I am writing about are based on Hyper-V 3.0 and System Center Virtual Machine Manager 2012 SP1. In some cases these techniques will work with older versions of Hyper-V or Virtual Machine Manager, and in other cases they will not.
The Hyper-V Manager
Even though the Hyper-V Manager is more than a little bit lacking in terms of its multi-server management capabilities, that isn’t to say that you can’t use the Hyper-V Manager for multi-server management.
When you open the Hyper-V Manager, the console tree’s left pane lists the name of your Hyper-V server. When you select this server, the top center pane displays a list of the virtual machines residing on that host server, as shown in Figure A.
Figure A: The left pane lists the name of the Hyper-V server.
As you look at the figure above, it might seem as though the console’s left pane contains an awful lot of empty space. The reason for this is that you can add additional Hyper-V host servers to the console. All you have to do is to right click on the Hyper-V Manager container, and then choose the Connect to Server command from the shortcut menu, as shown in Figure B. When prompted, just enter the name of the server that you want to add to the console.
Figure B: To manage another server, right click on the Hyper-V Manager container and choose the Connect to Server command from the shortcut menu.
You can easily populate the Hyper-V Manager console with all of your Hyper-V servers, as shown in Figure C.
Figure C: The Hyper-V Manager can display and manage multiple Hyper-V servers.
Unfortunately, this is where the Hyper-V Manager’s multi server management capabilities end. You cannot for example, select multiple Hyper-V hosts to receive an aggregate view of your virtual datacenter. For that, you will need System Center Virtual Machine Manager.
System Center Virtual Machine Manager 2012
Microsoft considers the Hyper-V Manager to be a lightweight management console that is intended for use primarily in smaller organizations. For larger organizations with several or more Hyper-V servers, Microsoft recommends using System Center Virtual Machine Manager. System Center Virtual Machine Manager 2012 has capabilities that go way beyond simple, multi-server management. In fact, entire books have been written about System Center Virtual Machine Manager. In spite of System Center Virtual Machine Manager’s complexity, Hyper-V administrators should find it relatively easy to begin using the tool for basic host server and virtual machine management.
Virtual Machine Manager 2012 : Architecture
Unlike the Hyper-V Manager, System Center Virtual Machine Manager is able to display an aggregate view of virtual machines spanning multiple hosts. As you can see in Figure D, selecting the All Hosts container causes the console to display all of the virtual machines regardless of which host server they reside on.
Figure D: System Center Virtual Machine Manager can display an aggregate view of your virtual machines.
As you look at the figure above, you can see that not only does System Center Virtual Machine Manner display virtual machines from multiple host servers, it offers all of the same management functionality that you would get through the Hyper-V Manager. For example, you can use the ribbon at the top of the screen to create new virtual machines.
Another thing that you probably noticed about the previous figure is that the list of virtual machines can grow to be quite long. I’ve only got a couple dozen virtual machines, but a large organization could easily have hundreds or even thousands of virtual machines. Once you start dealing with large scale Hyper-V deployments with hundreds or thousands of virtual machines, the idea of being able to display all of those virtual machines on the screen at the same time suddenly seems a lot less appealing. The virtual machine list can quickly become overwhelming.
Thankfully, Microsoft gives you a few different ways to filter the list of virtual machines so that you can view the specific virtual machines that you are interested in. One option is to simply click on a column heading to sort the list by the selected column. For example, you might sort the list by host server name or by average CPU usage. Another option is to create a custom view of the virtualization hosts. You might have noticed in my previous screen captures that the names of my virtualization hosts reflect the host’s purposes. I have three lab hosts and two production hosts. With that in mind, you can see how it might be useful to create a view that shows only lab hosts (and the virtual machines on them) or only production hosts.
If you want to create this type of view, you can do so by creating a host group. A host group is really nothing more than a logical collection of host servers. To create a host group, right click on the All Hosts container and select the Create Host Group command from the shortcut menu. When you do, System Center Virtual Machine Manager will create a host group called New Host Group. You can easily rename this host group to a name that reflects its purpose.
Once the new host group is in place, you can begin dragging host computers into the host group. When you click on a host group you will see the virtual machines residing on the hosts within the host group. For example, if you look at Figure E, you can see that I have created a host group called Lab Machines and then placed my lab hosts within that host group. When I select the Lab Machines host group, the console displays only the virtual machines that reside on lab servers.
Figure E: Host groups allow you to organize Hyper-V hosts by purpose.
Host groups are a handy way of organizing host servers, but they may not offer the granularity that you need. If you want to temporarily display a list of virtual machines that conform to a specific criteria, click on the search box. When you do, the console will display a number of different search criteria. Click on the criteria that you want to filter by and then click on the search box again. This time the console will display a range of values for the search criteria, as shown in Figure F. Click on the most appropriate value, and the console will display a filtered list of virtual machines.
Figure F: You can use the search box to filter the list of virtual machines.
Conclusion
In this article, I have shown you a few different tricks for managing multiple Hyper-V hosts. In Part 2, I will show you how you can manage multiple host servers using PowerShell.
(Part 2)
This article continues the discussion of multi-server management for Hyper-V by talking about server groups within the Server Manager and by delving into PowerShell.
Introduction
So far in this series, I have shown you a variety of techniques for collectively managing virtual machines. In addition to the techniques that I have already shown you, Windows Server 2012 and Hyper-V provide some wonderful PowerShell based multi-server management capabilities. Before I get to that though, I want to show you one more technique for collectively managing Hyper-V host servers.
Server Grouping
As you are no doubt aware, Windows Server 2012 contains a new version of Server Manager. Although not completely intuitive, one of the really great features found in this new version is the ability to collectively manage Windows servers.
The server grouping feature is not actually a Hyper-V feature, but rather a Windows Server 2012 feature. That being the case, you cannot use it to perform virtual machine management in the sense of modifying the virtual machine resources or live migrating a virtual machine to an alternate host. However, this feature is useful nonetheless.
Server grouping allows you to create groups of similar servers – physical or virtual. This grouping means that you can collectively manage servers that are performing similar tasks. For instance, you might consider creating a group for all of your Hyper-V hosts. Likewise, you could create a group for virtual machines that need to be collectively managed. For instance, you might create a group for your virtualized domain controllers.
The process of creating a server group is actually really simple. To do so, open the Server Manager and then choose the Create Server Group command. When the Create Server Group dialog box appears, enter a name for the new group, as shown in Figure A.
Figure A: Enter a name for the new server group.
The next step is to add servers to the server group that you are creating. You will notice in the figure that right now the Server Pool tab is selected. This means that the dialog box will list all of the servers that currently exist within the server pool. To add a server to the new server group, simply select the server and then click the arrow icon.
In most cases the group that you are creating probably will act as a sub set of the servers that are in the server pool. However, you can add servers that do not currently exist within the pool. As you can see in the figure above, the dialog box contains three other tabs – Active Directory, DNS, and Import. You can use these tabs to add computers that are Active Directory members, add servers by fully qualified domain name or IP address, or to import a file containing a list of servers. When you have made your selections, click OK.
If you look at Figure B, you can see that I have created two server groups – Lab Servers and Production Servers. The groups are listed in the column to the left, with the Production Servers group currently selected.
Figure B: You can create a series of server groups.
In case you are wondering, the Production Servers group that is shown in this figure contains Hyper-V hosts that are running production workloads. I could have just as easily created a group for production virtual machines. The only real requirement for doing so is that Server Manager needs to be able to see those virtual machines, which basically means that you won’t be able to add virtual machines that reside on an isolated virtual network segment that is inaccessible to the host operating system or to the physical network.
Creating a server group does more than just group similar servers together. You can collectively manage the servers within the group. For example, if you take a look at Figure C, you can see that I have selected both of the servers in the Production Servers group. If you look at the Services pane near the bottom of the screen, you will notice that it contains listings from both of the selected servers.
Figure C: The console can display aggregate information from multiple servers.
PowerShell Management
If you need true Hyper-V level management for multiple virtual machines or for multiple Hyper-V hosts, then your best option is often to use PowerShell. Windows Server 2012 is specifically designed to allow multi server Hyper-V management through PowerShell. In fact, you can use PowerShell to accomplish many of the same management tasks that you could perform if you had System Center 2012 Virtual Machine Manager (which I discussed in the previous article).
There are a few different ways in which PowerShell lets you run commands against multiple targets. One method that you can use is to establish a session with a remote Hyper-V host. This isn’t technically a multi-server management technique, because your actions are performed against a single host, but it does allow you to execute a command on a remote Hyper-V server.
To show you how this technique works, let’s assume that you wanted to run the Get-VM command against a remote server named Lab1. In case you aren’t familiar with the Get-VM command, it is one of the simplest PowerShell commands for Hyper-V. This command returns a list of the virtual machines that exist on the host server. The commands that you would use to run the Get-VM cmdlet on a host named Lab1 are:
Enter-PSSession Lab1Get-VMExit-PSSession
The first line in this block of code establishes a session with the remote server. When this happens, you will actually see the PowerShell prompt change to reflect the fact that you are now connected to a remote server instead of the local server.
The second command is the Get-VM command. Keep in mind that I am only using Get-VM as an example. You could actually use any PowerShell cmdlet here.
The last line of the block of code shown above is Exit-PSSession. This command terminates your session with the remote Hyper-V hosts. The most important thing to know about this command is that until you enter the Exit-PSSession command you will remain connected to the remote host. In the sample code block listed above, we established a connection to a remote host, executed a single PowerShell cmdlet, and then terminated the session. While this is perfectly valid behavior, you aren’t limited to executing only a single PowerShell cmdlet within the remote session. You are free to execute as many cmdlets as you want (or even to run PowerShell scripts) until the session is terminated.
As I mentioned earlier, this is only one example of a way that you can use PowerShell for multi-server management. There are several other techniques that you can use. One technique isn’t necessarily better than another. It’s just that depending on what you are trying to accomplish, one technique might be better suited to a particular task than another technique would be.
Conclusion
In this article, I have demonstrated a couple more techniques for multi-server management in a Hyper-V environment. In Part 3 I plan to conclude the series by showing you some PowerShell commands that will allow you to perform administrative actions in bulk against multiple physical or virtual servers.
Thanks to
The Author — Brien M. Posey