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

Three Hyper-V R2 configuration errors to avoid

Steer clear of these potential missteps during Hyper-V R2 configuration in your customer’s environment, such as under-subscribing network resources, to sidestep bigger problems in the future.

One of the most difficult parts of being a managed service provider (MSP) is getting into the minds of your customers. Finding the subtle differences between what they say they want and what they actually need is what separates the good MSP consultants from those who just go through the motions.

Reading customers’ minds can be a challenging activity, particularly when they are vehement about having you configure the wrong things when you know what you are doing is right.

You can find Hyper-V R2 configuration mistakes in nearly every control panel. Although none of these are the true “this will destroy the data center” mistakes, configuring them incorrectly can harm your customer’s environment. Consider these top three misguided efforts that consistently appear in my consulting travels:

1. Enabling CSVs without considering the consequences. 
Cluster Shared Volumes (CSVs) are Microsoft’s solution for resolving the “one virtual machine (VM) per logical unit number (LUN)” limitation that was an issue in Hyper-V R1. Enabling CSVs on a LUN sidesteps Windows Failover Clustering’s shared-nothing model. It enables Hyper-V hosts to coordinate access to VMs among each other.

Although this configuration seems like a useful idea for solution providers to improve management, nobody wants to be creating LUNs for every new VM, and enabling CSVs can have future consequences.

The first consequence is that some backup solutions don’t function with CSV-enabled LUNs. The number of those that do is increasing every day, but verification is a must.

Next, some types of anti-malware scanning on C:\ClusterStorage, which is the storage location for VMs on CSV-enabled volumes, can lead to issues. CSV can also be a fragile file system, and it is generally a good idea to limit any direct-file accesses and allow Hyper-V’s management tools to interact with virtual hard disks.

2. Enabling anti-malware or defragmentation without compensation for virtualization.
CSVs are a native feature that you must be careful with, but anti-malware and defragmentation are another set of common tools everyone uses that don’t work as well in your customer’s environment when paired with virtualization. 

The problem is resource economics. Anti-malware and defragmentation administrative tools can be a burden because of heavy resource consumption. Turning these tools on without tuning their processor, memory usage or scheduling may lead to their activities affecting VM performance.

Although beginning a scan on one machine might consume a minimal percentage of processor resources, multiplying that percentage across 10 or more VMs can consume every resource the physical host has to offer. When building a Hyper-V R2 architecture for your customers, don’t discount the effect these tools can have on overall performance.

3. Under-subscribing network resources, either to production or storage traffic.
Users under-subscribe network resources in their environments all the time, particularly in environments with network-based storage as a secondary option. Most environments today have moved or are moving some portions of their storage to network-based storage-area networks (SANs). Network device prices have dropped so significantly that even smaller customers can afford them.

But connecting a server to a SAN for secondary storage has fewer performance requirements than connecting a Hyper-V R2 server to its VM storage. The difference here is in Input/Output Operations per Second (IOPS), a metric that represents the speed of a connection. When a Hyper-V R2 host isn’t configured with a fast enough storage connection–one without enough IOPS–VMs’ speed on that host will slow to a crawl.

Potential connection problems aren’t just limited to storage. This is typically less of an issue, but production networking connections can also suffer. Never collocate production networking with storage networking through the same physical interfaces.  You should always segregate storage traffic and its network interface cards (NICs) from production network traffic and its NICs.

Segregating across completely separate paths is an even better option. Not doing this may lead to an environment where storage consumption affects production networking. And in that scenario, everyone loses.

About the author
Greg Shields, MVP, vExpert, is a partner with Concentrated Technology. Get more of Greg's tips and tricks at

Dig Deeper on Server virtualization technology and services

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.