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)
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.
In Hyper-V Manager, we have added an additional step in the New Virtual Machine wizard:
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:
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.
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.
The following is a screenshot from a generation 2 Windows 8.1 virtual machine running on Hyper-V in Windows 8.1
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.
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!!
It should be clear that gen2 does not support Linux properly (out of the box). Gen1 works fine, but in Gen2 I had to change some more advanced setting to get it to boot. Furthermore, the keyboard did not load and required additional steps. Anyone not a VM/Linux pro is not going to get far without proper OOTB Linux support. The tutorials are wrong online as well and don't really mention gen2.
Will Linux support also enable FreeBSD ?
I don't as yet know what distros and versions will take up the required changes to LIS to support generation 2 VMs presently. Keyboard support I believe has been submitted to the Linux code base recently. It's a question of when the distros take up the changes. When I know more, I will let you guys know.
I have performed a number of tests with a new failover cluster using a Dell PowerEdge 1950 and Dell PowerEdge 2950 with an MD3200i SAN running 15k SAS disks.
Hosts: Server 2012 R2. iSCSI via 1Gb switches, 2 network interfaces dedicated to iSCSI on each host.
Guests: 32Gb system drive, 2 processors configured, 2Gb RAM Server 2012 R2. One created as a Generation 1 machine, one as a Generation 2 machine. Generation 1 has the 32Gb fixed size disk attached via IDE, Generation 2 has the 32Gb fixed size disk attached via SCSI. Both systems have identical role/software installations.
Test tool: Crystal Disk Mark 3.0.2 x64 edition. 9 iterations of 4000Mb file size on the system drive.
The results are consistent. The generation 2 machine is slower on all read/write operations with the exception of 512k reads and 4K QD32 reads. On all other operations the generation 1 machine is faster, sometimes by as much as 15%.
The test has been run multiple times, with each of the hosts being the owner of the cluster disk and the guest machine, and with one being responsible for each, then swapped. As these are non-identical host hardware platforms the speed results in the guest are different depending which host the guest machine is active on (the 1950 is generally lower speed), but there is still correlation between which generation VM runs particular disk operations the fastest (i.e. on the lesser hardware, still 512k reads and 4K QD32 reads are the only tests that run fastest on the generation 2 machine)
For the purposes of the test, whilst the test of the Generation 1 machine is being run the Generation 2 machine is in a saved state, and vice versa. There are no other VM's configured on the two hosts, and no other VM's on the iSCSI disk set.
Just to add as I forgot to mention, the disks are vhdx.
Any feedback on this John, have you replicated in your own testing?
Thanks very much for this information - really well presented and laid out, and helped resolved an issue for us where a gen 2 VM had been built for a customer and we were trying to map through a physical DVD to the host - now we can see that it's not going
to work like that, we've advised the client to get an ISO ripper and work from that instead.
I think Hyper-V is excellent with a few exceptions: Why only support win8 and above for Gen2? Why doesn't copy/paste work except in RDP.
Charon - if you take a look at the FAQ, it explains about the dependency pre-Windows 8 has on a device which isn't present in generation 2 VMs, hence it is windows 8 and later. Copy/Paste will also work in enhanced session mode as of Windows 8.1/2012 R2 which uses RDP under the covers, just not over network. Architecturally, when not in enhanced session mode, we can just send keys to the guest by putting things in the keyboard buffer. Copy/Paste in that mode is extremely difficult. (ESM is independent of generation 2 BTW)
RHEL v7.0 inside Hyper-V VM Generation 2
If short -- all fine
Nice Blog series, really appreciate the depth and explications!