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).
>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!
This would be useful for anyone who needs to run bleeding edge linux kernels. Most other hypervisors have poor support when you're pinned to testing distros (For security reasons). KVM and virt-manager are uh not exactly user friendly, so being able to use the KVM backend and always be compatible with the new kernels while having the UX and UI of vbox is actually a very huge deal. This is one of the main reasons I really really hope you all manage to upstream this.
I built and tried this, it worked great, so excellent work there. I found the processor CPU core counts being grayed out unpleasant, it's not clear to me how I am supposed to adjust my core and ram values now, maybe document this?
That's odd about the core count. I only get that behavior if my host system only has 1 CPU to begin with (tested in qemu/KVM with nesting). Could you comment on your host system parameters a bit?
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.
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.
