Hyper-V generation 2 virtual machines – part 1

This is another one of my blog-post series, this time taking a dive into generation 2 VMs, a new feature in Hyper-V in Windows 8.1 that I’ve been working on as Program Manager for throughout the release. In the end, it turned into a small novel rather than a few short posts, but I hope you find them valuable. Especially when you get to the part 10!

Part 1: Introduction to generation 2 virtual machines
Part 2: Networking and boot order
Part 3: Storage
Part 4: Keyboard for Windows 8 & Windows Server 2012
Part 5: Kernel debugging
Part 6: Secure Boot
Part 7: FAQ
Part 8: Manually migrating generation 1 virtual machines to generation 2
Part 9: Installing from ISO
Part 10: Utility for converting generation 1 virtual machines to generation 2 (Convert-VMGeneration)

Why have we introduced generation 2 Virtual Machines?

The main reason for introducing generation 2 VMs is a strategic bet by the Hyper-V team to have a platform upon which we can build upon in future releases, while introducing a number of improvements in this release as well.

If you look at previous virtualization solutions from Microsoft, including Virtual PC, Virtual Server, and all earlier releases of Hyper-V, from a VM perspective, the underlying hardware is relatively old, emulating an Intel 440BX chipset. Interestingly (perhaps!), I only recently discovered that the codename for this chipset was ‘Seattle’. Kind of appropriate with Redmond being the easterly younger-brother city to Seattle, and where I now call home!

Of course, we have introduced many features to make guest operating systems run well in a virtual environment, such as software based I/O and kernel enlightenments. There are plenty of posts and documents which explain that in more detail though, so I won’t go into depth in these posts.

The reason for using emulated devices is that most operating systems can run on that hardware. And that was important to be successful as a virtualization platform. However, it meant compromises had to be made.

Generation 2 VMs have a revised set of virtual hardware which move away from previous limitations, unleashing new possibilities in the future. We still have full compatibility by keeping the previous hardware intact in the form of “generation 1” virtual machines.

How to create and distinguish between a generation 2 and generation 1 VM.

In Hyper-V Manager, we have added an additional step in the New Virtual Machine wizard:

clip_image002[4]

In PowerShell, you use the “Generation” parameter to New-VM. If the parameter is not specified, a generation 1 VM will be created.

PS C:\> New-VM -VMName Generation2 -Generation 2

Name State CPUUsage(%) MemoryAssigned(M) Uptime Status
---- ----- ----------- ----------------- ------ ------
Generation2 Off 0 0 00:00:00 Operating normally

Once a VM has been created, in Hyper-V Manager, the generation is shown on the summary tab when a VM is selected:

clip_image004[4]

To determine the generation of a VM using PowerShell, the ‘Generation’ property is exposed on the VMObject returned by Get-VM

PS C:\> Get-VM -VMName Generation2 | fl Name,Generation

Name : Generation2
Generation : 2

The generation is also exposed in the VirtualSystemSubType field in the Msvm_VirtualSystemSettingData class. The values are “Microsoft:Hyper-V:SubType:1” for a generation 1 VM, or “Microsoft:Hyper-V:SubType:2” for a generation 2 VM.

 

What is different about generation 2 Virtual Machines

1. The firmware

First, we took a decision to change the system firmware. Generation 1 VMs use a PCAT BIOS, as have the majority of OEM PCs until recently. While technically there is nothing wrong with BIOS, it has limitations. Especially when you consider in our case it’s written in 16-bit assembler. This makes ongoing enhancements extremely difficult. It is also relatively slow to initialise taking up a significant proportion of virtual machine power on time, and relatively inefficient consuming a fair number of CPU cycles during this initialization.

Instead of BIOS, we went with UEFI firmware, which is actually a logo requirement for OEMs to achieve Windows 8 & 8.1 logo. One of the big advantages of using UEFI is that it is written in a high-level language which makes if far easier to maintain and extend. Our implementation is based on TianoCore, EDK II and is a UEFI 2.3.1 implementation with necessary modifications and bug-fixes.

UEFI has a number of other advantages such as removing the 2.2TB MBR partition limits for the boot volume. I will go into that in a little more detail in a future post.

Our UEFI firmware in Windows 8.1 does not have a CSM (Compatibility Support Module). In terms of how the UEFI forum defines platform types, this makes our implementation “Class 3”. We do not have a 32-bit implementation, which means that only 64-bit Guest Operating systems would be able to run in this environment. I will cover what operating systems are actually supported later.

2. The devices

There are some obvious devices we removed. For example, the legacy network adapter (which is an emulated device based on a DEC/Intel/Tulip 21140). Then we removed the IDE controller. And the floppy controller plus associated DMA controller. And the serial controller (COM ports). These are all things you can directly see in the VM settings.

Then we changed other devices such as removing the legacy i8042 keyboard controller (which has an interesting side effect I will talk about in a future part), PS/2 mouse, S3 Video, the Programmable Interrupt Controller (PIC), the Programmable Interrupt Timer (PIT), the Super I/O device on which floppy support relied. We actually went even further by removing the PCI bus as well. For good measure, we also removed the speaker and the numerical co-processor. We also revised ACPI.

Of course, when you rip this much out, you may initially think ‘could an operating system boot in this environment?’. With just the above changes, the answer would be no. Primarily because the most common ways of booting a generation 1 VM are a disk/VHD attached to an IDE controller, an ISO/DVD drive attached to an IDE controller, or PXE boot from the legacy network adapter. I’m ignoring boot from floppy (.VFD) – I’m sure not many people do this these days!

Given that both IDE and Legacy NIC are no longer present, we had to introduce alternate boot mechanisms, and a new DVD device. We extended the UEFI firmware to be aware of software based devices (ie those using VMBus), and support booting from our software-based SCSI and Network controllers, plus the new software-based DVD device.

To give you a feel of what this means inside device manager, the screenshot is from a Windows Server 2012 virtual machine running on Hyper-V in Windows Server 2012, with up to date Integration Services installed. This is relatively typical of what you would see on any VM you have running today in Hyper-V.

clip_image006[4]

The following is a screenshot from a generation 2 Windows 8.1 virtual machine running on Hyper-V in Windows 8.1

clip_image008[4]

You may be asking at this point, so what? In fact, I’d be surprised if you weren’t asking that question. A big advantage is that the security attack surface of a generation 2 VM is lower than that of a generation 1 VM. It moves us closer towards accountability of compute resource by not consuming so many resources in the parent partition or Hypervisor through emulation. And it makes VM management decisions easier. This last point is where I will pick up in the next part.

Cheers,
John

A short after-story.... A lot of people incorrectly abbreviate generation 2 virtual machines to ‘gen 2’, or capitalise the G when it’s not at the start of the sentence, or even use just “G2”. Even I am occasionally guilty. The correct terminology is a generation 2 virtual machine. Internally we did have a few other names during development, one of which had some particularly strong negative feedback which will forever stick in my mind! And no, I’m not letting on…

At Microsoft, you can change your picture which shows up on internal email among other places. I was trying to (futile effort) encourage people to stop using the incorrect terminology. Hence I changed my picture to that of a Gentoo penguin with a red circle and cross through it. Well I thought it was a good idea, if a little subtle! Of course I wasn’t thinking it through entirely as I got some comments that I was being derogatory towards Linux which was not the case at all! You live and learn!!