As IT Pros we’re often told to “Be flexible” and to “Do more with less”. Nothing is more true than when we’re talking about hardware, software licensing and the placement of network-critical services.
While I agree with the above phrases, and Hyper-V allows us to do both with relative ease, there are still some guidelines that need to be followed to keep us from shooting ourselves in the proverbial foot.
Picture the following situation:
You’re an IT administrator for the XYZ corp. The company has a stand alone Hyper-V host with two VMs, One a DC, and the the other an Exchange Server. Bob from accounting shows up and asks that their new application be installed and served up to the network. Your junior admin, being the nice guy he is, decides to take the task upon himself and installs said application on the Hyper-V host, as it has the most resources available of all the company’s servers. Makes sense right? Sadly your junior admin doesn’t know what he just got himself into.
A couple weeks go by. The web app functions properly for the most part, but one day the memory leak you didn’t know the application had causes the host to run short on memory. Fixing said memory leak may, or may not require a reboot of the host, which would then require a reboot of the VMs running on top of it as well and once the issue is resolved you contact the vendor for support to find out what the heck happened.
Mr. Vendor goes on to explain that “Yeah… that’s a known issue in that version of the code and to prevent the issue from occurring again you’ll need to install patch blah blah….”
You download the patch and install it to prevent an angry mob from forming outside your office and lo and behold it requires a reboot for the changes to take affect. Now you have to reboot your host AND the associated VMs a second time and either schedule downtime, or disrupt production work if the patch is urgently needed.
It’s not a good situation to be in and could have been entirely preventable. Your Junior admin has effectively eliminated the flexibility benefits of Hyper-V.
The above is just a simple example of what can happen when you don’t let your host be just a host. In addition, there are other concerns as well besides patching and stability. You need to be able to insure the security of the host system, and be able to maintain full resource control as well.
Let’s look at each item in turn
1. Ease of Patching
As Hyper-V is designed to serve up scalable and dynamic workloads, uptime is of paramount importance. Therefore, the less time we spend applying patches, the more time we have for running our production workload and keeping end-users happy. Installing extra software on the host that “should” get installed elsewhere adds to the amount of stuff that needs to be patched and maintained on the host.
Not only does this concept apply to 3rd party software, but it also applies to Windows Server roles and features as well. Microsoft has come to understand this reality and has created Windows Server Core to assist in situations such as this.
For those that don’t know, Windows Server Core is a stripped-down-GUI version of the server OS that contains a minimal toolset and only the core files and services needed to serve up primary production workloads such as AD, DNS, Hyper-V…etc…etc.
As you can see below, the main Windows UI is not present and is instead replaced by a command prompt window and a couple tools, such as Notepad, Powershell and Task Manager. If you’re interested in more information on Server Core, I’ve got a couple posts on my personal blog regarding this topic.
The default view after login to a server core box.
By removing most parts of the UI, Microsoft has essentially stripped all the bloat out of the OS. Running the host OS in this mode and keeping un-needed 3rd party software and Windows Server roles/features off the host means less time required for you to apply patches and more time serving up the company’s production workload.
2. Stability
Stability is always important, and if things are un-expectantly going offline/running slow, your liable to have a mutiny on your hands. Hyper-V is inherently quite stable, but the more software we add, the more things there are present in the system to potentially cause stability issues.
In short, only install what you absolutely NEED on your Hyper-V hosts and put the rest elsewhere.
3. Security
It has become an everyday reality that IT pros need to be thinking about security in all facets of our jobs. This is doubly true for Hyper-V hosts for one quite obvious reason.
If your Hyper-V host is compromised, all VMs running on said host are potentially compromised as well.
With that said, great care should be given to insure that these critical systems are secure. This can be best achieved by running the hosts in Server Core mode with only the roles needed to do the job. When a server is running in core mode, most of the items that are typically vulnerable to attack are no longer present in the system, such as IE, Java….etc…etc.
Another area of concern is Anti-Virus. There is some debate in the community as to whether you should run AV on Hyper-V hosts or not. That decision will depend mostly on your workload and whether you have any industry regulations to adhere to.
If you find yourself needing to run AV on your hosts, please take note of the necessary AV exceptions listed here. The article applies to Hyper-V 2008/2008 R2, but it serves as a good baseline for 2012 Hyper-V.
If you’re interested in more regarding security and Hyper-V, check out Eric Siron’s recent post here.
4. Resource Control
In the XYZ Corp. example above, the application needed by accounting experienced memory issues which, in turn, affected all running VMs due to the application being installed in the host partition.
Had this application been installed inside a guest VM, only that VM would have been affected. This is one of the advantages of the proper use of virtualization.
In addition, what happens when the application requires more memory? Yes, most Hyper-V hosts will have quite a bit of memory, but what if it didn’t have enough? You’d have to down the host (again) to install new physical memory. Something that would be easily achievable with no downtime if the application had been running in a VM with Dynamic Memory enabled. This is true for CPU, storage and networking as well.
Not being bound to changes or needs at the hardware level allows Hyper-V to easily scale based on the needs of the business and helps us to not get stuck into one configuration or another.
Summary
Keep these things in mind when setting up your hosts. If you’re already in a situation where some of the above suggestions are not being followed, take the time and effort to make these best practice changes. Your life will be made simpler as a result.
As a wise man once said “An ounce of prevention is worth a pound of cure”
Thanks for reading all!
More in this category
About the Author
Andy Syrewicze
