Yes, this is indeed nice. I have a Chromebook as well and the integration with Linux apps is super seamless. The major usecase for VBox is mostly Windows, though.
We're offering commercial support. We can also help with graphics virtualization and other topics (e.g. performance tuning and automated testing in real world scenarios).
We have used this with recent Intel GPUs that support SR-IOV. This is what you see in the video on the cyberus website. Intel hasn't managed to upstream the drivers for this yet and you have to piece together things, which is very unpleasant. But we are there to help, if someone wants to use this in a professional setting.
We used to have support for Intel GVT-g GPU virtualization as well, which was more of a software solution. This doesn't work with modern Intel GPUs anymore.
>How does this work in licensing terms? If VB foss enough?
It's as FOSS as the VirtualBox open source edition.
> Do you expect Oracle to merge this?
That would be nice, but I wouldn't hold my breath. Oracle gonna Oracle.
> If oracle doesn’t merge this, will you keep on maintaining it, potentially forking VirtualBox?
We don't intend to fork VirtualBox. VBox has a somewhat modular architecture where you can plug-in different hypervisor backends. That's what we did. It's not as modular, but our changes to core VirtualBox code is very small.
As far as our plans go, we are pretty open at this point. We are very interested to get to know people that find this useful!
It depends on your setup and workload. On a recent Intel CPU, our performance dashboard shows +10% for some benchmarks. It's hard to make a general statement though.
The KVM backend in vanilla VBox cannot be activated without changing the code. If you tried it, you tried the vanilla VBox hypervisor (vboxdrv) instead of KVM.
Well, KVM is used by Google and AWS and others for their clouds. As such, there are a lot of eyes on KVM code. The vboxdrv kernel module that provides the same functionality in vanilla VBox definitely has fewer people looking at it. It also has anti-features, such as code upload from the userspace VirtualBox process to the kernel. This is also the largest security issue with vanilla VBox, because a lot of emulation code runs directly in the kernel.
From a performance perspective, it's a bit more complicated. KVM has support for modern virtualization features (Intel APICv, AMD AVIC, etc) that vanilla VBox lacks. You get these in the VirtualBox/KVM version. On the other hand, vanilla VBox emulates most devices in the kernel (see above). So SATA emulation in vanilla VBox is very fast compared to KVM/Qemu or KVM/VirtualBox for a bit unfair reasons. Modern devices, such as virtio or NVMe, are not as impacted by that.
tl;dr
So the performance you get depends on your workload. If it's very interrupt heavy, VirtualBox/KVM will win. If it uses antiquated virtual devices (SATA), vanilla VirtualBox (with vboxdrv) will have an edge.
The name KVM is a bit confusing. It doesn't do anything fundamental different than VirtualBox. The difference is that KVM comes by default with any Linux. VirtualBox ships it's own Linux kernel module for that. That has drawbacks. You typically can't use the newest Linux or the newest features.
KVM also always has the hottest new (performance-relevant) features, because Intel and AMD will always build their hot stuff into KVM first.
There is no real connection to UML here. Hardware virtualization (Intel VT, AMD-V) are much faster in practice and also don't require the guest operating system to be heavily modified. So besides as curiosity or test vehicle, approaches like UML are pretty dead.