> However, no one forces you to use KVM directly. There is libvirt, a nice friendly wrapper for low-level virtualization techniques such as KVM or BHyve.<p>No, that's not what libvirt does. libvirt abstracts handling of tools like Qemu, or LXC. No lowlevel stuff.<p>When people talk about libvirt, they usually mean the libvirt daemon that manages VMs or containers using other programs and accepts XML machine descriptions as input.<p>The actual "libvirt" library is simply a front end library for talking to the daemon and is used internally by tools like virsh (CLI) or virtman (GUI tool).<p>Some ~7 years ago I used the libvirt library for a small in-house tool. It has the possibly shittiest API ever designed. No abstraction whatsoever, just a couple C functions that accept XML strings as input and possibly return XML responses from the daemon.
There is also this LWN article which covers much of the same ground: <a href="https://lwn.net/Articles/658511/" rel="nofollow">https://lwn.net/Articles/658511/</a><p>I do like here that the author here went beyond minimal hello world and also showed how to boot linux
It would be trivial for VirtualBox to use KVM instead of shipping an (out of tree) kernel module that uses the vmx instructions directly. I don't understand what exactly is blocking VirtualBox from doing that. They already use HyperV in Windows instead of abusing vmx directly.<p>They could still keep their qemu fork and everything so that the driver compatibility is still top-notch, but at least they would not require out of tree kernel modules, and VirtualBox would also be concurrently usable with other KVM users.
If you're interested in "other things" that can be done with KVM, take a look at the Solo5 "hvt" tender: <a href="https://github.com/Solo5/solo5/tree/master/tenders/hvt" rel="nofollow">https://github.com/Solo5/solo5/tree/master/tenders/hvt</a>.