Getting more storage capacity for data or applications is not a problem. The question is: how fast your apps can run? That’s why performance becomes a number 1 demand for the majority of system administrators. So it’s not a big deal finding an article on improving Hyper-V and VMs performance, the challenge is to get an up-to-date info and modern insights. That’s why in this post, I’m gonna give some advice on boosting your Hyper-V infrastructure performance – from host to virtual machine and the overall cluster optimization. This might come in handy when building a new Hyper-V based environment or even improving the existing one. Let’s put the pedal to the metal!
MAKING HYPER-V RUN AT FULL THROTTLE
Here’s a brief overview of what I’m gonna describe in this article. Sequence matters!
1. Host Optimization
2. Boosting Hyper-V server
3. Maximizing network throughput
4. Squeezing max out of your underlying storage
5. Accelerating VM performance:
Security – performance impact
Setting a proper memory amount
Configuring virtual processor
6. Improving Hyper-V cluster performance
I’ve used Microsoft Windows Server 2016 v1607 (OS build 14393.0) as a basis.
1. HOST OPTIMIZATION
Instead of starting straight with Hyper-V, you should really take some time to optimize Windows Server itself.
You should keep an eye on the updates of the OS and get a detailed information about the exact components of the system that are to be updated. The Microsoft forum and other credible internet resources would be extremely helpful in discovering whether those updates have any issues. In case the updates are functioning smoothly and cause no problems, you can easily proceed, however, do not forget to create a recovery point beforehand.
The same goes for the device drivers – use only the latest versions.
Do not install unnecessary roles that will not be used on Windows Server.
Do not install or simply delete supplementary software that will never be used.
2. BOOSTING HYPER-V SERVER
If you use a VM to launch applications with their own replication technology (i.e. Active Directory, Microsoft SQL Server), do not use Hyper-V Replica then. Their native replication technologies will do better.
Higher performance can be ensured with the utilization of several disk arrays. For instance, one can be used for the operating system, while another one for the VMs.
Change the default location of the VMs to the alternative non-OS disk array.
Additionally, if you’re looking to scale Hyper-V on Windows Server 2016, take a look at this article.
3. MAXIMIZING NETWORK THROUGHPUT
I’m not gonna cover the process of Virtual Switch creation as there is a straightforward guide already by Microsoft, so please check it out here.
I recommend using at least 2 network adapters to distribute the workload effectively: one IP address is used for connecting to the virtual machine, another IP address is for data exchange between the VMs.
4. SQUEEZING MAX OUT OF YOUR UNDERLYING STORAGE
As you probably know, Hard Disk Drive is the slowest component in the network.
RAID-0 is the fastest RAID type and provides the maximum capacity but does not ensure reliability.
RAID-10 is considered as the fastest and the most reliable at the same time, but it makes only the half all disks available for active utilization.
RAID-6 gives slower performance than RAID-0 and RAID-10, still it delivers a greater capacity.
Depending on your peculiar tasks and disks available, you can decide which exact RAID type is the most applicable in your case.
As for the file system, I prefer NTFS because ReFS is not mature enough.
The best way to increase the storage speed is to consider utilization of fast disks such as SSDs or NVMe.
5. ACCELERATING VM PERFORMANCE
OK, let’s move on to our VMs. When you’re creating a new VM in Hyper-V, it is possible to choose one out of two virtual machine types: Generation 1 or Generation 2.
I strongly recommend creating the Generation 2 VM for a number of reasons.
First, you will be able to load VMs from the SCSI controller, which is much faster than loading the VM from the IDE controller (used in Generation 1). Secondly, Generation 2 VM is based on the VMBUS and VSP / VSC architecture of the boot level, which significantly increases the overall VMs performance.
Once the VM is created, its type cannot be changed. For more information about the compatibility of operating systems and VM types, please refer to this article.
Also, do not create a Checkpoint because it negatively influences VM performance.
SECURITY – PERFORMANCE IMPACT
Do not use virtual machine encryption because it degrades the performance.
SETTING A PROPER MEMORY AMOUNT
Do not use Dynamic Memory for increasing the VM performance.
Moreover, avoid allocating extra memory resources for the VM until required.
CONFIGURING VIRTUAL PROCESSOR
In the Processor parameter of the VM settings, you can indicate a needed number of vCPUs assigned to the VM.
There is no difference in processor parameters configuration between Generation 1 and Generation 2.
In case you want to edit those parameters, switch off the VM.
The Number of virtual processors parameter indicates the number of virtual processors inside a VM. The correct number of processors depends on the type of service provided and the host processor.
You should be aware of the specific requirements for the service operation that you are planning to launch.
To start with, check how many cores are there on your processor and how many are needed for the service operation. Start with one core.
To determine whether additional cores are required, analyze the VM core workload. To measure this, go to the VM settings (with some service running of course) and check the current workload. In case it exceeds 80 %, an additional virtual processor is required. If it’s somewhere between 50-70%, well…take a look if the service runs properly.
In case there are no delays in the service operation, leave everything as it is. Otherwise, add one more virtual processor unit and check its performance afterwards.
Apparently, it is not possible to analyze all probable situations because the resources are customized in each particular case.
However, do not assign 100 virtual processors to each VM just because you can. This will influence its performance negatively.
Let’s shift to another parameter you can use to optimize the VM performance – Virtual machine reserve (percentage). This is the percentage of logical processor resources that Hyper-V will reserve for the virtual machine. For instance, in case your VM has 1 virtual processor and you set this parameter for 100%, the will be provided with one CPU core. When Hyper-Threading is on, VM will be then granted one logical core of the CPU.
Percent of total system resources shows the percentage of total system resources utilized (well obviously). This parameter fluctuates depending on the number of virtual processors indicated in the Number of virtual processors parameter and the value of Virtual machine reserve (percentage).
The formula is the following: CPU of VM/Total physical CPU * VM reserve. So we have an 8-core processor: 1 / 8 * 100 = 12,5.
In case Hyper-Threading is on, then formula is modified: CPU of VM/Total logical CPU * VM reserve.
Next on the list is the Virtual machine limit (percentage) parameter. This setting limits the amount of the host’s logical processor resources that can be consumed by a VM.
For example, in case your virtual machine has only one virtual processor and you set 100% for this parameter, this VM will not be able to get more than one core of the processor. In case Hyper-Threading is on, the VM will not be able to operate with more than one logical core of the processor.
Such limitation is reasonable when one VM tends to utilize more resources than provided. The default value is set as 100. When you put 0 value, the VM will not be limited to the amount of processor resources and will use them when needed.
The formula is the following: CPU of VM/Total physical CPU * VM limit. In our case: 1 / 8 * 100 = 12.5.
In case Hyper-Threading is on, the formula will be modified: CPU of VM/Total logical CPU * VM limit.
Similar to the previous situation, Percentage of total system resources shows percentage of the total system resources utilized. This parameter changes depending on the amount of virtual processors indicated in the Number of virtual processors and the value indicated in the Virtual machine limit (percentage).
Relative weight is a configurable parameter for processor resources management, its value ranges from 1 to 10000.
Relative weight remains inactive till several VMs start fighting for the processor resources. Subsequently, when the Relative weight value is 100 for the first VM and 200 for the second VM, they both will obtain all necessary processor resources in case those are available. When there is a competition for the resource utilization, then a VM with higher relative weight value obtains a greater share.
Relative weight is especially important when it is necessary to determine which VMs are “important” and which are “ordinary”. That way, your mission-critical services will obtain processor resources first.
It should be noted that utilization of relative weight must be standardized – if you stick to the values within the range between 100 and 200 on one node, it will not be appropriate to set values between 500 and 1000 on another node. In case of Live Migration, a VM with a mission-critical service may have a lower relative weight value than a VM with less important services.
Note that those parameters are set individually in each infrastructure so there is no “strict” advice on the case.
The Processor compatibility parameter is responsible for enabling/disabling processor compatibility mode in case of virtual machines migration between the nodes with different processors generations. The compatibility mode does not support migration between AMD and Intel hosts.
The processor compatibility is deployed within software and when enabled, limits all advanced processor functions such as SSSE3 and higher, POPCNT and Misaligned SSE.
That way, refer to the compatibility configuration only when it is required.
Note that the processor compatibility mode is switched off by default.
NUMA (Non-Uniform Memory Access) is a scheme of implementing the computer memory, which is used in multiprocessor systems when memory access time correlates depending on its location relative to the processor.
For more information about NUMA configuration in Hyper-V, please refer to this article.
In case you are not sure about how to configure NUMA, use the “Use Hardware Topology” button.
Now that we’re done with all possible processor configurations, let’s switch to storage. Use disks of the ‘fixed’ type to reach the maximum performance rates.
Do not use an outdated controller in the Generation 1 VMs. When the VM of Generation 1 type is created, the disk will be located on IDE controller by default.
Do not perform a full disk defragmentation. Minimal defragmentation performed by Windows is sufficient. The process of defragmentation negatively influences longevity of the hard disk because of the numerous write operations. You don’t want suddenly finding out your disk is “dead” and having to go buy a new one, right? When you really need to perform defragmentation, use “Live Migration” to move the VM to another host and format the disk. Sure, it will take longer but it still would be more effective than regular defragmentation.
6. IMPROVING HYPER-V CLUSTER PERFORMANCE
OK, from simple to complex – now we’re ready to optimize the overall cluster performance. Perform the process of validation before creating the cluster. Obviously, you do not need to fix each warning, however, you need to explore the result thoroughly.
Use the same hardware on each node to reach higher performance rates. Well, at least you won’t have to play around with processors compatibility.
For Hyper-V, each cluster node is supposed to utilize at least 2 IP addresses. One of them should be designated as the management IP address, which means that it must have a valid default gateway. Another IP address may stand for Live Migration so that there was no overload on the main channel.
The Compression option for data transfer uses data compression to reduce the amount of data transferred over the network and involve less processor cycles, which leads to increased migration time. If you do not have any physical adapters supporting RDMA, use the Compression option for Live Migration.
The SMB option for data transfer over the network does not assume compression, however, it uses SMB Direct instead. SMB Direct uses RDMA capabilities, which means that data transfer will be faster with minimum use of the host CPU. Subsequently, if you have physical adapters supporting RDMA, choose SMB option for Live Migration.
I would like to admit that settings mentioned above were used in my infrastructure and therefore are considered as appropriate from my point of view. Probably, other settings would be more applicable within your particular environment.
If you stick up to the recommendations provided in this article, you will definitely experience improved Hyper-V performance in your existing infrastructure.
Anyway, this article should not be perceived as an ideal guide to improve the Hyper-V performance. Therefore, you are welcome to join the discussion, send your comments and suggestions. I am sure that you also have ideas on how to optimize the Hyper-V performance.