Since its introduction at Microsoft’s BUILD conference last September, Windows 8 has garnered a large measure of attention, especially with regards to the new Metro interface. The feature that intrigued me the most, however, was the inclusion of Hyper-V.
For roughly 8 years, I have been a frequent user of virtualization on the desktop, so the inclusion of Hyper-V intrigued me. I haven’t had a chance to use Hyper-V, it being primarily server product, but I do have experience with other desktop virtualization packages, including VirtualPC, VMWare, and VirtualBox. In this article, I will try to gauge how well Hyper-V works on the desktop. I’m going to test four operating systems: Windows 7, CentOS 6.2, Debian Squeeze, and FreeBSD 9. These four represent the spectrum of support for Hyper-V, with Windows and CentOS being officially supported, FreeBSD being completely unsupported, and Debian somewhere in the middle.
Configuration of Hyper-V
Hyper-V isn’t installed by default, and is added from via the â€œWindows Featuresâ€ panel. Installation is relatively quick, and requires two restarts. If you have other VM software installed at the same time, it will likely refuse to run. The hypervisor is fairly well integrated with the Windows kernel, and is in fact enabled as a kernel option at boot.
The Hyper-V Manager is the central location for managing guests, and allows you to manage virtual machines on your system, or others. Anybody that is familiar with the Microsoft Management Console will feel right at home. All the relevant information is up front, and various control options are readily accessible for multiple machines. It is quite easy to us, especially compared to the horrible tab interface of VirtualBox.
Once the program is launched, the first thing to do is add a virtual network switch. There are three types of network switches available: Internal, External, and Private. The Internal switch allows guests to communicate with each other, and the host. The Private switch allows communication only among guests, and not with the host machine. Finally, the External switch provides a means for guests to connect to a physical network. There is a caveat to this, though. Your host system will no longer connect directly to the physical network. Instead, traffic with flow through a virtual network interface, then to a virtual switch, which connects the host and guest systems to the actual physical interface. Generally, this works fine, but I did notice that some of the included Metro apps are unable to detect a connection to the Internet. I’m not sure where the problem lies, but it doesn’t affect all the Metro apps, and I haven’t noticed any issues with any of the desktop applications I have.
Unfortunately, Hyper-V lacks a NAT feature. Typically, using an external connection means any traffic between the host and guest has to go to the router then back. A NAT option eliminates this in situations where guests don’t need to be available to other machines on the network.
Some networking features available to Hyper-V include “DHCP Guard,” which blocks DHCP messages from unauthorized virtual machines that may be pretending to be DHCP servers, and a similar “Router Guard,” which blocks route advertisement from guests that are pretending to be routers. Finally, the synthetic network adapter can be configured for hardware TCP/IP acceleration, as long as the host adapter supports the feature.
Next, creating a new virtual machine is easy, but not all options are presented in the wizard. I created identical machines for each OS, differing only in name. The wizard asks for the name of the machine, the amount of memory dedicated to the machine, the size of the virtual disk, and finally, the installation source. After the wizard completed, I further configured the VM and gave each one 3 virtual processors. One of the more interesting features I discovered was resource management. Hyper-V allows you to reserve a certain percentage of the host CPU time for a machine, as well as put a limit on the maximum amount of CPU time a guest is allowed to use.
Installing Windows 7 is as straight forward as can be, being exactly like installing on regular hardware. One thing I did discover is that Hyper-V emulates neither sound nor USB. If USB and Sound are needed, you can use Remote Desktop, which allows sound to be played locally, and local USB devices connected to the remote server. If you’re not worried about sound or USB connectivity, then which method is better is a toss-up. The built-in method performs faster, but you’re limited to the VESA resolutions with 4:3 ratios (1280×1024, also). Using RDP allows full screen on widescreen monitors, but graphics performance is noticeably slower. Finally, there is no shared folders feature, so any moving of files between host and guest will happen via standard networking, or to a more limitex extent, RDP.
Apart from graphics performance, disk and network performance seems on par with other VM software. Installing Windows did not seem to take longer than usual, nor did the installation of Visual Studio. Windows works as expected under Hyper-V.
Testing CentOS 6
CentOS 6 worked well under Hyper-V. This is not surprising, considering that Red Hat’s Enterprise Linux is officially supported. Hyper-V Integration Services for Linux are available as a downloadable ISO image from Microsoft’s website. These install higher-performing network and storage drivers, as well as enabling the â€œheartbeatâ€, which allows the hypervisor to know if a virtual machine is functioning or not. Make sure to download the latest version (currently 3.3); otherwise, be prepared for a world of hurt.
Installation worked well, but wasn’t perfect. The text-based installer had to be used, as Anaconda would crash when attempting the graphical install. Using the default configuration, network access isn’t available until the Integration Services are installed, since Hyper-V emulates its own network interface. However, Hyper-V can be configured to emulate an actual hardware interface, which is compatible with the Tulip driver. This allows the network to be accessible immediately, if needed.
After installation, video is supported, and performance is on par with Windows, with the same limitations. Again, the optimal way to run Linux graphical programs is over the network. I use the Xming X-server with Putty to launch programs on the virtual machine and have them display alongside my Windows apps. It is also possible to play sound via PulseAudio for Windows.
Also, as a quick benchmark, I compiled the Linux kernel, and then again under VMware, and the build times were about the same under both setups. The actual times aren’t important; I let them build in the background while I continued to use my computer for other minor tasks (primarily web browsing).
Installing Debian Squeeze and FreeBSD
The first thing I noticed with Debian is that the graphical installer worked! It did have a minor problem of severe input lag, but this also showed up with the text installer. Closing the display window than re-connecting fixes the problem (though it might take a couple attempts). Xorg worked fine after installation, but again, the available resolutions are limited to the older VESA resolutions.
I was surprised that FreeBSD 9 installed as easily as it did. Using the legacy network adapter worked like a charm, and Xorg worked as well. For both Debian and FreeBSD, I was pleasantly surprised. I was expecting anything that wasn’t officially supported to have issues, but this turned out to not be the case. In both cases, the guest machines should be configured for the legacy adapter, as neither has support for the native adapter out of the box.
Hyper-V is not a desktop virtualization product, nor is it really positioned as one (yet). I didn’t cover most of the features, as they are more useful for server usage. These include live migration, virtualized fibre channel and SAN, and strong remote management features. That said, there are indications that Microsoft will push Hyper-V in that direction. Currently, they offer virtual machines configured with different versions of Internet Explorer to allow for more convenient testing.
Hyper-V is close to be ready for widespread desktop use. The performance is there, as are the heavyweight features. However, the complete lack of of desktop integration makes it cumbersome to use. Additionally, the complex manner in which virtual machines access the network can have a negative impact on other software. That said, Hyper-V has been increasing in capability at a fairly rapid pace. Plus, it’s inclusion with even desktop Windows could mean some people won’t even bother with VMWare Workstation or VirtualBox.
About the author
David Hutchinson is a computer science student in California, with an eye towards operating system design.
Very interesting article. Thanks
Good article. I would have like for you to have explained yourself a little more when you mentioned competing products, but this wasn’t a vs. article.
Also, VMware kind of came out of nowhere. I thought you were just comparing to VirtualBox, then VMware comes in. What version of VMware was that anyway? ESX, ESXi, vSphere 5, Workstation, Server, Player?
That’s the exact same reason I’m using VirtualBox over KVM. USB, sound, and file passthrough are there; it’s the lack of a fullscreen display resolution that gets me.