Running Windows on a Hyper-V virtual machine can naturally never be as fast as that same version of Windows on host machine’s real physical hardware. However, by tweaking virtual machine settings, you can greatly impact the speed and functionality of a virtual machine. As a Hyper-V enthusiast, I want to share my tips for making virtual machines run smoother and faster.
VHD storage location
It is recommended to store virtual hard disks on an SSD, if possible. Storing virtual hard disks on an HDD affects the time required to install Windows onto a VM, and its boot and restart times. It also affects the time required to install software, and large Windows updates like full feature upgrades.
Using my laptop (an HP ProBook 470 G5) as an example, when the VHD is on an SSD, installing Windows 10 takes about 7 minutes from start to desktop, whereas that same VHD on an HDD requires over 20 minutes. Booting a Windows 10 VM from SSD takes about 40 seconds, and restart about a minute. Booting VM from an HDD, it takes almost two minutes to boot, and over three minutes to restart.
However, don’t worry if you do not have an SSD. Under normal use, virtual machine with its VHD on an HDD works nicely, once it has been tweaked with optimal settings.
Hyper-V New Virtual Machine Wizard prompts user to select either Generation 1 or Generation 2 for the new VM. Generation 1 emulates a BIOS-based computer with an MBR disk, Generation 2 a UEFI machine with a GPT disk. In all my years of extensive use of Hyper-V, I have never noticed any difference in Generation 1 and Generation 2 VM performance.
There are two things to consider when deciding the VM generation. First, MBR disk (virtual hard disk) size limit, the VHD can be maximum 2 TB. Second, Generation 2 VM requires a 64-bit guest operating system.
I use only Generation 2 virtual machines, except when installing a 32-bit operating system, in which case I must use Generation 1. But, really, you can use Generation 1 for every VM, not noticing any difference in performance.
Differencing Disks is recommended if your SSD is relatively small. Differencing disks means that a VM is stored on two different virtual hard disks, a so called Parent Disk containing the base Windows installation, and a Child Disk which contains all user profiles and data, settings, customizations and software. The VM boots from the Parent Disk where the base Windows is installed, and then passes control to the Child Disk.
Storing the Parent Disk on an SSD, and Child Disk on HDD is a good compromise. You save storage space on the SSD, yet get a faster VM than if only an HDD was used to store virtual hard disk(s). In addition you can save a lot of the storage space that your virtual machines use in general; one Parent Disk can be used for an unlimited number of Child Disks.
Here’s an example. Let’s say you have Windows 10 version 1909 installed on a Parent Disk. You’d like to use four virtual machines, all available Insider Ring builds (Release Preview, Slow Ring, Fast Ring), and one for the 1909 public release.
Version 1909 on the Parent Disk takes about 11 GB. Creating four new virtual machines with Child Disks using this Parent Disk, this 11 GB is saved on each VM. You can then opt one VM in for Release Preview, one for Slow, one for Fast, and make one for the public release.
If all four virtual machines were using a normal VHD, they would each have over 11 GB virtual hard disks when first booted to desktop, a total of about 45 GB before any software would be installed. But, using a Child Disk, each VM requires less than 2 GB for its VHD, because the base Windows installation on Parent Disk is used instead of complete Windows on the Child Disks.
In this example, you saved about 25 GB of storage space (11 GB + 4*2 GB = 19 GB, instead of 4*11 GB = 44 GB).
If you have an SSD for parent disks, and a fast USB3 external HDD, you can store your child disks on that external HDD. Hyper-V has no issues in running virtual machines from an external disk.
Virtual RAM (vRAM)
By default, Hyper-V virtual machines are set to use 1 GB starting vRAM and dynamic memory. Dynamic memory means that a VM only uses as much vRAM as is currently required. A VM with default settings starts with 1 GB vRAM, then assigns it more vRAM when needed, and reduces the amount of vRAM when additional memory is no longer required.
Dynamic memory can fluctuate between set minimum (default is 512 MB) and maximum (default is ridiculous 1048576 MB / 1 TB) values. Both min and max vRAM can be set as the user prefers.
Hyper-V monitors memory demand for each VM that uses dynamic memory. This demand depends on what’s happening on any given VM; if you run Word and Excel at the same time, the demand increases and Hyper-V assigns more vRAM to that VM. This is theoretically very good, but it would require all software and VM actions to report demand in real time.
Unfortunately, this is not the case. For instance, running a Windows feature upgrade should tell Hyper-V that for it to work, the VM needs more RAM, in case VM has less than 2 GB available at the moment the upgrade is started. But, Windows Update does not report its demand correctly, so therefore a user might see something like this:
In the case of a Windows feature upgrade, it’s not so much Windows Update not demanding enough dynamic vRAM for the VM, as the fact that the demand is made too late. The actual demand works a bit delayed, so the VM has no time to adjust for greater memory demand when it’s needed. A simple workaround is to shut down the VM, disable dynamic memory, and assign enough static vRAM to get the VM upgraded.
A bit more complicated workaround is to launch a bunch of software to increase the demand, and when the demand has increased the VM’s vRAM (shown in Hyper-V Manager under column Assigned Memory) over the required amount, close all open software and run the upgrade again.
You can also increase the available dynamic vRAM by changing the Memory Buffer size in VM settings. By default, a dynamic vRAM buffer is 20%. It means that VM is always assigned 20% more vRAM than it currently demands; if memory demand is 1 GB, VM is assigned 1.2 GB:
A practical way to follow memory demand in real time is to use Windows Admin Center (WAC). Managing virtual machines in WAC shows you real time memory demand and assigned vRAM for each VM. In the next screenshot, a Windows 10 Insider VM with default settings has been booted to the desktop and left idle. Its current memory demand is 707 MB, so it has been assigned that plus the default 20% buffer, 852 MB:
Memory weight, on the same settings page as memory buffer, rules which VM has priority to access host RAM and its own vRAM. I recommend leaving it as set by default, with each VM memory weight in the middle at 50%.
Dynamic memory with low minimum vRAM value makes it possible to run more virtual machines simultaneously. However, as it can make virtual machines quite slow, I prefer static vRAM on my virtual machines, never using dynamic memory. I assign 3 or 4 GB static vRAM for each Windows 10 VM, 2 or 3 GB for Windows 8.1 VM, 2 GB for Windows 7 and 1 GB for any Linux VM. Windows 10 x64 runs really nicely with 3 GB, Windows 7 & 8.1 with 2 GB.
To calculate how many virtual machines I can run at the same time, I use a simple formula. I have noticed, that Windows 10 on this laptop runs really nicely when it has 5 GB RAM available. I’ll add a 2 GB “buffer”, which leaves me 9 GB to use on virtual machines of the 16 GB total RAM.
For me, it means that I can run three virtual machines with 3 GB vRAM at the same time, or two using 4 GB. I quite often have one VM running Windows 7 (2 GB), one 8.1 (3 GB), and one Windows 10 (4 GB). All virtual machines run smoothly, and the host has enough RAM for its needs.
It is of course up to you if you decide to use dynamic memory. My recommendation is at least to disable it when installing Windows, or when doing a feature upgrade.
Virtual Processors (vCPU)
The maximum number of virtual processors you can assign to a single VM is the number of logical processors on your host. Open Task Manager, select Performance tab, and select CPU to see how many logical processors you have available:
That is the maximum number of virtual processors you can assign to a single VM, one vCPU per one host logical processor. If trying to assign more vCPUs to a VM, Hyper-V shows a warning:
A Virtual machine will not start if it detects too many virtual processors.
Everything in Windows runs and executes in threads. Each thread can handle one instruction at any given time, the system then decides which thread gets executed next, You can read more about this here. A VM can only use an assigned vCPU, basically a logical processor or thread on a host, when that thread is idle, not used by the host. What this means is that a VM can be totally unable to work if it and other virtual machines running at the same time demand all available threads. Because there are no idle threads on the host, a VM suspends its vCPU until a matching thread on the host becomes available.
One good “rule of thumb” is to use a 2 to 1 ratio, and assign each VM 1 vCPU for each 2 host logical processors. In my case, with 8 logical processors, I usually assign 4 vCPU per VM. This applies to all Linux and post-Vista virtual machines. Those who still run Windows XP or Vista virtual machines, remember that they do not accept more than 2 vCPUs. For some heavy duty Windows virtual machines used for image customization and other deployment tasks, I assign the maximum, 8 vCPU.
Monitoring the virtual processors, you can see a clear difference when the number of vCPUs is increased. First, a VM with 4 GB vRAM and 2 vCPU, running a feature upgrade:
Next, the same VM but now with 8 vCPU, running the same upgrade task:
The recommended maximum number of vCPUs in use at the same time is 8 times the number of host logical cores. In my case, with 8 logical processors, that means that my running virtual machines should not exceed 8*8=64 vCPUs at any given time. However, this is just a theoretical limit, more a recommendation than a hard and fast rule. As long as you have enough RAM and processing power on your host, you can run an almost unlimited number of virtual machines at the same time.
A checkpoint in Hyper-V stores the current state of a VM. When a checkpoint is applied, Windows on that VM is restored as it was at the moment the checkpoint was created. This is very practical when testing software or Windows features; changes can be discarded simply by applying an earlier checkpoint. For more information please read the full Ten Forums Hyper-V Checkpoint tutorial: Create and Use Hyper-V Checkpoints in Windows 10
Hyper-V uses two different types of checkpoints, Standard and Production. A Standard Checkpoint is basically the same as a Windows 10 restore point; when created, it captures the current state of Windows 10, but not that of open applications and processes.
My recommendation is to always use Production Checkpoints. A Production Checkpoint captures the current state of Windows, and all software and processes running at the time when checkpoint is created.
An example: if you are in the middle of copying a large file from network to VM, and you create a Production Checkpoint when file copy progress is at 44%, when you later apply that checkpoint, the file copy continues from that 44%. The same with an open not saved Word document; when the checkpoint is applied, the document will be open on the VM’s desktop.
By default, Hyper-V uses / creates automatic checkpoints. I strongly recommend to disable this feature before running a new VM for the first time. In all the time I have used Hyper-V, I have only found one scenario where automatic checkpoints were useful. I do a lot of Windows image customization and deployment tests. Creating a new, clean and empty VM with automatic checkpoint lets me to restore the virgin state of that VM when deployment does not work, and I must repair the image. Other than that, I think automatic checkpoints in Hyper-V are its most unnecessary feature.
My recommendation for checkpoint settings. You should check this every time before starting a new VM for the first time:
Export & Import Virtual Machines
Especially if you have activated your Windows virtual machines, it is important to preserve them and their activation status by exporting them. To export a VM to an external disk, see this tutorial: Export Hyper-V Virtual Machine in Windows 10
After exporting a VM, it can be deleted from Hyper-V Manager if it’s not currently needed. When that VM is again needed, import it back to Hyper-V: Import Hyper-V Virtual Machine in Windows 10
A hard disk on a physical machine, or VHD on a virtual machine on an activated Windows 10 system can be replaced without losing the machine’s activation status (digital license). What I always do when I have activated a Windows 10 virtual machine is to remove its VHD, and export it without any disk. I now have an activated Windows 10 VM with no disk. When I want, I can just import the VM, attach a new VHD to it, and install the same edition of Windows 10 it had when activated. New installation will be automatically activated, based on the existing digital license.
I even have a few exported virtual machines on a safe storage which have digital licenses for Home, Pro, Education and Enterprise editions; when imported back to Hyper-V, I can install any of the four editions, all of them automatically activated, or install all four editions on VM in multi boot, all activated.
Ideal VM settings
The ideal settings for a VM are subjective, based on multiple factors. My recommendations are based on the following factors:
– Windows 10 x64 host
– 16 GB RAM
– 8 logical processors
– An SSD and an HDD
– Guest (VM) OS Windows 10 x64
For those specs, my recommended settings for a Windows VM, which I have found to be quite good are as follows:
– 4 GB vRAM
– 4 vCPU
– Disable Secure Boot
– Production Checkpoints
– Disable Automatic Checkpoints
– Install on Differencing disks, Parent Disk on SSD
It is extremely important to leave the host with enough resources to run smoothly. Never run virtual machines with less than 2 GB available for the host. That is the absolute minimum, I recommend always having at least 4 GB for the host. What this means is that if you only have 4 GB of RAM, never assign more than 2 GB for a VM, and from 8 GB RAM, never more than 4 GB.
One very nice feature in Hyper-V is the possibility to select a virtual machine’s Stop Action and Start Action.
If you have a virtual machine that is normally always on and running, you can select to save its state when the host is turned off, shut down or restarted:
This is the default action. You can also select to automatically turn a VM off, or shut it down, when the host is turned off / shut down / restarted.
Depending on your selected Stop Action, the VM will be automatically started at the next boot (default action) if you so wish:
Accepting defaults for both Stop and Start Action, the VM which was running when you shut down the host, will be automatically restored to its last state when host is rebooted.
To boot a VM faster, save its current state by clicking the Save button:
This saves the current state of VM. When started next time, instead of clean boot, the VM is restored fast to its saved state.
That’s it, geeks. Happy virtualization!
Author: Kari Finn
A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.