Details on Generation 2 virtual machines and using them in VMM 2012 R2

~ Cedric Davies

In Windows Server 2012 R2, Hyper-V added a new type of virtual machine called a Generation 2 virtual machine. Generation 2 virtual machines introduce a number of changes over the prior, now called Generation 1 virtual machines. Generation 2 virtual machines remove a lot of the old hardware still being emulated in Generation 1 virtual machines, making it easier for Hyper-V to move forward with new features and improvements.

Some reasons you might want to give Generation 2 VMs a try are:

• Boot from SCSI attached storage
• Guest OS install from synthetic networking (much faster than using legacy networking)
• Faster boot time (on the order of one or a few seconds)
• New Secure boot feature (more information on this feature below)
• Larger boot volume (64TB vs 2TB)
• Online expand of boot disk
• Online add/remove of DVD drives
• Smaller security attack surface
• Less host resources consumed emulating devices
  • No floppy drive
  • No serial ports (possible to add back by advanced users through Hyper-V WMI)
  • No pass-through DVD
  • No legacy network adapter
  • No IDE controller

Generation 2 VMs may not be suitable for you if you require:

• Any of the emulated devices removed
• 32-bit guest operating systems
• Windows guests prior to Windows Server 2012/Windows 8
• RemoteFX support

Note also that Generation 2 VMs do not support the older VHD format although by now you are probably already using the superior VHDX format anyway. You can always use the Edit Virtual Hard Disk Wizard in Hyper-V Manager to convert between VHD and VHDX disks.

Generation 2 VMs use different system firmware than Generation 1 VMs. Generation 1 VMs use a PCAT BIOS (as have the majority of OEM PCs until recently) whereas generation 2 VMs use UEFI firmware. Some of the advantages listed in the reasons you might want to try Generation 2 VMs are a direct consequence of this change, such as larger boot volumes and the new Secure Boot feature. One of the major advantages of UEFI firmware is that it is written in a high-level language (as oppose to 16-bit assembler for the BIOS) which makes it much easier for the Hyper-V team to maintain and extend. And this is exactly what Hyper-V has done. By extending the UEFI firmware to be aware of software based (otherwise known as synthetic) devices, Generation 2 VMs support booting from synthetic network adapters or synthetic SCSI disks and DVD. Using UEFI firmware has an important consequence on the format of a VMs boot disk, which is a major ‘gotcha’ that you need to be aware of. For more on the boot disk format see the Boot Disks section below.

Ultimately the decision on whether to try using Generation 2 VMs is up to you. You should be aware however, that once you’ve made your decision, there is no option in VMM for converting a Generation 2 VM to a Generation 1 VM (or vice a versa). For a more in-depth look at generation 2 VMs, please see John Howard’s blog.

The rest of this article focuses on the changes made in VMM 2012 R2 to support generation 2 VMs. First thing to note is that in VMM 2012 R2, Generation 2 VMs are not supported when deploying VMM services or VM roles. Other than that, VMM 2012 R2 has full support for both creating Generation 2 VMs and for discovering Generation 2 VMs created outside of VMM.

Creating Generation 2 VMs

The Identity page of the Create Virtual Machine Wizard was modified to allow you to select which type of VM you want to create. When creating a Generation 2 VM just select “Generation 2” from the generation dropdown. This will do two major things: First, when you come to the Configure Hardware page you will notice that those hardware devices that are not support by Generation 2 VMs such as floppy drives, legacy networking and IDE controllers will not be present. Second, when selecting the destination host for the VM only Windows Server 2012 R2 hosts will be allowed.

Figure 1 - Creating a Generation 2 VM

Figure 2 - Hardware for a Generation 2 VM

Of course if PowerShell is your thing, the VMM New-SCVirtualMachine cmdlet has been updated to take a Generation parameter of either 1 or 2. You can thus create a Generation 2 VM from PowerShell like so:

PS C:\> $h = Get-SCVMHost

PS C:\> New-SCVirtualMachine -Name MyVM -Generation 2 -VMHost $h[0] -VirtualHardDisk $disk –Path “C:\MyVMs”

Once the VM has been created, it shows up in the VMM console window just like any other VM. If you want to check the generation of a VM you can do so from PowerShell by checking its Generation property:

PS C:\> Get-SCVirtualMachine MyVM | fl Generation

Generation : 2

Or you can open up its Properties window:

Figure 3 - Generation 2 VM Properties

Just like you can create a Generation 2 VM, you can also create a generation 2 Template or Hardware Profile. As with Generation 2 VMs, a Generation 2 Template or Hardware Profile will restrict you to only include the hardware devices that are supported by Generation 2 VMs. When it comes time to create a new VM from your Generation 2 Template, the Identity page of the Create Virtual Machine Wizard will not contain an option for selecting the generation because the generation has been automatically inherited from your Template. This implies that Generation 2 Templates can only be used to create Generation 2 VMs, and likewise, Generation 1 Templates can only create Generation 1 VMs.

Secure Boot

Secure Boot is a feature of the UEFI firmware specification used by Generation 2 VMs and supported by Hyper-V and VMM. Secure Boot uses a signature checking mechanism during the boot process to validate that only approved components are allowed to run. By default, Secure Boot is enabled for any new Generation 2 VM. It is a simple on/off property that can be modified via the Firmware settings in the VM’s properties dialog or via the SecureBootEnabled parameter of the Set-SCVirtualMachine cmdlet. Note that the VM must be off in order to modify this setting.

Figure 4 - Secure Boot

PS C:\> Set-SCVirtualMachine -VM $vm -SecureBootEnabled $true

For the most part, you won’t need to worry about this setting as you’ll likely want to always leave this option enabled which is the default. For more details on the inner workings of Secure Boot see here.

Boot Disks

Instead of a BIOS, Generation 2 VMs use UEFI firmware, a consequence of which is that the boot disk of a generation 2 VM must be GPT (Technically, the boot disk can be MBR or GPT, as long as there is an EFI system partition present with a boot loader, but GPT is strongly recommended).Generation 1 VMs, on the other hand, must have a MBR partition table, a requirement of its PCAT BIOS.

While not a problem when installing Windows (Windows will lay out the partitions on the boot disk in the correct format automatically), this does present a problem for those sysprepped boot disks you have stored in your VMM library. If you wish to create both Generation 1 and 2 VMs from these disks you will need to keep both an MBR and GPT version in your library. Unfortunately there is no feature in SCVMM 2012 R2 that will allow you to automatically know which disks are MBR vs GPT. To keep it straight, I would recommend that you use a consistent naming format for your disks, or keep the disks in separate library shares. One easy way for quickly telling if a disk is MBR or GPT is to mount it (right-click and select Mount) and then look at its properties from diskmgmt.msc.

Note that this discussion is only about the boot disk for the VM, non-boot disks can be either MBR or GPT for either generation of VM.

Figure 5 - Properties of a GPT disk

Boot Order

Another change with Generation 2 VMs brought about by the new UEFI firmware is a much more flexible boot order configuration. For Generation 1 VMs you would set the boot order from the options (CD, IDE Hard Drive, PXE Boot, Floppy). Generation 2 VMs, on the other hand, allow the boot order to be set among all of the bootable devices on the VM. For example, if your VM had two network adapters, they would each have an option in the boot order list. In addition to your VM’s bootable devices, any UEFI application running in the VM can create file boot entries and Windows will do exactly that during installation.

From the Hyper-V Manager UI you can see the full boot list order and make changes to it there. You can also make changes to the boot list order via the Hyper-V PowerShell cmdlets. See John Howard’s blog entry on boot order for more information.

Figure 6 - Boot List as seen from Hyper-V

In SCVMM 2012 R2 we allow you to view and modify only the first boot device of the VM via our PowerShell cmdlets. This covers most user scenarios, however if you need more fine grain control of the full boot order list you’ll need to use either the Hyper-V Manager or Hyper-V cmdlets. To get the first boot device of a VM, get its aptly named FirstBootDevice property (note that the previously used property: BootOrder, will be $null for a generation 2 VM):

PS C:\> $vm.FirstBootDevice

SCSI,0,0

In the case that the first boot device is a disk or DVD, the format will be “SCSI,x,y”, where x,y indicate the SCSI bus and location. In the case that the first boot device is a network adapter, the format will be “NIC,x”, where x is the 0-based index of the network adapter. In the case that the first boot device is a file entry, normally added by Windows on installation, the format will be “File,name”, where name is the file name. An example would be “bootmgfw.efi”.

By default, when creating a new Generation 2 VM, the first boot device is set to the first disk which will almost always be “SCSI,0,0”. As mentioned previously, during installation of the guest OS, Windows will change it to something like “File,bootmgfw.efi”.

In order to modify the first boot device, you can use the Set-SCVirtualMachine cmdlet passing the device to set as the first boot entry in the FirstBootDevice parameter. The parameter is passed a string formatted as described above. For example, if you want to boot from your NIC, you would set it as such:

PS C:\> Set-SCVirtualMachine -VM $vm -FirstBootDevice "NIC,0"

When a new first boot device is set, all of the other devices in the boot list are simply pushed down; nothing is actually removed from the list. If you want to remove entries from the list you will need to use the Hyper-V cmdlets. When booting, Hyper-V will go through each boot device in turn until one of them successfully boots the VM. Each failed boot device will generate a failure message at the console screen. For example, when I set my disconnected network adapter as the first boot device I see the message, “Boot failed. EFI network”. Assuming you set the device you want to boot from at the top of the list (or at least, only behind entries that fail to boot), the VM will boot up using your desired boot device.

Known Issues

Unfortunately software bugs are a fact of life and here is a known issue with Generation 2 VMs that exists in VMM 2012 R2:

Remember when I told you that Windows will create its own first boot device entry during installation? Well, if a user creates a Template from that VM, generalizing the VM’s boot disk in the process, we copy the first boot device of the VM to the Template verbatim. The Template now has as its first boot device an entry that doesn’t refer to any actual boot device for that Template. This might not normally be a problem because when a VM boots it will go through the entries in the boot order one-by-one until the VM boots. However, when you try to create a new VM out of this Template, VMM will try to set the first boot device of the VM to the file entry as set in the Template and fail with this error:

VMM cannot find the device or this device is not valid for a boot device

The work around is simple enough; after creating a Template from a VM, modify the first boot device of the Template to a valid device. For example:

PS C:\> Set-SCVMTemplate -Template $t -FirstBootDevice "SCSI,0,0"

Wrap-up

Generation 2 VMs are a new type of virtual machine in Hyper-V that come with their own set of advantages and disadvantages. They represent a new direction for Hyper-V, and with their reduced set of legacy devices and new UEFI firmware they provide Hyper-V with a break from the past. In the future there will likely be new features that depend on these changes, like Secure Boot, and hence will only work with Generation 2 VMs. Getting started with Generation 2 VMs today will set you up to take advantage of these features tomorrow. Ultimately the decision is up to you, but whatever you decide, you can rest assured that VMM 2012 R2 provides support for creating and managing your Generation 2 VMs (outside of VMM services and VM Roles).

I hope that you have found this post helpful. Please feel free to submit feedback at the bottom of this post and/or ask questions on the VMM forums. Also, make sure to visit the VMM 2012 R2 TechNet Library.

Thanks for reading!

Cedric Davies | VMM Developer | Microsoft

Get the latest System Center news onFacebookandTwitter:

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/