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 ^aEURoeWindows Features^aEUR 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.
Testing Windows
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 ^aEURoeheartbeat^aEUR, 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.
Final Thoughts
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.
Maybe I am misunderstanding you but VirtualBox can run in fullscreen mode and the resolution adapts to your monitor.
Yeah, that’s exactly what I’m saying. KVM can’t do that, so I’m using Virtualbox instead.
Hyper-V is really designed to compete against ESX, ESXi, and vSphere.
VMware Workstation is in a different class of product. VMware Server has reached end-of-life.
Right, but the author didn’t specify what he was comparing it to. He just said VMware, which could mean anything like that. Including VMware Server even if it is EOLd.
It was criticism to show he needs to be more specific in his writing. It’s obvious to him what he’s comparing it to, but not to us.
Including Hyper-V in Windows consumer versions, versus server versions, automatically puts Hyper-V into the VMware Workstation and Virtualbox class of product.
Edited 2012-07-01 19:04 UTC
Oops. I was comparing against both VirtualBox an VMWare Workstation at different times. I used to use VirtualBox, but now I have access to VMWare Workstation 8, which I’ve found to be much more stable than VirtualBox.
That’s not really a good comparison. V-Server competes with server virtualization products like Xen(Server), KVM and vSphere/ESX(i)/Whatever-vmware-calls-it-today. It’s not intended for desktop use in the first place.
Well, Microsoft is beginning to position Hyper-V for desktop use, so comparing it in that context is fair.
I’m assuming that the positioning for desktop use may include the moving of win32 into a Hyper-V session rather than the frankenstein setup that uses a maze of registry hacks and shims as to get a desired result?
It may be a Frankenstein setup, but App-V works. Apps are isolated from each other, and will uninstall cleanly. And you don’t have to manage a whole other operating system, because the apps are still running (through a redirection layer) on top of your primary OS.
No worries, just realize readers only know what you tell them, and little details like that aren’t obvious to people who weren’t there.
There’s no NAT? What about Internet Connection Sharing, does that still exist for Windows 8? If so, that would work.
On Windows Server, you could setup NAT by installing the routing role on the host machine.
Not sure how it is on Windows client. Perhaps they’re planning to make the integration available via a post-RTM install, like they did with XP Mode on Windows 7? But XP is going to reach end-of-life soon, so are they still making it available for enterprise customers?
Using ICS would work, but it’s not exactly a great solution. All your guests that are configured for host-only networking would become connected. As far as I know, ICS also isn’t configurable via group policy, or via the management console (If I’m wrong, let me know).
So, we’re talking about virtualization for desktop use. For such scenariosn, the things listed (no NAT, sound or USB, no shared folders, also “If you have other VM software installed at the same time, it will likely refuse to run”) do not make it particularly interesting and/or usable. I’d take VBox any day for desktop use over it.
Hyper-V = lol
I would never ever put windows on iron. never.
and even less, put guests on top of it..
But I avoid windows in general.
Virtualbox is ok for playing around with OSes for noobs.
VMWare, for big enterprise that needs lots of bells and whistles and pay well..
KVM awesome (a tool for pros, arguable faster than vmware)
For dedicated server or on desktop.
Xen too
FreeBSD will be officially supported as a Hyper-V guest.
http://blogs.technet.com/b/openness/archive/2012/05/10/freebsd-supp…
It was presented at BSDCan 2012.
http://www.bsdcan.org/2012/schedule/events/287.en.html
That is awesome. I’m a big fan of FreeBSD. It’s my *nix of choice, and I’m always happy to see it get broader support.
When Hyper-V is activated on 2008/R2 the host system becomes a client of the Hyper-V server. The experience is seamless to the user but the transition happens when it’s activated. So my question is, how does this affect performance on the host system for things like games or other programs that rely on direct access to hardware? There is usually a performance degradation that happens when running software like games in virtual machines. Has Microsoft found a way around that on the host system?
There doesn’t seem to be any performance penalty for the host, I run hyper-v on a AMD X2 2.4Ghz box with 8G of ram, running 2 Win2k8R2 vms, a 2k3r2 VM and a Debian VM, and can watch 1080p video, play games, whatever, while the box is streaming video to every other device in the house using tversity. It might be running ~50-60% cpu, but it’s responsive and fast.
At least for Windows 8, Hyper-V is a service like any other (mostly), and doesn’t virtualize the host like 2008/R2.
I’ve been playing Deus Ex lately, and haven’t noticed a performance or quality difference with Hyper-V installed or not.
Edited 2012-06-28 18:50 UTC
You would not be able to feel the performance penalty in client usage. You would need to benchmark your machine before and after adding the Hyper-V role to get an accurate measurement.
Hyper-V is a hypervisor, or Type 1 virtual machine monitor. By definition, it runs directly on bare metal. This means that all OSes — including the primary OS — run on top of Hyper-V, rather than directly on the CPU.
The way it worked on Windows Server was that the primary Windows instance got direct access to the hardware, while the other virtual machines didn’t. Thus, the primary Windows instance had access to sound and USB, even though it was running on top of Hyper-V, which did not provide emulated or enlightened devices for these functions.
Windows Server began running on top of Hyper-V as soon as the Hyper-V role was installed — even if you created no other virtual machines. (This is why installing/removing Hyper-V required a reboot.)
Microsoft has stated that a CPU with SLAT will be required to run Hyper-V on Windows 8. This is presumably because high-performance video drivers will thrash the TLB if the CPU does not have SLAT. This may be acceptable on a server, but would be unacceptable on a workstation.
I’m kinda out of the whole windows loop. Can anyone explain why Hyper-V is there on a desktop OS? Did they kill off virtualPC? I would have thought that virtualPC would have made more sense on a desktop.
yes hyper-v killed off virtualpc. I wish they would implement hyper-v like xenclient…basically it boots to a light desktop with all your virtual machines running on it..it is a bare metal hypervisor as well.