It’s been a rough week for virtualization beta testing, at least for me. Last week, I took a look at a late beta of VMware’s VI3 update (with ESX Server 3.5 and VirtualCenter 2.5), and was impressed overall, but found more than a few bugs and saw more than my share of host crashes. This week, I looked at Microsoft’s next-generation hypervisor, dubbed Hyper-V, which will be released as a component of Windows Server 2008. Hyper-V is a whole new virtualization platform for Microsoft, going beyond Virtual Server and adding new management features, expanded snapshot support, and hopefully better performance. After my brief look at the beta release, I can confirm that this is truly beta, and it has a long way to go to be production-ready.

The Bottom Line Microsoft Windows Server 2008 Hyper-V beta Microsoft, microsoft.com Beta   Ship Date: Due within 180 days after the Windows Server 2008 release. To be available in Windows Server 2008 Standard, Enterprise, and Datacenter editions, and also as a stand-alone Hyper-V Server. Platforms: Requires clean install of Windows Server 2008 Enterprise RC1, x64 edition. For the beta release, Microsoft recommends installing one guest only (32-bit or 64-bit): either Windows Server 2008 or Windows Server 2003 or Suse Enterprise Linux Server 10 with Service Pack 1. Bottom Line: Microsoft has taken many positive steps with Hyper-V, but still has a long way to go to be competitive in the roller-coaster hypervisor market. Hyper-V isn’t a threat to VMware’s Virtual Infrastructure or Virtual Iron, but it could be considered a competitor to VMware Server. The fact that Hyper-V will be offered with Windows Server 2008 will mean that it has an arguable leg up over other products, but when more mature products like VMware Server are available as a free download, Hyper-V still has an uphill battle. About our Reviews and Scoring Methodology

[ See also: Preview: VMware Infrastructure 3 update builds on the base" ]

The basis of Hyper-V is the new Windows Server 2008 platform that carries with it a host of new features and a vaguely Vista-esque look and feel. Love it or hate it, Vista-ness is apparently here to stay. Installation of Hyper-V on Windows Server 2008 is as straightforward as you would think, requiring only that an admin add the Hyper-V role to the server and designate which network interfaces to use for virtual machines. After installation, the server reboots and Hyper-V is ready for action.

I installed the beta on a solid, middle-of-the-road server, a Dell PowerEdge 2950 with two dual-core 3GHz Intel CPUs, 4GB of RAM, and a single 72GB U320 SCSI drive. I had newer and more powerful hardware in the lab, but I wanted to run the beta on hardware that was virtually guaranteed to have built-in driver support. I wasn’t disappointed -- everything worked right out of the box. From there, I had the system ready to handle virtual machines in a matter of minutes. A few minutes later, I ran into problems.

Disk Manager lockup drill
I first created a Windows Server 2003 VM by running through the simple wizard. Aside from the fact that Hyper-V wanted to create a 127GB virtual disk on a fictitious 2TB file store instead of the actual 70GB local disk, the process was quick and easy. Then I tried to boot the VM from an ISO located on a network share, much like I’ve done for countless VMware installations. Unfortunately, although my user account had rights to the share, Hyper-V requires the system account to have read/write access to the share to read the ISO image. Rather than reconfigure network sharing security preferences, I copied the ISO to the local system and proceeded to install the new VM that way. While the Windows VM setup was running, I built another VM to run Linux, and configured it for PXE boot, again like I’ve done on many, many VMware installations. The VM successfully PXE booted and the installation proceeded normally.

While the two VMs were building, I explored the system a bit, specifically Server Manager and the iSCSI Initiator, in order to mount an iSCSI LUN for the VMs. This led me nowhere. Although I could successfully discover and log on to the iSCSI LUN, opening Disk Manager to partition and format the volume locked the application up tight. For a period of five minutes, I could communicate with the server, but all VM activity was frozen, and the Server Manager was completely unresponsive. Manually ending the process did bring the server back, but I couldn’t use the iSCSI LUN. In subsequent testing with the system quiescent and no iSCSI LUN mappings, the same scenario occurred consistently: Trying to run the Disk Manager resulted in a lockup.