Hyper-V generation 2 virtual machines part 2

John Howard MSFT 25 Oct 2013 12:24 PM

24

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 ConvertVMGeneration
In the previous part, I explained why we introduced generation 2 VMs in Windows 8.1/Windows Server 2012 R2. In this part, Im
going to talk a little about what is simpler in generation 2 compared with generation 1 from a management perspective. In
particular, in this part, Im going to focus on networking.
Lets start with a question Im frequently asked literally the saying about a dollar for every time applies here. Why is
networking in my virtual machine so slow?
The number one answer for this is that people have installed a VM using a legacy network adapter which remember is emulated,
thus incurring multiple expensive round trips through the Windows Hypervisor, plus context switches between kernel and user
mode in the parent per I/O, plus the emulation itself, and forgotten to switch to a software based network adapter.
Even though we have this message in the settings page for a Legacy Network adapter, and a warning in the BPA applies only to
server, not Client HyperV, the fact is people dont always read whats in front of them:

Given we dont have a legacy network adapter as an option in a generation 2 VM go on, try it!, we had to make it possible to
boot from a software based network adapter, providing the appropriate support for VMBus and the device in the UEFI firmware
stack.
OK, Ill try it for you this is what Add Hardware looks like in a generation 1 VM on the left, vs. a generation 2 VM on the right,
and below it through PowerShell running AddVMNetworkAdapter IsLegacy $true on a VM

Ill gloss over the RemoteFX 3D Video Adapter for the moment and come back to that later however, in this case, the
generation 1 screenshot was taken on Server HyperV without a capable graphics adapter, the generation 2 screenshot was taken
on Client HyperV where RemoteFX is not available.

It was actually a little worse than having a potentially confusing choice of two network adapters, as, in order to remove the legacy
network adapter and add a software based network adapter to replace it, you had to shut the virtual machine down. Ive even
heard of problems with network infrastructure due to the DHCP lease not expiring immediately when the legacy network adapter
is removed from the virtual machine, or having to reconfigure switches to allow the MAC addresses for each of the NICs.
Well this is solved in generation 2. The only type of NIC is the software based network adapter. To boot from network, you simply
need to ensure the network adapter is at the top of the list of firmware boot entries or at least higher than another bootable
device that would succeed in boot. Note setting the boot order for a generation 2 VM is somewhat more involved than for a
generation 1 VM due to the use of NVRAM variables to store explicit boot order and boot entries.
As the boot order is so much more flexible when using UEFI firmware than BIOS, we have had to introduce new WMI, PowerShell
and UI for configuration. This means that the old properties such as BootOrder are not used by a generation 2 VM.
Heres the settings of a generation 2 VM set to boot from network first which would fail as its not connected to a switch:

We also have a new capability for network boot on generation 2 VMs that is not present on generation 1 VMs the ability to
network boot using both IPv4 and IPv6. Generation 1 can only boot using IPv4.
This capability is not exposed in HyperV Manager, but is available through both PowerShell and WMI. In PowerShell, you set the
NetworkBootPreferredProtocol parameter when calling SetVMFirmware. The WMI property has the same name and is a member
of the Msvm_VirtualSystemSettingData class.
Note that the property is global and applies to all NICs in a virtual machine. You cannot selectively attempt an IPv4 network boot
from the first NIC in a VM, and if unsuccessful, attempt an IPv6 network boot from a subsequent NIC. The default protocol is IPv4.
There is one relatively fortunate downside to UEFI it goes through boot entries too fast! So its not really a downside unless you
have lots of devices and they all fail there would be a slew of messages on the screen which wouldnt necessarily be readable.
For that reason, for advanced users we have a WMI property PauseAfterBootFailure in the Msvm_VirtualSystemSettingData class
which does exactly what it implies it requires user input before advancing to the next boot entry candidate should the current
one fail.
You may be asking how you can change the boot order in PowerShell. Theres been a number of people ask this internally during
development, or have been confused, so its worth spending a couple of minutes on it.
There are two ways in PowerShell to change the boot order of a generation 2 virtual machine. The simplest way is to use the
FirstBootDevice parameter to SetVMFirmware. This simply bumps a device to the top of the list which is more often than not the
most common case.
Consider this example a virtual machine with a boot disk, data disk, network adapter and a bootable ISO in a DVD drive. Initially
the boot order is network, boot disk, data disk and DVD.

In PowerShell, Im going to make the DVD drive the first boot device by obtaining the DVD object and passing it in as the
parameter for FirstBootDevice:
PSC:\>$vm=getvm"BootOrderExample"
PSC:\>$dvd=GetVMDvdDrive$vm
PSC:\>SetVMFirmware$vmFirstBootDevice$dvd
Back in the UI, we can see that the DVD drive has jumped to the top of the list, and all other boot entries have been bumped
down by one, in the order they originally were.

Now while this technically allows you to do any ordering, with a lot of devices, this is not always the easiest way to manage the
settings. Instead, lets work with the BootOrder property returned by GetVMFirmware. Here, Im getting the property, and as
there are two SCSI hard disks one data, one bootable, Im showing which is which by examining the .Device.Path property.
PSC:\>$bootorder=(GetVMFirmware$vm).BootOrder
PSC:\>$bootorder|flDevice
Device:Microsoft.HyperV.PowerShell.DvdDrive
Device:Microsoft.HyperV.PowerShell.VMNetworkAdapter
Device:Microsoft.HyperV.PowerShell.HardDiskDrive
Device:Microsoft.HyperV.PowerShell.HardDiskDrive
PSC:\>$bootorder[2].Device.Path
d:\vms\BootDisk.vhdx
PSC:\>$bootorder[3].Device.Path
d:\vms\DataDisk.vhdx
We can simply reorder the array by rearranging the elements and passing that into SetVMFirmware. A silly example would be to
sort by the firmware device path. You would probably want to do something a little more sensible, but you get the idea.
PSC:\>(setvmfirmware$vmbootorder($bootorder|sortfirmwarepath)
passthru).BootOrder.FirmwarePath
\AcpiEx(VMBus,0,0)\VenHw(9B17E5A2089142DDB653
80B5C22809BA,635161F83EDFC546913FF2D2F965ED0E0532954F3B05964FB09794B5A
F46C4DC)\MAC(000000000000)
\AcpiEx(VMBus,0,0)\VenHw(9B17E5A2089142DDB653
80B5C22809BA,D96361BAA104294DB60572E2FFB1DC7F01DF391F428F934A85E1115ED
64C01E4)\Scsi(0,0)
\AcpiEx(VMBus,0,0)\VenHw(9B17E5A2089142DDB653
80B5C22809BA,D96361BAA104294DB60572E2FFB1DC7F01DF391F428F934A85E1115ED64C01E4)\Scsi(0,1)
\AcpiEx(VMBus,0,0)\VenHw(9B17E5A2089142DDB653
80B5C22809BA,D96361BAA104294DB60572E2FFB1DC7F01DF391F428F934A85E1115ED64C01E4)\Scsi(0,2)
This also happens to get us back to where we started

If you use the BootOrder property, I would strongly recommend you Get it from the VM first, reorder it and Set it on the VM. As
opposed to simply constructing your own array and passing it in to SetVMFirmware. There is a good reason for this. In the above
examples, the VM just had a bunch of devices configured on it. Id never actually started it, and the Boot Disk.vhdx file was just a
blank VHDX without an operating system.
However, there is another type of boot entry, type File. Any UEFI application running in the VM can create File boot entries. In fact,
Windows does exactly this during operating system installation, and places it first in the boot entries by default. In this way, even
if you perform a network installation or DVD installation of Windows, subsequent boots will always start the Windows Boot
Manager unless you explicitly change it. So now you can see, if you just constructed the boot entries from devices attached to the
VM, you would delete any File entries. Below is an example of a file boot entry created by Windows 8.1.

So while Im here, lets suppose you dont heed my advice and construct a bootorder array which doesnt list all the devices in the
VM. Ill use the real VM which has the File entry and Windows 8.1 installed, and set the boot order to an array which contains just
the network adapter.
PSS:\>(getvmfirmware$vm).bootorder.boottype
File
Drive
Network
Drive
PSS:\>$nic=getvmnetworkadapter$vm
PSS:\>$mybootorder=@()
PSS:\>$mybootorder=$mybootorder+$nic
PSS:\>setvmfirmware$vmbootorder$mybootorder
PSS:\>(getvmfirmware$vm).bootorder.boottype
Network
PSS:\>
Youre probably totally unsurprised by this. The new boot order contains just the network adapter. And of course, if I started the
VM, its not going to boot back into the Windows installation sitting on its SCSI connected operating system disk. The easiest
solution to this is to remove and readd the hard disk through the VM settings or PowerShell equivalent, and change the hard
disk to be top of the boot order. HyperV will automatically add an entry to bottom of NVRAM boot entries when a SCSI or NIC
device is added to the VM configuration.

However, you have still lost that file entry which Windows setup created. It can be recreated in WMI not through PowerShell
directly assuming you know can calculate the correct firmware device path. An easier way is using bcdboot inside the guest
operating system once it is booted, as you can see here.

Anyway, enough of boot entries. Ill move on to storage in the next part.
Cheers,
John.

Comments
Marius Sandbu 25 Oct 2013 10:17 PM

any reason why remotefx adapter is not available in Gen 2 VMs?

Denis Dyagilev 26 Oct 2013 10:58 AM

Hi, John
For PXE boot machines of the Gen2 can only use WDS on 2012 R2 ADK 8.1?
Denis Dyagilev 26 Oct 2013 10:59 AM

Also, what are the requirements for WDS?

Steve Jones 27 Oct 2013 7:39 PM

Do your networking changes make it easier to get networking working with wireless adapters in Win8/8.1 on
laptops? That has been a constant problem with Win 7/8.
John Howard MSFT 28 Oct 2013 5:41 PM

@Marius, I'll get on to that in the FAQ part.