Problem solve Get help with specific problems with your technologies, process and projects.

Five mistakes to avoid when deploying Hyper-V virtual machines

While Hyper-V is relatively simple to set up, there are still plenty of gotchas to consider. Here are some of the most common configuration blunders that can trip you up.

Microsoft has made working with Hyper-V so easy that it no longer takes a specialized skill set to get a virtual...

machine (VM) up and running. The downside, however, is that there is plenty of room for mistakes. Even though the wizards and setup verbiage try to move you in the right direction for best practices, I still see plenty of people introducing risk into their virtual environments without even realizing it.

Here are the five most common mistakes I see with Microsoft Hyper-V deployments and how you can avoid them.

#1. Ignoring the management network
When you first add the Hyper-V virtualization role, you should dedicate a single network interface card (NIC) for management. Many people skip this because it wastes a network port. After all, without a dedicated management interface you are still able to manage the host, so why waste the port?

Well, consider the security implications. The host, otherwise known as the parent partition, is hosting several virtual machines, all with their own workloads and data. When you have access to the host, you also have direct console access to those virtual machines and the virtual hard disks. Would you allow your DMZ and internal network to operate in the same subnet? Of course not -- there would be too many risks.

Consider the host to be of a different security level than your virtual machines. The parent partition should only be manageable from a separate network interface on a network dedicated to administrative access. Without it, you open yourself up to security risks.

#2. Using the wrong kind of disk
When you setup a new virtual machine, you also setup a virtual hard disk. This dynamically expanding disk is a file on the hard drive of the host, which you have the option to make any size. This is a great option because it starts you off with a smaller file that grows only as you need it. Even if you specify a 250 GB hard disk, it will only use the space it needs. This means you will end up with a true VHD file size that is usually much smaller.

With this convenience there is a trade-off, as the performance of a dynamically expanding disk takes a hit. It not only has to expand the file as you need it, it also requires additional maintenance if you add and remove large amounts of data using the compact function.

It can also pose a problem if you do not keep track of your configuration and run out of disk space. With fixed disks, which reserve the space by creating a right-sized VHD file up front, your performance is roughly consistent with the hardware and you avoid the possibility of running out of disk space. If you already have dynamic disks you can use the Convert operation to transform them into physical disks.

#3. Incorrect configurations of snapshots
One of the best reasons for systems administrators to use Microsoft Hyper-V for virtualization is the snapshot feature. It's an easy way to revert and get yourself out of a jam, allowing you to avoid a career limiting move. Still, there are a few problems with using snapshots.

First, a snapshot is not a backup It seems counter-intuitive because the magic of snapshots makes it seem like a perfect backup, but it doesn't give you file-level restores nor does it protect you against issues on the Hyper-V host. It's a system state backup, so certain applications like Microsoft Exchange Server will have problems with in-flight data or connections.

Next, snapshots are stored by default in the same location as the VHD file, so the snapshot files can build up and choke the storage of a disk with limited available space. Your first inclination may be to delete those snapshot files if you don't need them using the Hyper-V Manager. This won't actually get rid of those snapshot files; it will merely mark them for a merge into your main VHD. The next time you shut down the virtual machine the merge will occur, so if you have many snapshots this can take a bit of time. Thus, there aren't any quick ways to relieve disk space issues with snapshots without a complete shutdown of a virtual machine, so be sure to plan your snapshots appropriately and make time for maintenance to avoid future issues.

#4. Too many CPUs
Multi-core processors are commonplace now, with a typical server having eight CPU cores as a starting point. Most people equate more cores to better performance, and Microsoft Hyper-V does allow you to assign up to four processors (or 32 processors in Hyper-V R2) to a virtual machine.

Although flexible, there is a cost to using multiple processors on a single virtual machine.

Although flexible, there is a cost to using multiple processors on a single virtual machine. You shouldn't exceed a 2:1 ratio for virtual processors to physical cores. In the case of a quad-core server, this means you shouldn't allocate more than eight virtual processors for performance reasons. Additionally, you should not assign four processors to a virtual machine because a virtual processor doesn't map to a single physical core. Instead, that work is distributed to all of the physical cores. Therefore, you should have a good reason for taking your virtual machine to multiple cores, like a CPU-intensive server such as a database server. If you are working with something like a WSUS server that sits idle most of the time and doesn't stress the processor, you'd be wasting resources by assigning too many virtual CPUs.

#5. Not taking advantage of virtual switches
Virtual switches are an extension of your network topology. Network administrators set up virtual LANs, or VLANs, and use 802.1Q trunking to make the network more efficient and easier to manage.

When we plug into the switch port, we still consider the host as the endpoint of that network connection, but that's no longer the case. If you use VLANs and trunking in your network, you can extend that functionality to your virtual machine host. Have your network administrator give you the rundown of the switch configurations and how they are set up. Instead of configuring a dedicated NIC for each subnet, you may find that you can host a variety of virtual machines all bound for different networks while conserving network ports. This is especially helpful when you have limited NIC ports from space-saving designs such as blade servers.

Microsoft Hyper-V has helped move virtualization under the wing of the Windows administrator without the need for extensive specialized training. Just because it's easy to setup doesn't mean there aren't more complex options to consider. The option to virtualize comes with so many positives that it's easy to forget about the drawbacks until they occur in a production emergency. To avoid this scenario, make the right decisions up front and you'll be well on your way to a fully functional Hyper-V environment.

More on this topic

  • What's new:
    Inside Hyper-V R2  
  • Spotlight:
    Virtual machine security  
  • Comparisons:
    Hyper-V vs. VMware  
  • Tools:
    Top five free utilities

Eric Beehler has been working in the IT industry since the mid-90's, and has been playing with computer technology well before that. His experience includes over nine years with Hewlett-Packard's Managed Services division, working with Fortune 500 companies to deliver network and server solutions and, most recently, IT experience in the insurance industry working on highly-available solutions and disaster recovery. He currently provides consulting and training through his co-ownership in Consortio Services, LLC.

Dig Deeper on Microsoft Hyper-V management