Injecting network drivers into a Hyper-V Server (or Windows Server) installation

A couple of weeks ago, I blogged about running Windows from a flash drive – specifically running Hyper-V Server 2008 R2. One thing I hadn’t got around to at that time though was injecting the necessary drivers to provide network access to/from the server – which is pretty critical for a virtualisation host! Under network settings, the Hyper-V Server Configuration (sconfig.vbs) showed that there were no active network adapters found but I knew this should be pretty easy to fix.

One of the strengths of the Hyper-V architecture is that it uses the standard Windows device driver model. This is in stark contrast to the monolithic model used for VMware ESX (and ESXi) and is the reason that I can’t do something similar with ESXi. In fact, adding network drivers to Hyper-V Server (or for that matter Windows Server 2008 running in server core mode, or even for command line administration of a full Windows Server 2008 installation) is pretty straightforward.

The network card I needed to support is a Marvell Yukon 88E8055 PCI-E Gigabit Ethernet Controller and, even though Windows 7 recognised the hardware and installed the appropriate drivers at installation time, I couldn’t find the drivers in the install.wim file on the DVD. That was no problem – Marvell’s download site had x64 drivers for Windows 7 available and these are also be suitable for Windows Server 2008 R2 and Hyper-V Server 2008 R2. Armed with the appropriate driver (yk62x64.sys v11.10.7.3), I ran pnputil -i -a yk62x64.inf on my Hyper-V Server:

Microsoft PnP Utility

Processing inf :            yk62x64.inf
Successfully installed the driver on a device on the system.
Driver package added successfully.
Published name :            oem0.inf

Total attempted:              1
Number successfully imported: 1

(oem0.inf and an associated oem0.pnf file were created in the %windir%\inf\ folder)

With drivers loaded, I restarted the server (probably not necessary but I wanted to ensure that all services were running) and Hyper-V Server recognised the network card, allowing me to make configuration changes if required.

To validate the configuration, I ran pnputil -e, to which the response was:

Microsoft PnP Utility

Published name :            oem0.inf
Driver package provider :   Marvell
Class :                     Network adapters
Driver date and version :   07/20/2009
Signer name :               Microsoft Windows Hardware Compatibility Publisher

So, that’s installing network drivers on Hyper-V Server, what about removing them? Here, I was less successful. I tried removing the plug and play package with pnputil -f -d oem0.inf and this removed the package from %windir%\inf but, after a reboot, my network settings persisted. I also used devcon.exe, the command line equivalent to the Windows Device Manager (making sure I had the amd86 version, not i386 or ia64) to successfully remove the PnP package (devcon -f dp_delete oem0.inf) as well as the network interface (devcon remove "PCI\VEN_11AB&DEV_4363") but this still left several copies of yk62x64.sys available in various Windows system folders. Again, after a reboot the network card was re-enabled. Uninstalling network drivers is not a very likely scenario in most cases but, with a bootable flash device potentially roaming between hardware platforms, it would be good to work out how to do this. Of course, my work is based on the release candidate – the RTM version of Hyper-V Server 2008 R2 is yet to be released to web.

Hyper-V is now supported on flash drives

Last week I wrote about booting Windows from a USB flash drive.

This had been a “pet project” of mine for a few months and, just after I finally got around to doing it, Stephen Rose blogged about a tool to help you prepare the USB drive to boot from VHD. Oh well, that’s life – I can’t get the time back – but anyway, I enjoyed working out the answers for myself.

Today, I’ve seen a post from the Windows virtualisation team about the release of Hyper-V Server 2008 R2. It’s mostly a rehash of the long-running argument that Hyper-V (Server) costs less than ESX (i) and it probably does, even when factoring in the cost of the management tools but the real cost savings with virtualisation come from reduced power consumption (which will depend on the hardware used, and the consolidation ratios achieved) and operational improvements (i.e. not just running a virtualised infrastructure in the same way as for a physical one) so I’d take the messages from either Microsoft or VMware with a pinch of salt. Perhaps understandably for software companies, both focus too much on the cost of hardware and software rather than the cost of service delivery, which is what really matters to IT Managers.

More significantly from my point of view, the Microsoft’s Windows Virtualization Team also announced formal support for booting Hyper-V Server 2008 R2 from flash memory:

“Microsoft Hyper-V Server 2008 R2 includes the unique ability (compared to Windows Server Hyper-V) to boot from flash. We’re making the documentation available to our OEM partners as part of the OEM Preinstallation Kit (OPK). Boot from flash is specifically designed for our OEM partners who want to ship an embedded Hyper-V hypervisor and thus will be supported via our OEM partners.”

“So what”, you may ask. Well, this means that Hyper-V Server servers can now be diskless (e.g. boot from SAN) and treated as a commodity appliance. For organisations that still see a version of Windows as an operating system (any version of Windows – even if it’s just server core running Hyper-V) and so internal cross-charging mechanisms effectively tax virtualisation hosts as a full operating system, this is a step forward. It gets even better when considering that Hyper-V Server 2008 R2 is based on the Enterprise Edition of Windows Server (the previous version was based on Standard Edition) so it supports clustering and hence live migration.

I had heard something about flash support from a contact at HP (after I got it working!) but had seen nothing formally via the MVP programme; however this is the way that OEMs “embed” VMware ESXi (at least one vendor told me that they use an internally-mounted USB drive for ESXi – I’m not sure if that’s the way it works for all of them). Of course, running the OS from an inexpensive USB flash drive may be fine for a hypervisor that, once loaded into memory, requires little disk access but it’s certainly not a recommended solution for a full operating system – for that you would need better quality flash memory, such as a solid state disk (SSD).

Running Windows from a USB flash drive

I’ve titled this post as “Running Windows from a USB flash drive” because the same principles should be equally applicable to all Windows 7-based operating systems (and even Vista if the Windows 7 bootloader is used) but my specific scenario was based on Hyper-V Server 2008 R2.

I got this working a few hours after Windows 7, Server 2008 and Hyper-V Server 2008 R2 were released to manufacturing but I was still using release candidate code – fingers crossed it still works with the final release!

Boot from VHD is a fantastic new technology in Windows 7/Server 2008 R2 and derivative operating systems and I’ve often wondered if it’s possible to use it to run Hyper-V from a USB flash drive (just like the “embedded” version of VMware ESXi offered by some OEMs). Well, as it happens it is – and this post describes the steps I had to take to make it work.

First of all, I needed to create a virtual hard disk and install an operating system onto it. As Keith Combs noted, there are various ways to do this but only one is supported; however there is also a handy video on TechNet which takes you through the steps of creating a VHD and booting from it.

Using the TechNet video as a guide, I issued the following commands from the command prompt to create my virtual hard disk and apply an image from the Hyper-V Server 2008 R2 release candidate DVD:

create vdisk file=driveletter:\virtualharddisk.vhd maximum=15000 type=expandable
select vdisk file=driveletter:\virtualharddisk.vhd
attach vdisk
list disk

(make a note of the disk number.)

select disk disknumber
create partition primary
select partition 1
format fs=ntfs quick

(note the drive letter for the newly mounted VHD.)

imagex /info dvddrive:\sources\install.wim

(identify the correctentry.)

imagex /apply dvddrive:\sources\install.wim /check imageindex vhddrive:\
select vdisk file=driveletter:\virtualharddisk.vhd
detach vdisk

At this point, Hyper-V Server had been imaged into my new VHD, which could then be copied to the USB flash drive.

Next, to load the VHD from the Boot Manager, I edited the boot configuration data (which is what would be required in a standard boot from VHD scenario); however, as I found later, a different set of actions is needed for booting from the USB flash drive.

bcdedit /copy {current} /d “Hyper-V Server 2008 R2”

(make a note of the GUID for the newly created entry.)

bcdedit /set {guid} device vhd=[usbdrive:]\virtualharddisk.vhd
bcdedit /set {guid} osdevice vhd=[usbdrive:]\virtualharddisk.vhd
bcdedit /set {guid} detecthal on
bcdedit /set {guid} description “Hyper-V Server 2008 R2”

It’s worth understanding that the use of drive letters (which are transient in nature) does not cause a problem as the BCD Editor (bcdedit.exe) extracts the data about the partition and saves it in the BCD store (i.e. it does not actually save the drive letter).

After rebooting, Hyper-V Server loaded from my USB flash drive and ran through the out of box experience. At this stage I had Hyper-V Server running off the flash drive but only if my original Windows installation (with the boot manager) was available and, as soon as I removed the hard disk (I wanted to be sure that I was booting off the flash drive with no other dependencies), then the whole thing collapsed in a heap. Thanks to Garry Martin, I checked my BIOS configuration and made sure that USB device boots were enabled (they were not) but I then spent about a day playing around with various BCD configurations (as well as various attempts to fix my BCD with bootrec.exe) until I stumbled on a post from Vineet Sarda (not for the first time, based on the comments that include one from yours truly a few weeks back!) that discusses booting from VHD without a native operating system.

Following Vineet’s example, I booted my system into Windows 7 (I could have used the Windows Recovery Environment), reformatted the USB flash drive before copying my VHD image back onto it, and issued the following commands:

select vdisk file=usbdrive:\virtualharddisk.vhd
attach vdisk
list volume

(note the drive letter for the newly mounted VHD.)

bcdboot vhddrive:\Windows /s usbdrive: /v

(i.e. copying the BCD from the operating system image contained within the VHD, to the physical USB drive. Note that, when running on a live system it is important to specify the target drive for the BCD in order to avoid overwriting the live configuration.)

I then shut down the system, removed the hard disk and booted from the USB flash drive, after which the Windows Boot Manager loaded an operating system from within the VHD.

Looking at my BCD configuration (shown here for reference), I can see the source of my many hours of confusion – the Boot Manager resides on the physical media (my USB key – which was allocated drive D: in this case) and loads an operating system from the virtual disk that is given another drive letter (in this case C:):

Windows Boot Manager
identifier              {bootmgr}
device                  partition=D:
description             Windows Boot Manager
locale                  en-us
inherit                 {globalsettings}
default                 {current}
resumeobject            {27f66313-771a-11de-90bb-00037ab36ab6}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
identifier              {current}
device                  partition=C:
path                    \windows\system32\winload.exe
description             Hyper-V Server 2008 R2
locale                  en-us
inherit                 {bootloadersettings}
osdevice                partition=C:
systemroot              \windows
resumeobject            {27f66313-771a-11de-90bb-00037ab36ab6}
nx                      OptOut
detecthal               Yes

It took a while to boot (my flash drive was a freebie is not the fastest in the world) but, once loaded into memory, Hyper-V Server seemed to run without any noticeable delay. I figure that, as long as the workload is stored on another disk this should not present any problems and, given suitably fast flash memory, it ought to be possible to improve boot times as well. Running a full Windows operating System (e.g. Windows 7) in this manner is an entirely different matter – very few USB flash drives will be able to stand the constant writes and further testing would be required.

Now that I have Hyper-V Server running from an inexpensive USB flash drive with no reliance on my PC’s internal hard disk, all I need to do is inject the correct network drivers and I will have a virtualisation solution for colleagues who want to run a full hypervisor on their corporate notebooks, without deviating from the company’s standard client build.

Additional information

The following notes/links may provide useful background information:

Two more of my “How Do I?” videos available on the Microsoft TechNet website

Last month I mentioned that my “how do I” video on backing up a Hyper-V host with SCDPM had made it onto the Microsoft TechNet website and recently I noticed that the follow-up on backing up Hyper-V using the tools within Windows Server (Windows Server Backup) is now live on the site too (as well as one on creating a cluster on Hyper-V, which I freely admit would be more useful if it was about creating a cluster of Hyper-V hosts… for which I didn’t have the hardware available…).

There are a whole bunch of guys working on videos like these and the good news is that Microsoft has commissioned more for 2009/10. So, if you’re looking for step-by-step information on perform some common tasks with Microsoft products, then it might be worth checking out the TechNet How Do I? videos.

Early reports of SLAT-enabled processors significantly increasing RDS session concurrency

Let me caveat my next statement by saying that I think Hyper-V is a great virtualisation platform that meets the needs of many customer environments… but… Hyper-V does lack some features that would allow it to stand tall alongside the market leading product (VMware ESX) and I was disappointed when the dynamic memory feature was pulled from the second release of Hyper-V.

As I wrote when discussing new features in the Windows Server 2008 R2 release candidate:

“I asked Microsoft’s Jeff Woolsey, Principle Group Program Manager for Hyper-V, what the problem was and he responded that memory overcommitment results in a significant performance hit if the memory is fully utilised and that even VMware (whose ESX hypervisor does have this functionality) advises against it’s use in production environments. I can see that it’s not a huge factor in server consolidation exercises, but for VDI scenarios (using the new RDS functionality), it could have made a significant difference in consolidation ratios.”

Well, it seems that there may be a silver lining to this cloud (or at least, a shiny metallic grey one) as Clive Watson highlighted the results from some testing with Remote Desktop Services (Microsoft’s VDI broker) running on Hyper-V and reported that:

“We conducted our testing using both non-SLAT and SLAT hardware and found that SLAT enabled processors increased the number of sessions by a factor of 1.6x to 2.5x compared to non-SLAT processors.”

Basically using an SLAT-enabled processor (Intel Nested Page Tables and AMD Enhanced Page Tables) in a server should make a big difference to the consolidation ratios achieved in a VDI scenario.

Of course, if SLAT allows improved performance, then other platforms will also benefit from it (although not necessarily to the same degree) but, if VDI really is a feasible technology solution (I have my doubts and consider it a “significant niche” solution), I’m sure Microsoft will come up with something for the third incarnation of Hyper-V.

Copying files to/from a Hyper-V Server or Windows Server (server core) computer over RDP

It’s reasonably well known that it’s possible to expose local resources (including local drives) on a remote computer when connecting using the Microsoft Remote Desktop Connection client. Using this method, the local drives are exposed on the remote computer using Windows Explorer (e.g. drive on computername).

Last week, I was working with a Hyper-V Server 2008 computer (the principle would be the same for a server core installation of Windows Server 2008) and, even though I’d connected via RDP, I couldn’t work out where the drive connection was on a machine without Windows Explorer. Then I ran the net use command and saw that there was a remote mapping called \\tsclient\d with a network name of Microsoft Terminal Services, representing my local D: but without a remote drive letter assigned.

I ran net use * \\tsclient\d and the connection was re-mapped – this time with a drive letter assigned (in this case, the system chose Z:) following which, I was able to copy files between to and from Z: (i.e. to/from my local computer’s D:) using the remote host.

Hyper-V Manager cannot find the MSVM_VirtualSystemManagementService object

A couple of days ago, I was working with a colleague to build a Windows 7 proof of concept lab with a number of servers running Hyper-V and some virtualised server instances to provide the supporting infrastructure. The physical servers running are a mixture of Windows Server 2008 (full installation) and Hyper-V Server (the free of charge version of Hyper-V) but, after installing the Hyper-V role on one of the full Windows Server 2008 machines, we were still unable to manage the remote (Hyper-V Server) host – even after following John Howard’s 5-part series of blog posts to enable remote management.

Whenever I tried to connect to the Hyper-V server (or indeed the local instance of Hyper-V), Hyper-V Manager complained that:

The ‘MSVM_VirtualSystemManagementService’ object was not found

It turned out that the problem was related to not having the RTM version of Hyper-V installed on the server (a schoolboy error!) – Windows Server 2008 shipped with a beta of Hyper-V. After installing the update described in Microsoft knowledge base article 950050 (downloading Windows Server 2008 service pack 2 to bring the server completely up-to-date was a slow process over a poor Internet connection) the server was able to manage both local and remote Hyper-V resources.

A few notes on the Hyper-V Server configuration script

Hyper-V Server comes with a handy script to assist administrators who don’t like the command line with key configuration items such as domain/workgroup settings; computer name; network settings; adding a local administrator account; Windows Update settings; downloading and installing updates; Remote Desktop connection settings; regional and language options; date and time; logging off, restarting and shutting down a server.

This script is automatically run at first logon but, if you need to run it again later (rather than use the standard commands that hardened server core administrators are now used to!) then the command to run is [%windir%\system32\]hvconfig.cmd (which calls hvconfig.vbs from the appropriate language-dependent subdirectory, e.g. %windir%\system32\en-us\).

Incidentally, the hvconfig script can also be used on a server core installation of Windows Server 2008, as described by Sander Berkouwer (and linked from this blog back in October).

Another one of my “How Do I?” videos makes it onto the Microsoft TechNet website

A couple of days back, I noticed that another one of my videos has made it onto the Microsoft TechNet website – this one looks at backing up a Hyper-V host using System Center Data Protection Manager 2007 SP1.

Those who’ve watched earlier videos may notice that the sound quality on this video is much improved as I finally bought myself a half-decent microphone. I’ve also dedicated a PC to the task of recording these videos (recommissioning my old Compaq DeskPro EN510SFF, which has been upgraded with a 250GB disk and 2GB of RAM, and more recently gained a Matrox Millennium G550 dual-display video card picked up for a few pounds on eBay). This machine is certainly no screamer but, as the videos are only recorded at 5 frames per second it’s perfectly capable of keeping up, although TechSmith Camtasia Studio falls over from time to time and the 2.4GHz Intel Pentium 4 processor does take a while to render the final output.

There are some more videos on the way as I’ve submitted three more that have yet to make it onto the TechNet site but, if you’re looking for step-by-step information on perform some common tasks with Microsoft products, then there are a whole bunch of guys working on these TechNet How Do I? videos and they’re definitely worth a look.

Looking for a 64-bit notebook to run a type 1 hypervisor (Hyper-V… or maybe XenClient?)

Earlier today, some contacted me via this website and asked for advice on specifying a 64-bit laptop to run Hyper-V. He was confused about which laptops would actually work and I gave the following advice (unfortunately, my e-mail was rejected by his mail server)…

“The main thing to watch out for is the processor specification. If you get the model number (e.g. T7500) and look this up on the Intel website you can see if it has a feature called EM64T or Intel 64 – that is Intel’s implementation of AMD’s x64 technology – and most PCs have it today. Other things you will need for Hyper-V are hardware DEP (Intel XD or AMD NX) and hardware assisted virtualisation (Intel-VT or AMD-V). This last one might catch you out – some quad core chips don’t have the necessary functionality but most dual core chips do (and I’ve heard some reports from people where the chip supports it but there is no option to enable it in the BIOS).

Also, if you’re running 64-bit, driver support can be a pain. Stick with the major manufacturers (Lenovo, Dell, HP) and you should be OK. I was able to get all the drivers I needed for my Fujitsu notebook too.”

If you want to run Hyper-V on a notebook, it’s worth considering that notebook PCs typically have pretty slow hard drives and that can hit performance hard (notebook PCs are not designed to run as servers). Despite feedback indicating that Virtual PC does not provide all the answers, Microsoft doesn’t yet have a decent client-side virtualisation solution for developers, tech enthusiasts and other power users but Citrix have announced something that does look interesting – the XenClient (part of what they call Project Independence), described as:

“[…] a strategic product initiative with partners like Intel, focused on local virtual desktops. We are working together to deliver on our combined vision for the future of desktop computing. This new virtualization solution will extend the benefits of hosted desktop virtualization to millions of mobile workers with the introduction of a new client-side bare metal hypervisor that runs directly on each end user’s laptop or PC.”

You can read more at – and it’s probably worth watching the last 15 minutes from the Synergy day 2 keynote (thanks to Garry Martin for alerting me to this).

Layered on top of XenClient are the management tools to allow organisations to ensure that the corporate desktop remains secure, whilst a personal desktop is open and the scenario where we no longer have a corporate notebook PC (and instead are given an allowance to procure and provide our own IT for work and personal use) suddenly seems a lot more credible. I’m certainly hoping to take a closer look at the XenClient, once I can work out how to get hold of it.