
KVM host in a few lines of code - stargrave
https://zserge.com/posts/kvm/
======
st_goliath
> 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.

No, that's not what libvirt does. libvirt abstracts handling of tools like
Qemu, or LXC. No lowlevel stuff.

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.

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).

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.

~~~
qhwudbebd
I think you underappreciate libvirt here. The qemu command line interface is
really quite ugly and awkward to use. You might imagine that, in wrapping it,
libvirt might fail to make it worse. But they actually succeeded!

(To be fair, if you're stuck for ideas for making something nastier, wrapping
it in XML isn't a crazy starting point.)

~~~
asguy
qemu has its own (often unnoticed) config file format `-readconfig fname`. I
use it instead of the command line when things are getting out of hand.

~~~
rwmj
-readconfig is incomplete. You cannot express all features (and even several common features) through the config file. Also the config file field names are sometimes different from the corresponding command line names. It's considered an appendix by the upstream developers so don't be surprised if it disappears one day.

~~~
asguy
What features have you had problems with?

------
zokier
There is also this LWN article which covers much of the same ground:
[https://lwn.net/Articles/658511/](https://lwn.net/Articles/658511/)

I do like here that the author here went beyond minimal hello world and also
showed how to boot linux

~~~
JoshTriplett
It's remarkable how much traction that article has gotten over the years; it's
also cited by crosvm, rust-vmm, Firecracker, and many other virtualization
projects.

~~~
mjb
Thanks for writing it!

I've shared that with a lot of people, because it's a great introduction to
stepping through the abstraction of QEMU (or libvirt or whatever) and seeing
what KVM can do. There's some good articles that start from VMx on up, which
are fun too, but much more involved than KVM.

In general, this is a kind of technical content I'd like to see more of:
here's a lower-level API, what can I do with it?

~~~
JoshTriplett
I enjoy such articles as well, especially when the lower-level API is
something that most people only use through one piece of complex high-level
software.

Similarly, it's fun to study containers starting with "unshare" and "clone".

~~~
teknopaul
Top tip, thanks

------
AshamedCaptain
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.

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.

~~~
reilly3000
Methinks IP may have something to do with that, but I'm not sure how.

~~~
monocasa
I seem to remember that they've said it's because they think that their kernel
driver has higher perf than KVM on latency sensitive I/O.

------
mato
If you're interested in "other things" that can be done with KVM, take a look
at the Solo5 "hvt" tender:
[https://github.com/Solo5/solo5/tree/master/tenders/hvt](https://github.com/Solo5/solo5/tree/master/tenders/hvt).

