I didn't say they have no reason to exist. I indicated they are moving towards becoming UI shells around standard OS features and/or other commodity software, which they are. Look at UTM, for instance. Even VMware Workstation and VirtualBox on Windows use HyperV under the hood if you have HyperV or WSL features enabled.
While everyone still seems to be busy disagreeing with me because of <insert favorite feature>, I'll mention that HyperV does have official support for transparent GPU paravirtualization with nvidia cards, and there are plenty of other open projects in the works that strive to "bleed through" graphics/gpu/other hardware acceleration api's from host to guest on other platforms and hypervisors. With vendors finally settling around virtio as somewhat of a 'standard pipe' for this, expect rapid progress to continue.
> Even VMware Workstation and VirtualBox on Windows use HyperV under the hood if you have HyperV or WSL features enabled.
VirtualBox is consistently (and significantly) slower when it uses HyperV as backend than when it uses its original driver, and many features are not supported at all with HyperV. In fact the GUI actually shows a "tortoise" icon in the status bar when running with HyperV backend.
For a start, the list of operating systems Hyper-V supports is an order of magnitude less than what VirtualBox supports. Likewise for emulated hardware, like 3D as mentioned a number of times here. The GUI is also much better on VirtualBox.
And Windows many times forces HyperV onto you, taking exclusive control of the CPU's virtualization features, thereby forcing VirtualBox to either use Hyper-V as a (terrible) backend .... or not run at all.
The use case is mainly interoperability with VirtualBox; they can still keep thier own disk/vm formats, guest tools, etc. and use HyperV as the 'virtualization engine'. Users that have workflows that call out to VirtualBox can continue to work; a lot of vm image tools (vagrant, packer) continue to work, etc.
But yes, of course you can also change your tools to use HyperV directly.
"Having to use HyperV" is not actually anything nefarious as the other comment seems to imply. You can't have two type 1 hypervisors running cooperatively on the bare metal and you cant implement your type 2 hypervisor hooks if you have a type 1 hypervisor running. So if you have enabled HyperV directly or indirectly by using WSL2 or installing any of the container runtime platforms (Docker Desktop et al) that use it, then you have to use HyperV as your hypervisor.
Note this is different than nested virtualization (ESXi on HyperV, etc.) which is supported but a completely different beast.
For the same reason you cannot run Xen and KVM VM's simultaneously on Linux (excepting nested virtualization).
> "Having to use HyperV" is not actually anything nefarious as the other comment seems to imply. You can't have two type 1 hypervisors running cooperatively on the bare metal and you cant implement your type 2 hypervisor hooks if you have a type 1 hypervisor running.
The nefarious part is that Windows enables Hyper-V even if you don't actually use Hyper-V VMs and never will. KVM doesn't take exclusive control of VMX until you _actually_ run a KVM VM.
By the way, the distinction between type 1 / 2 is purely academic at this point: there is no definition where KVM is a type 1 hypervisor and VirtualBox isn't, as they are _literally_ the same conceptually-wise: both are a kernel module that implements a VMX manager/root. Same on Windows. The only remaining type 2 hypervisor these days is kqemu which can still work in binary translation mode (and therefore can work even without access to VMX).
> The nefarious part is that Windows enables Hyper-V even if you don't actually use Hyper-V VMs and never will.
It does not actually enable it by default but there are many settings or apps that can cause it to become enabled. Virtualization-based-security, WSL, container tools, etc. Providing a hypervisor and related functionality is part of what a modern OS kernel should do! It's not nefarious!
In truth it's not; however if the software has to do extra things like, for instance, translate io calls to a virtualbox disk format that hyperv cannot natively support or do an extra memcpy on the video framebuffer to get their UI to work then there will be necessary performance impacts. How fast a guest os "feels" is mostly down to the performance of the virtualized devices and not necessarily the overhead of virtualization itself.
Yes, it is; even the official documentation mentions it (and recommends you disable Hyper-V) and it is FAQ #1 in the support website.
One of the reasons mentioned is that VirtualBox runs (some) emulated devices in kernel space but is not allowed to do when running with Hyper-V. The official API forces custom devices to strictly be user space, and only some basic hardcoded devices are emulated from kernel space.
The "secret sauce" of a desktop virtualizer is in part in the selection of devices it emulates, so this severely cripples VirtualBox.
GPU-P is a pita to keep updated and is half baked. So many things just don't see or use the Nvidia drivers properly. If you want 60fps, Parsec is the only solution I found for desktop/mobile Nvidia graphics.
Once I discovered that, I haven't looked at parsec. Moonlight/sunshine (whatever the pair is) is... terrible. And, When I was looking YUV444 wasn't a feature. Or, at least not one anybody actually knew how to use.
I didn't say they have no reason to exist. I indicated they are moving towards becoming UI shells around standard OS features and/or other commodity software, which they are. Look at UTM, for instance. Even VMware Workstation and VirtualBox on Windows use HyperV under the hood if you have HyperV or WSL features enabled.
While everyone still seems to be busy disagreeing with me because of <insert favorite feature>, I'll mention that HyperV does have official support for transparent GPU paravirtualization with nvidia cards, and there are plenty of other open projects in the works that strive to "bleed through" graphics/gpu/other hardware acceleration api's from host to guest on other platforms and hypervisors. With vendors finally settling around virtio as somewhat of a 'standard pipe' for this, expect rapid progress to continue.