Client Hyper-V vs. VirtualBox – Which is Best for You?

Desktop hypervisors are a popular technology among technophiles, leading to many debates about which are the best, such as Hyper-V vs. VirtualBox. We have all sorts of reasons to use them. Some of us need to test software that other people wrote to see if it’s any good. Some of us need to test the software that we wrote to see if it’s any good. Sometimes, we need to restrict activity to a temporary environment. Other times, we just want to keep our primary environment out of the clutches of an invasive installer. Coming up with reasons to use a desktop hypervisor is simple. As mentioned at the outset, deciding which desktop hypervisor to use can be trickier. This article will compare and contrast Hyper-V vs. VirtualBox and see which one you may want to use over the other.

As a rule, I do not tell people which product to use, including Hyper-V vs. VirtualBox. I believe that you should pick what best suits your needs. If nothing is available that aligns perfectly, mix and match until you get as close as you can. I do not like it when people choose their product first and then throw out convenient justifications for that choice. Two common examples are, “Nobody ever got fired for buying IBM,” and, “This product is the most popular.” My purpose here is not to dictate which product is superior but to guide you toward an informed decision. That decision might be to use both hypervisors.

Client Hyper-V and VirtualBox: A Technology Overview

We’re all technology people here, so let’s begin by looking at these two hypervisors from a technological standpoint, Microsoft Hyper-V and Oracle VirtualBox

They’re Not Each Other’s Type

The most obvious difference between the two products is that Client Hyper-V is a type 1 hypervisor and VirtualBox is a type 2 hypervisor. Now, every time that I say “Hyper-V is a type 1 hypervisor” and then try to explain what a type 1 hypervisor is, I invariably get at least a few comments that tell me that my description is all wrong and that, “Hyper-V is…,” and then the commenter proceeds to describe Hyper-V as a type 2 hypervisor. Either my explanations aren’t very good or people just don’t believe that Hyper-V is a type 1 hypervisor. I’m hoping that the biggest part of it is that the line between type 1 and type 2 is not nearly as solid as some people would have you believe, and therefore these commenters just see things differently.

Anyway, I am going to attempt a new method of explaining type 1 vs. type 2, but restrict it to this context.

Hypervisor Startup Process: Oracle VirtualBox

I’m going to start by explaining how VirtualBox is started. It is a type 2 hypervisor and the easiest to understand.

1. The physical computer is started
2. The physical computer’s boot system (BIOS or UEFI) hands control over to the operating system installed on the hardware. For Oracle VirtualBox, that can be Windows, Linux, OSX, or Solaris
3. The user (that’s you) starts the VirtualBox application.
4. The user (that’s you) selects which virtual machine(s) to start. VirtualBox spawns hosting processes

Simple, right?

Hypervisor Startup Process: Client Hyper-V

As a type 1 hypervisor, Client Hyper-V’s startup routine is quite different from VirtualBox’s on a fundamental level.

1. The physical computer is started
2. The physical computer’s boot system (BIOS or UEFI) hands control over to Hyper-V
3. Hyper-V starts the management operating system. The management OS can only be Windows, Windows Server, or Hyper-V Server
4. In response to automatic settings or manual user (that’s you) instructions, Hyper-V spawns partitions for virtual machines

There are variances in the way that different type 1 and type 2 hypervisors accomplish their goals, so I can’t just make a few blanket statements and walk away. We’ll take a look at a few of the generic differences.

The Importance of Type Differences

You can find a great deal of written material on the differences between type 1 and type 2 hypervisors. In light of the capabilities of modern hardware, virtualization software, and operating systems, most of that material is of questionable value. I’m going to skip the questionable parts and only deal with what we can verify.

For this discussion, the most important distinction between type 1 and 2 is that a type 1 hypervisor is always on. The only way to “stop” Client Hyper-V is to turn the computer off or remove the role. Sure, you can stop the “Hyper-V Virtual Machine Management” service, but that’s not Hyper-V. It’s a management service. I’m guessing that’s why they gave it that particular name. Stopping it prevents you from managing any of the virtual machines, but it doesn’t affect the virtual machines or the hypervisor. You cannot see Windows 10 Hyper-V by poking through the management operating system.

On the other hand, Oracle VirtualBox can be opened and closed at will. You can locate the VirtualBox application, its service, and its virtual machines in the management operating system’s Task Manager. If you close the main interface, any active virtual machines will continue running because VirtualBox will leave its hypervisor kernel in memory. If you stop the last VirtualBox virtual machine, then there’s no more VirtualBox. You’ll need to start it again to get any virtual machines running.

The type differences of Client Hyper-V and VirtualBox have several consequences:

• Client Hyper-V’s management OS uses vCPU like the virtual machines
• You need to use Hyper-V performance counters to see anything about Client Hyper-V’s resource usage, and that doesn’t tell the entire tale
• Hardware assignment works differently
• Resource priority works differently

Hyper-V vs. VirtualBox: Hardware Access

When I read the complaints about Windows 10 Hyper-V vs. Virtual Box, hardware issues jump right to the top of the pile. Inevitably, comparisons are made to VirtualBox, VMware Workstation/Player, and other type 2 hypervisors. Complainants rarely fail to mention how device issues are nearly non-existent in those products. The root of the problem sources right to the hypervisor type.

When VirtualBox (or any other type 2 hypervisor) spawns a virtual machine, its container runs inside the management operating system where applications live. Like other applications, they do not have direct hardware access; they must request device access through the operating system.

For example, let’s look at my Windows 10 desktop’s assignment of my sound hardware:

Sound Hardware Allocation

I have multiple sound hardware devices and multiple applications. All hardware access and assignment occur through the operating system. Note: The above is for illustrative purposes only. You do not use Volume Mixer to connect VirtualBox guests to sound hardware.

So, when you turn on a VirtualBox guest, you can use its application container to request access to hardware.

Now, think about Client Hyper-V. The management operating system runs in its own partition separate from the guest operating systems. Unlike VirtualBox, Client Hyper-V’s guest operating systems do not have any projection into the management operating system. They can’t just call the API in the management OS the way that VirtualBox guests can because they can’t reach it. There are features in Client Hyper-V that can help you to address this difference, but this is all caused by fundamental differences in hypervisor technologies.

The takeaway from this section: if you want to use USB-attached hardware and external disks with your guest virtual machines, you will have an easier time with VirtualBox.

Hyper-V vs. VirtualBox: Hardware Presentation

This section connects strongly to the previous section and helps to understand how hardware is accessed between Hyper-V vs. VirtualBox. If you flip through a virtual machine’s settings tabs in VirtualBox, you’re going to find a lot of things that you won’t see in Hyper-V. You must decide between a PIIX3 or an ICH9 chipset. You must choose between an Intel audio controller, an ICH AC97 audio controller, and a SoundBlaster 16 audio controller. If you allow a virtual machine to have a USB controller, you must pick from a 1.1, 2.0, or 3.0 device. Hyper-V doesn’t ask you to make any choices like that.

The difference here is also related to that whole type 1 vs. type 2 discussion. Type 2 hypervisors are designed to run in a much wider range of environments, which presents any number of problems. To address those issues, type 2 hypervisors make extensive use of emulation. Emulation is when a software construct mimics the interfaces of a hardware device. VirtualBox emulates all of the things that I listed in the preceding paragraph and more. Client Hyper-V emulates very little — most notable are its IDE controller and the legacy network adapter.

Emulation solves the problems of widespread applicability. As you can imagine, this versatility comes at a cost. The entire purpose of speciality hardware, such as network cards and video adapters, is that they handle their respective workloads so that the burden doesn’t fall elsewhere. Since they’re built specifically for their tasks, they (presumably) do it better than other components built with other goals in mind. With emulated hardware, your general-purpose CPU takes on all the responsibility of dedicated hardware.

The takeaway from this section when considering Hyper-V vs. VirtualBox is: VirtualBox works with a wider range of hardware on a wider range of systems at the expense of performance-impacting overhead.

Hyper-V vs. VirtualBox: Resource Priority

Because VirtualBox only runs within the hardware-installed operating system, it is at the mercy of that operating system’s scheduler. One of the reasons I skipped any of the typical discussions about CPU rings is that VirtualBox includes this dialog:

VirtualBox Acceleration Settings

What that means is that VirtualBox can access the same features that many people only associate with CPU ring -1 and the virtual machine monitor extensions used by “true” type 1 hypervisors.

However, VirtualBox is still bound by restrictions imposed by the hardware-installed operating system. If you’ve got a run-away Flash game soaking up memory and CPU in your hardware-installed OS, the OS can and will cause your VirtualBox virtual machines’ performance to suffer to any degree that it likes. If it comes right down to it, you can use Task Manager to kill any VirtualBox process or guest.

In contrast, looking at Hyper-V vs. VirtualBox, Client Hyper-V provides the same prioritization controls as its server-based big brother. You can prioritize CPU and memory, enable storage Quality of Service, and set network bandwidth limitations for all of your virtual machines.

The takeaway from this section when considering Hyper-V vs. VirtualBox: Client Hyper-V grants fine-grained control over resource prioritization; VirtualBox does not.

Hyper-V vs. VirtualBox: Video Acceleration

This section is a bit different from the preceding discussion because nothing here will be universally true when comparing Hyper-V vs. VirtualBox. I will recount how differences in the two hypervisors influenced my experiences. Your mileage may vary.

When comparing Hyper-V vs. VirtualBox, Client Hyper-V and VirtualBox emulate video. In my experiences, I have been unable to distinguish that one is better than the other when it comes to 2D acceleration. I don’t believe that I ask a great deal of 2D acceleration, but I also know that most modern desktop operating systems utilize 2D acceleration in ways that aren’t always obvious until they’re not available. Two prime examples are font smoothing and window animations. With the expressed reservation that your mileage may vary, I do not believe that 2D acceleration should factor strongly in when comparing Hyper-V vs. VirtualBox.

3D acceleration is a different story. Client Hyper-V offers RemoteFX. In my experimentation, it works very well within the confines of what it is designed to do. RemoteFX does not project the video adapter into the guest operating system, so you cannot access all of its functionality. RemoteFX has also worked on every system that I’ve ever attempted to use it with, as long as it contained the requisite 3D-accelerated WDDM-compliant driver.

3D acceleration in VirtualBox is a completely different story. I have utterly failed to ever get it to work well enough to even display a basic Windows desktop properly. I never got close to trying any 3D acceleration features. So, I can’t give you any meaningful comparisons between Hyper-V vs. VirtualBox.

The takeaway from this section: 2D acceleration appears to be a wash between Hyper-V vs. VirtualBox. 3D acceleration seems more reliable in Client Hyper-V.

Hyper-V vs. VirtualBox Performance

Summarizing the previous sections and the differences in Hyper-V vs. VirtualBox in terms of architecture, hardware access, resource management, and other areas, let’s talk briefly about Hyper-V vs. VirtualBox performance. 

With Hyper-V vs. VirtualBox performance, Hyper-V has the edge on VirtualBox. Client Hyper-V has a more direct path to the hardware than VirtualBox which is at the mercy of the host operating system for CPU and other resource scheduling as mentioned above. Client Hyper-V is essentially the same technology found in Hyper-V Server, with a few limitations.

It means it is better able to handle resource demands and other performance-intensive processes compared to Type 2 hypervisors. Ultimately, if performance is the consideration that takes priority, Hyper-V edges out VirtualBox.

Hyper-V Vs. VirtualBox: Virtual Hard Disk Compatibility

VirtualBox supports several virtual hard disk formats. You can choose from:

• VDI, the native VirtualBox format
• VMDK, VMware’s format
• VHD, Microsoft’s format
• HDD, Parallel’s format
• QED and QCOW, used in QEMU and other hypervisors

You cannot use VHDX with Oracle VirtualBox. The ability to use another hypervisor’s disk format does not necessarily mean that you’ll be able to smoothly transition a virtual hard disk from one hypervisor to another, either.

The takeaway from this section when comparing Windows 10 Hyper-V vs. VirtualBox: this is almost general information because the ability to use multiple virtual hard disk formats is not as useful as it might seem at first. If you plan to attempt to move a virtual hard disk from one platform to another without employing a converter, VirtualBox is your best choice.

Hyper-V vs. VirtualBox: Other Video Features

VirtualBox provides a few video features that Client Hyper-V does not directly compete with.

• Client Hyper-V can display only on one monitor or all monitors. You can specify between one and eight monitors for VirtualBox.
• VirtualBox provides a server mode that allows remote computers to connect to the hardware-installed operating system to view the console of one or more specific guests. Each endpoint allows multiple simultaneous remote connections. Client Hyper-V provides similar functionality with vmconnect.exe, but it is not as versatile.
• VirtualBox can make a video recording of a guest operating system.
• VirtualBox allows you to set a virtual machine to “Seamless” mode. Applications that you start in the virtual machine will appear and operate as though they are running in the hardware-installed operating system.

The takeaway from this section comparing Microsoft Hyper-V vs. VirtualBox: if any of these features appeal to you, VirtualBox is the only choice.

Hyper-V vs. VirtualBox: Source Code Access

VirtualBox is open-source software. If you don’t like something and believe that you can do better, have at it. If you just want to know how it works, download the code set and dig in.

Microsoft is gradually warming to the notion of open-source and has submitted a great deal of code to the community. Windows is notoriously absent. As I understand it, the Hyper-V code base is very tightly coupled to Windows. I have my doubts that we’ll ever see Hyper-V’s code published.

The takeaway from this section when comparing Hyper-V vs. VirtualBox: if using an open-source hypervisor is important to you, that disqualifies Client Hyper-V.

Hyper-V vs. VirtualBox: Usage License

Client Hyper-V ships as a component of Windows 10 Professional and Enterprise SKUs. If you’re otherwise licensed to use one of those, then you are licensed to use Client Hyper-V.

Oracle licenses the current core VirtualBox package (versions 5.x+) under GPLv2. They also provide some “extensions” under a separate license called the “VirtualBox Personal Use and Evaluation License“. I don’t personally use any of these features, although they do encompass some of the features I spoke of above. I did not dig deeply into the terms of this license, but it appears to be fairly generous. As always, I recommend that you allow trained legal counsel to field any of your licensing questions.

As far as guest operating system licenses between Hyper-V vs. VirtualBox, those are a separate tale. Neither Client Hyper-V nor VirtualBox provides for any guest operating system licenses at all. If you install any flavor of Windows or Windows Server into a guest operating system under either hypervisor, you must properly license the hardware.

The takeaway from this section: licensing is always important, including between Hyper-V vs. VirtualBox.

Acquiring Client Hyper-V and VirtualBox

If you’re running Windows 10 Professional or Enterprise, then you only need to enable the Hyper-V role to start using it.

VirtualBox is available from its website: https://www.virtualbox.org/

VirtualBox vs. VMware vs. Hyper-V

Another comparison that is often made is VirtualBox vs. VMware vs. Hyper-V. When considering the three hypervisors, many of the same comparisons we have already made apply when extended to include VMware Workstation. VMware produces a desktop virtualization product, called VMware Workstation, and an enterprise virtualization product called VMware vSphere. VMware Workstation is a Type 2 hypervisor, compared with VMware vSphere being a Type 1, bare-metal hypervisor. 

Client Hyper-V being a Type 1 hypervisor holds some of the similar advantages over VMware Workstation as it does with VirtualBox. VMware Workstation uses device emulation to allow guest operating systems to interact with the host hardware. Compared to VirtualBox, VMware Workstation has the polished feel of a pay-for product when compared to VirtualBox and certainly aligns itself with the VMware ecosystem. With VMware Workstation, there is direct integration with VMware vSphere, allowing admins to administer vSphere from VMware Workstation. You can also perform seamless moves of virtual machines in VMware Workstation to VMware vSphere.

VMware Workstation is a paid product and requires a license. However, it can run on Windows 10 Home, whereas Client Hyper-V is not available in Windows 10 Home. It is considered by most to be a Cadillac of Type 2 hypervisors. 

VirtualBox is still the only truly “free” offering of the three and can be run on any edition of Windows 10 and may arguably still provide the best value out of the three solutions.

To properly protect your Hyper-V virtual machines, use Altaro VM Backup to securely backup and replicate your virtual machines. We work hard perpetually to give our customers confidence in their Hyper-V backup strategy.

To keep up to date with the latest Hyper-V best practices, become a member of the Altaro DOJO | Hyper-V now (it’s free).

Wrapping Up

Client-side hypervisors provide a great way for end-users to have multiple isolated environments for running multiple operating systems, development environments, sandboxes, labs, and even browsing VMs, without the need for multiple client systems. Comparing Hyper-V vs. VirtualBox is an interesting discussion that comes down to what use case you are trying to solve and, often, if you are running Windows 10 Pro and higher, or Windows 10 Home edition.

VirtualBox provides very robust features and capabilities for a free hypervisor and is arguably the best value if you do not own a Pro, Enterprise, or Education SKU of Windows 10 since Home Edition does not contain the Hyper-V feature.

Whatever the case, comparing Hyper-V vs. VirtualBox helps to explore the very interesting world of client hypervisors, their benefits, and use cases.