HyperV – An own Goal for Developers on Windows7

For the champion of the partner channel, with an ecosystem that is the envy of the market, the most ardent supporter showering resources and asset on its dedicated and committed developer community, it comes as a surprise that Microsoft of all people seems to be inadvertently driving its Partners and developers to competing virtualisation products. Even more surprising when you reflect on Microsoft’s robust and competent HyperV solution on their flagship server platform!

Up until recently I thought it was just an internal challenge we had, but following discussions with other partners at recent UK Chapter meeting of the IAMCP (International Association of Microsoft Channel Partners) it is dawning on me that we were not alone.

With the maturity of virtualisation has come a new more cost effective, efficient, flexible and productive way of developing software; not to forget the environmentally friendly benefit with a reduction in server footprint!

The use of virtualisation on the desktop to suck up all that underutilised power of modern workstations has been the engine room of many software production lines. Adoption has been extensive amongst all types of service companies and ISV (Independent Software Vendors) alike.

All was rolling along smoothly when Microsoft got serious about server virtualisation with its Hyper V and Systems Centre Virtual Machine Manager, pound for pound heavyweight contenders to VMWare. But that is where the good news stopped for Microsoft appears to have ‘forgotten’ about the workstation, leaving Windows 7 languishing with Virtual PC. Virtual PC is a Workstation Virtualisation asset that is not only off the pace but a legacy 32bit lightweight not even relevant in discussions over other vendor workstation virtualisation solutions. For HyperV does not run on Windows 7 and there is NO 64bit version of VirtualPC.

The consequence is Partners and developers are forced to deploy competing desktop virtualisation technologies, largely in the face of a real desire to run HyperV, fuelling familiarity with competing products. It is not therefore surprising that such familiarity fosters business cases to take these competing products one step further to the server and thereby usurping HyperV entirely!

A Microsoft own goal of epic proportions in the titanic virtualisation war of hearts and minds. Or is there an angle I’m missing here?

Why not deliver a HyperV class workstation solution to the desktop is hard to fathom? Windows 7 and Windows Server 2008 R2 share the same codebase, so technically there is no barrier. The two differ largely on their configuration and features switched on at install time. Having tested this I can confirm that you can make either platform look and behave almost exactly like the other with a little bit of shell scripting and registry tweak. There is even a third party utility ‘The Windows Server 2008 R2 Workstation Converter’ which can automate the process and does what it says on the tin. You get the equivalent of a Windows 7 experience with HyperV.

The main gotcha, apart from the license cost of running server and throwing away an OEM license, seems to be some utilities and manufacturer’s drivers still see the server class OS and will refuse to install, but I will let you work out that modest challenge.

All happy you would have thought, just use Windows server 2008 R2 as your developer workstation OS instead of Windows 7. But no with the Microsoft Hardware Compatibility List comes the spectre stability problems!

HyperV is built to run on certain hardware and that means deviation from standard server class components will herald back onto your screen that arch enemy the BSOD (Blue Screen of Death).

The HyperV BSOD’s are almost always hardware device driver related, but because of the standardisation of hardware many desktop machines will get away without any issues as they will be close enough to server components, and in some cases just lower spec server components. The exceptions tend to be those with specialist components, or high end graphics cards. Regrettably high end graphics cards are now a common feature as developers deploy multiple screens for productivity. On current reports this seems to be more prevalent with ATI graphics cards, but that may be simply because I have spoken to more developers and partners with ATI graphics than others. Laptops as you could guess are also big victims because their components are often modified by manufacturers to fit the low profile demands of the proprietary Laptop format and more prone to suffer driver compatibility issues leading to a higher yield of BSOD’s under HyperV.

The caveat here the BSOD issues highlighted above are by no means a reflection of a fair and balanced selection of hardware components or laptop vendors, but none the less of significant impact to be classed as meaningful.

So for the persevering who wish to persist with Microsoft HyperV on the workstation you can reduce the pain by:

1. Adding a boot option to load Windows Server 2008 R2 without Hyper-V when not needed using ‘BCDedit’ . This will not eliminate BSOD’s when running HyperV but at least give you peace of mind when HyperV is not needed.

2. A less desirable solution is to default your graphics card to Standard VGA or if you have an on-board Intel graphics chip use that instead of the shiny dedicated GPU you may have installed.

Unfortunately though the path of least resistance is the use of a competing virtualisation solution.

Microsoft let’s stop the rot and get focused on doing the good stuff with the best stuff!