As I’ve recently noticed some confusion around the difference between the terms Hyper-V VM versions and Hyper-V VM generations, I like to clarify a few things and then talk a bit more about each. Let’s start with Hyper-V VM generations.
Hyper-V VM generations
Hyper-V VM generations are directly related to VM (virtual) hardware. For the first Hyper-V releases, developers had to come up with some sort of predefined virtual hardware. They wanted to provide Hyper-V-platform compatibility with the underlying hardware, so the Hyper-V would be able to run problem-free right out of the box. They also wanted the guest OS to recognize VM virtual (emulated) hardware easily to give the end user a large variety of supported guest operating systems. This was called generation 1 virtual machines and you would have recognized a lot of hardware that you would see on a true physical machine also.
By the Windows Server 2012 R2 release Hyper-V team decided to reevaluate the virtual hardware set to eliminate obsolete devices and build a platform that, theoretically, would take less resources from the physical system due to a smaller number of virtual components to emulate. To distinguish this new and revised setup from the earlier setup, it is called the generation 2 Hyper-V VM, while the previous setup is referred to as the generation 1 Hyper-V VM.
Let’s see what is inside:
Removed: BIOS firmware, network adapter (based on Intel/Tulip 21140), IDE, floppy, DMA, i8042 keyboard, PS/2 mouse controllers, S3 video, PIT, PIC, Super I/O, PCI bus, speaker and more
Added: UEFI firmware, SCSI controller, new software-based DVD device and new network controller
Benefits of generation 2 VM:
- Less attack surface and better security
- Less resources consumption in the parent partition of the hypervisor
- Faster guest OS boot and guest OS installation because no emulation needs to be done (UEFI firmware initializes faster than BIOS and generation 2 VM always use VM bus for I/O)
- New functionality for VMs: Secure boot (enabled by default), boot from an SCSI virtual hard disk, boot from an SCSI virtual DVD, PXE boot by using a standard network adapter, and UEFI firmware support
Disadvantages:
- Generation 2 VMs can’t be used as virtual desktop templates
- No support of RemoteFX
- Limited support for guest OS: Only 64-bit versions of Windows 8 and Windows Server 2012 and higher (Linux family was not supported at the very beginning, but the situation has changed since then. Read more relevant information here.)
Considerations:
- There is no guest OS performance gain promised. Users may find a performance boost during operations, which I mentioned earlier in the Benefits of generation 2 VM
- There is no requirement to have a physical host with UEFI firmware to use a generation 2 VM; hosts with BIOS firmware can accomplish this just as well.
- The guest OS application is agnostic to VM generation.
- There is no support for booting from a physical pass-through DVD drive. Booting happens only from an SCSI controller (.iso image or .vhdx bootable disk).
- The generation 2 VM can only boot from .vhdx disks and can process .vhd as data disks.
Comparing the generation 1 VM with the generation 2 VM is like comparing an old laptop with a new one at some point. The newer generation is smaller with new components inside, but at the same time it does the same things (application installation, internet browsing and so on) that you could do with the older generation.
Ok, I hope you got the idea of what a Hyper-V VM generation is, and now it’s time to switch to Hyper-V VM versions.
Hyper-V VM versions
A Hyper-V VM version is also known as a VM configuration version. This term represents the VM configuration, saved state and snapshots compatibility with the Hyper-V host version. In other words, this defines the hypervisor features that are available for a certain VM.
The newest VM configuration versions aren’t able to run on previous host versions, and older configurations can run on new hosts, but with limited functionality because newer hosts only provide backwards compatibility.
In a mixed environment of Hyper-V hosts on different versions of a Windows desktop OS and a Windows Server OS, this versioning can create confusion. Since its debut in Windows Server 2008, Hyper-V brought the new Hyper-V VM version in every major release or update. For example, Hyper-V on Windows Server 2008 has a 1.0 VM configuration version. On Windows Server 2008, SP1, version 2.0, and Windows Server 2012 R2 has the 5.0 version. Lately, Windows Server 2016 Technical Preview and Windows 10 with its updates introduced VMs with configuration versions from 6.2 to 8.0.
For previous Hyper-V versions, a VM configuration upgrade was performed within the host upgrade. New versions leave it up to an administrator.
The meaning of this is simple: new Hyper-V features are only available with a certain version of VM configuration. There is no reason you should postpone upgrading, unless you run a mixed Hyper-V environment and plan to migrate VMs between hosts with different OS versions.
For example, a secure boot for Linux VMs is working for VMs starting from the 6.0 configuration version, and PowerShell Direct from the 6.2 version. More details can be found in this article.
NOTE: The VM configuration version can only be updated, not downgraded.
A few PowerShell cmdlets can help you with VM configuration versions. Check the versions for all VMs at the host: Get-VM | select name, state, version. Perform manual VM configuration conversion thus: Update-VMVersion -Name “VM name.”
NOTE: The VM should be turned off prior to this operation.
Conclusion
Hyper-V Manager and PowerShell cmdlet (Get-VM) can always help you define a VM’s generation and configuration version. Don’t overlook it as you move forward. Good luck!
