libvirt has put a lot of time into figuring out how to run QEMU in the most secure and performant way (specific low-privilege user, seccomp, all the right options for virtio, etc, etc). If you aren't using it then that's a lot of effort to reinvent, and you probably missed something out.
libvirt wasted a lot of effort into abstracting everything behind a ton of pointless hypervisor-agnostic cruft, only to then deprecate basically every single backend except QEMU.
I have used libvirt for almost a decade before going back to plain QEMU; I must say that using it from the CLI is an herculean task, you often have to edit plain XML in order to do whatever you want, and the cherry on top is that `virsh`is a huge pile of cow dung that often drags you into a Sisyphean fight against the aforementioned pointless abstractions - you find yourself configuring "domains" and "virtual networks" when you really only wanted to launch Windows to run Word.
When I had to run stuff on a big server which only does VM, maybe with OpenStack and other orchestration systems on top, libvirt was often _fine_. I still use it in those use cases (I usually prefer Proxmox this day, though), it works fine, I can connect to remote instances using SSH and Virt-Manager and I like how it often just works.
My use case, 90% of the time, is that I just want to run a damn Windows or FreeBSD VM on my workstation. I want to put disk images wherever I want because my root FS is small (often on ZVOLs, which are a big massive PITA to use with libvirt) without having to read a million different websites and man pages. I want it to work with my firewall configuration, which often changes due to the fact I have to do stuff with this machine, and I don't really care about 90% of the features of libvirt - I just want to run Windows every once in a while and I want my VMs to keep working without too much effort.
Thus, I run plain QEMU with the following configuration, which took me a solid 10 minutes to perfect:
- `nsbr0`, a bridge with a static IP configured using systemd-network;
- `qemu-bridge-helper` set-up in order to attach taps to nsbr0 automatically, using `-netdev bridge` (echo 'allow nsbr0' > /etc/qemu/bridge.conf);
- IP forwarding set to 1 and `masquerade` in nft.conf;
- OVMF downloaded from my distribution's repos;
- `spicy` to attach to a running VM;
- a 30 line script that spawns QEMU in a tmux. If I want to configure a new VM, I just copy paste this shell script and I put it in a directory together with a copy of OVMF_VARS.fd for the efivars.
Et voilà, I get VMs that just work, without having to wage any pointless battle against libvirt in order to get what I want. This is basically just a way to run KVM VMs that does not create a million firewall rules together with useless network interfaces, and doesn't force me to configure "storage pools" when the only thing I care about is running 2, 3 VMs max on my machine.
There's a reason why VMWare sells both ESXi and VMWare Workstation, and why people still love VirtualBox despite how shitty it is.
It's because more often than not something designed to run on servers is hardly be the best solution for a single user. The same features that make libvirt interesting on servers make it clumsy and overcomplicated on workstations, and the more I use it the more I realize it's true.
LXD recently added support for QEMU virtual machines in addition to its existing support for LXC containers, and it's almost completely replaced libvirt for me. It's great, pretty much just a matter of adding a `--vm` flag to normal `lxc launch` usage, e.g. `lxc launch images:debian/buster --vm`.
Yes, but the main reason I use VMs is to run different OSes. When I need to run other linux distros I normally use systemd-nspawn (or rarely LXC) and it's enough.
It's a type-2 hypervisor, so its performance is often quite worse than KVM. Also, its storage drivers are quite wonky, so I/O is often choppy and underwhelming. It has often a better desktop experience, though, except when you run Linux with VirGL. Also, virtualbox cannot emulate other platforms; for instance, I often run AArch64 operating systems in full emulation using QEMU on my x86_64 workstation.
Yeah I didn’t say ideal. But if you are on Win/Mac (there are a lot of those people) and need a Linux box without much fuss it’s a good go-to solution.
No, KVM (and FreeBSD's bhyve) are kernel modules that for all intents and purposes transform the host kernel into a type 1 hypervisor itself. The hypervisor is not, like in the case of VrtualBox or VMware workstation, running on top of the kernel, it is the kernel itself. The VMs spawned on KVM or bhyve have potentially full access to any hardware capabilities exposed to them. You can passthrough PCI devices to KVM VMs, for instance, using VFIO; you can also fully expose the host CPU allowing nested virtualization
A "true" type-2 hypervisor does not require any modification to the host kernel; at max it ships with a kernel module or two to help implementing things such as custom networking or to get a speed boost kernel side. For instance, it's trivial to share USBs with a guest on the fly with VirtualBox, because the VM is basically a process running on the host, so it can just tap into the USB stack and expose the device to the VM. This is not so simple with KVM.
