Microsoft's Hyper-V is a solid virtualisation platform that's compatible with a wide range of modern server hardware. However virtual machines could be affected by software problems with the host Windows server.
Microsoft released the first production version of its Hyper-V hypervisor on 26 June. Supplied as part of the Windows Server 2008 bundle, Hyper-V enables a single piece of server hardware to run multiple operating systems. Most people will use it to run several versions of Windows on the same server, but it could also be used to host Linux software, or just about anything else that runs on an x86-compatible CPU. However, organisations wanting to convert existing servers to run as virtual machines (VMs) or import VMs from other vendors' products will need to buy additional software.
We tested Hyper-V running on a workstation fitted with an Intel Core 2 Quad Q6600 CPU running at 2.4GHz and fitted with 3GB of RAM. We found the software easy to set up and use, and it did a good job of hosting both Windows and Linux software.
Having said that, Hyper-V is closely coupled to Windows Server 2008 and cannot be installed without it. On the upside this means that Hyper-V works with all the network cards (NICs), SCSI controllers and Fibre Channel HBAs that are supported by Windows. On the downside it also means that all your VMs must be temporarily halted if the host server needs a reboot after applying software updates.
Hyper-V also requires an x64 CPU and either Intel VT or AMD-V hardware virtualisation support. This is in contrast to the current market leading hypervisor, VMware's ESX Server, which works with just about any x86 architecture CPU and rarely needs patching or rebooting. However, ESX Server needs special drivers for NICs and other I/O cards, so it's compatible with a smaller set of server hardware.
We tested Hyper-V by installing Windows Server 2008 Enterprise Edition x64 onto an empty 100GB partition, using the Full Installation option. Microsoft has said it will make a Server Core version available later this year. This could be used to build a Hyper-V system without the memory and disk overhead of the full Windows Server 2008 GUI, and would cost around US$28 (~AU$32) to license. However, the true cost would not be negligible as it would still need to be managed remotely via a network connection, using a full Windows Server 2008 system. Organisations running more than one Hyper-V system would probably also buy System Centre Virtual Machine Manager 2008. Currently this does not support Hyper-V, but Microsoft has said it will provide an update this year that will add this feature.
With our fresh installation of Windows Server 2008 finished, we configured Windows Firewall to block all incoming connections. This was particularly important as our Windows server would be connected directly to the internet via a simple ADSL modem that did not have a firewall to protect the server.
Next we connected our server to the ADSL modem and used the Automatic Update feature in the Windows Initial Configuration Tasks applet to update our system with the latest patches. This replaced the pre-release version of Hyper-V supplied on the Windows Server 2008 installation DVD with the finished version that's certified for use with production systems. One reboot was required to complete this process.
With these steps completed we were ready to use the Add Roles Wizard to install and configure our server to run Hyper-V. The wizard asked which NICs were to be used to create external virtual networks that could be used by VMs. Like many systems that will be used to run Hyper-V, our lab system had only one NIC installed, so we had little choice but to select this one for use by our VMs.
The wizard also recommended that at least one NIC be reserved for remote access to the server. This could be a little disconcerting for the unwary as the wizard also said that this remote-access NIC could not be used by VMs. Clearly we had no choice but to proceed without a remote-access NIC. With these configuration options in place, we proceeded with the Hyper-V installation, which completed in less than two minutes. Two reboots were required, and when we logged back into the Windows Server desktop we checked the Update History using a link in the Initial Configuration Tasks applet and confirmed that our system was running the production version of Hyper-V.
Windows Server 2008's Server Manager applet has a three-pane interface, with a hierarchy on the left, details in the middle and actions on the right.
At this stage we could see a new Hyper-V option in the Server Manager (SM) applet, which could be used to manage Hyper-V setups running locally or on other servers via a network connection. The Windows Server 2008 version of SM provides a three-panel user interface, with the left panel providing a hierarchical view of the roles and features running on the server, and the central panel showing a detailed view of the selected item. The right-hand Actions panel provides links to relevant functions. Double-clicking on the Hyper-V Manager option in the left-hand panel expands its hierarchy, which allowed us to select Hyper-V running on the local server.
Before adding any VMs, we wanted to make a few changes to the basic Hyper-V configuration. For example, we used the right-hand Actions panel to launch the Virtual Network Manager and add an 'internal' virtual network, which promptly appeared in the Windows Device Manager as an extra NIC alongside the physical NIC and the 'external' virtual network adapter we created during the installation of Hyper-V. Internal virtual networks can be used by VMs and the host server. We could also create a 'private' virtual network, which could be used only by VMs running on our server.
To illustrate the difference between the 'internal' virtual network and the 'external' one created during installation, we created a VM to replace Windows Firewall with a Linux-based alternative.
The New Virtual Machine wizard lets you configure a VM to install an OS from an ISO image — in this case, IPCop.
