As someone who has been working with Microsoft Hyper-V since the days of Windows Server 2008, I have set up more Hyper-V hosts than I care to think about. As such, I wanted to take the opportunity to talk about some of the best practices that I have adopted along the way.
Server Core vs. Windows Desktop Experience
One of the most well-known best practices for Hyper-V hosts is to run a Server Core configuration on the host operating system. For the most part, I agree with this particular best practice. After all, the hardware resources that would normally be used to run the Windows Desktop Experience (the GUI) can be put to work hosting virtual machines instead. Besides, Server Core deployments have a smaller codebase than servers running the full Windows Desktop Experience and are therefore arguably more secure.
The one caveat that I would make to this particular best practice is that running a Server Core configuration is not the best choice for every organization. Smaller shops with two or three Hyper-V servers and a very limited IT staff may find that running the full Windows Desktop Experience simplifies things for them. In my own organization, for example, I currently have three Hyper-V hosts and run the Windows Desktop Experience on all of them.
Dedicated network segments
Another best practice is to avoid lumping all of the physical network communications together within a single network adapter or network adapter team. Certain types of communications should be isolated to a dedicated network adapter whenever possible. This will help to ensure optimal performance and will help to improve security.
The first type of traffic that I recommend isolating to a dedicated physical network segment is host management traffic. To be fair, host management traffic normally accounts for a very small percentage of a Hyper-V server’s total network traffic. Even so, I recommend isolating host management traffic simply for the sake of security. It’s always a good idea to avoid mixing management traffic and general-purpose user traffic whenever you can.
It almost goes without saying, but if your Hyper-V host uses something other than direct-attached storage (such as iSCSI attached storage) then it is extraordinarily important both from a security and a performance standpoint to route the storage traffic over a dedicated network segment. In my own organization, for example, my Hyper-V servers are attached to external storage arrays through a series of dedicated 10GB Ethernet links.
It’s also important to use dedicated physical network segments for failover cluster traffic, live migration traffic, and VM replication traffic. Admittedly though, Hyper-V does not provide a mechanism for routing VM replication traffic across a specific segment (at least not if you are not working in a clustered environment), but depending on your hardware configuration there are some roundabout ways to force replication traffic to use a specific link. Regardless of its purpose, the network traffic flowing over any of the dedicated links should ideally be IPSec encrypted.
Separation of administrative roles
While I am on the subject of security, I also think that there is something to be said for the separation of administrative roles. In small organizations, it is totally normal and usually necessary for a couple of administrators to have full access to all of the organization’s IT resources. In larger organizations though, it is a good idea to segment administrative responsibilities. This keeps any one single administrator from having too much authority.
One of the best ways to accomplish this is to create a dedicated Active Directory domain (or even a dedicated Active Directory forest) that is used solely to manage the organization’s Hyper-V hosts. The nice thing about this approach is that it allows you to differentiate between Hyper-V host administrators and the administrators who oversee the workloads running on virtual machines.
Even though I am the only administrator in my own organization, I have created a dedicated Active Directory forest for my Hyper-V hosts. The reason why I did that actually had nothing to do with security. At one time, I had significantly more Hyper-V servers than I am operating today. Grouping all of the Hyper-V hosts into a dedicated Active Directory domain made it a lot easier to perform bulk management on those servers.
The host operating system
When it comes to the Hyper-V servers host operating system, I am a big believer in keeping things as simple as possible. Simple configurations tend to be less problematic. My two main guiding principles for configuring the host operating system are to make it as secure as possible, and to avoid running any applications or services that I don’t absolutely have to.
Countless articles and best practices guides have been written on the subject of hardening the Windows operating system, so I don’t want to spend a lot of time talking about OS hardening. What I do want to talk about, however, is what I recommend running on a Hyper-V server.
Normally, the only role that you should be running on a Hyper-V host is the Hyper-V role. Having said that, however, a case can be made for running the file and storage services role, particularly if virtual machines are being stored on direct-attached storage.
It’s also important to avoid running any third-party applications within the host operating system, with a couple of possible exceptions. It may sometimes be necessary to run a backup agent or a management agent within the host operating system, depending on what backup and management tools you use in your organization. Even so, there is a big difference between running a backup agent and having your Hyper-V server pull double duty as a backup server.
Another third-party component to consider is anti-malware software. There are a lot of people out there, even within Microsoft, who recommend that you do not run anti-malware software within the Hyper-V host operating system. There are two main reasons for this. First, if not properly configured, antivirus software can damage Hyper-V. Second, assuming that the host operating system is really being used solely as a Hyper-V host, it should never come into contact with malware.
Personally, I do run anti-malware software on my Hyper-V servers. However, I had to set up a number of scanning exclusions to prevent the software from harming Hyper-V.
And if you’d like to read a similar story on best practices for configuring Hyper-V virtual machines, check it out here.
Featured image: Shutterstock