"around" is the best way to describe it; the libvirt/virt-manager ecosystem isn't dead, but redhat killing off ovirt/rhev support drained a lot of resources out of it.
And for some bizarre reason people decided that the much less mature (both organizationally and technologically) proxmox VE is the best thing since sliced bread, so everyone who does care about linux virtualization is now trying to hammer some homelabbers' collection of perl scripts into a replacement.
Until recently, I used it routinely for VMs, and it worked solidly and reliably. There is a ZFS storage backend as well, always nice to see since I've loved to use zvols for VMs, even when I did VirtualBox on OpenIndiana back before ZFS on Linux was viable.
But I found that Proxmox fit my needs much better than wrestling vanilla Ubuntu or Debian into a VM server, particularly for things like backup/restore and instrumentation, or setting up a bridge on a desktop-based installation. Since both are based on QEMU/KVM, it wasn't too hard to move my VMs (one thing you might need to look out for is changing network interface names).
It's usable (?) as a toy: numerous gui inconsistencies and lack of security isolation [0].
Can't say whether the of lack funding (move to Cockpit from Red Hat) is the reason, or maintainer is just an obstructionist (strictest feature policy).
I use it multiple times a day, and it's great! It doesn't try to hide details from you, but it does put a well-thought out GUI in front so you don't have to stumble around. It's not perfect, does take some getting used to, but it's stable and relatively comprehensive. I love it. Caveat: I'm mainly using it for home usage in my home lab.
I also love that I can drop to the CLI easily for scripts and it plays perfectly well with virt-manager, and it can be used easily over SSH to manage VMs on a remote host (which is key to my use case).
This is another area I hope I'm able to migrate to systemd. I already use nspawn for containers but vmspawn is still a bit new and limited in the options. Once it gets there though it'll be nice to have system+containers+vms under one consistent roof.
I've been using Canonical's LXD for this, under Debian Trixie. Nowadays I can usually get away with just running containers for things I need vs full-blown VMs. I guess the only downside is that in order to get the latest version of LXD installed easily you'd have to do it via snap, which I understand is a dealbreaker for many.
Damn, I didn't know about vmspawn, will keep an eye. But I've been running VMs inside nspawn containers by binding /dev/kvm and using plain qemu. Works great.
Membership in the libvirt group is root-equivalent, not a permissions fix. Through qemu:///system it lets you attach arbitrary host block devices to a VM, so anyone in that group can mount and read the host's own disk. If you want to manage VMs without root or that group, use qemu:///session instead: unprivileged, images live under ~/.local/share/libvirt, no sudo. Tradeoff is you lose bridged networking without a setuid helper.
virt-builder is an alternative to installing a guest OS from scratch. It has a selection of popular guest OSes template images that you can quickly install non-interactively.
It's convenient when you don't want to manually install a guest and also don't want to figure out preseed/kickstart/etc.
It makes creating new KVM guests easier and has handy features like the ability to copy in ssh keys so you can connect to the guest right away.
I think this is a backwards way to set up VMs. "Installing a guest" is the wrong concept. Use a VM image pre-prepared from your favourite distro to skip that step. cloud-init is the standard way for it to specialize to your use case.
Honestly though... why not just systemd containers with minimal mounts, and if you're needing an ip, what not an unprivledged LXC container? The surface area is far smaller and they're way easier to inspect.
Mama, what a read! Nice work! Same story on macos: recently ditched the big (corpulent, distended, ossified) vagrant + virtualbox _repositories_ for some spritely lima + apple virtualization framework scripts, and been happier for it.
It was a forklift, to be sure, but the machines're snappier, & you buy yourself a little headroom.
27 comments
[ 3.3 ms ] story [ 55.3 ms ] threadWonder if it’s still around ? Hope it’s doing well !
And for some bizarre reason people decided that the much less mature (both organizationally and technologically) proxmox VE is the best thing since sliced bread, so everyone who does care about linux virtualization is now trying to hammer some homelabbers' collection of perl scripts into a replacement.
It would be funny if it wasn't so sad.
Well it has been replaced. We don't need anything now.
But I found that Proxmox fit my needs much better than wrestling vanilla Ubuntu or Debian into a VM server, particularly for things like backup/restore and instrumentation, or setting up a bridge on a desktop-based installation. Since both are based on QEMU/KVM, it wasn't too hard to move my VMs (one thing you might need to look out for is changing network interface names).
Little wonky to get the config files all setup for a VM but LLMs make that a breeze these days.
Can't say whether the of lack funding (move to Cockpit from Red Hat) is the reason, or maintainer is just an obstructionist (strictest feature policy).
[0] https://github.com/virt-manager/virt-manager/issues/358
VM guests should be considered trusted? Are you kidding me? That’s my number one usage -to operate software I do not trust.
I also love that I can drop to the CLI easily for scripts and it plays perfectly well with virt-manager, and it can be used easily over SSH to manage VMs on a remote host (which is key to my use case).
It's convenient when you don't want to manually install a guest and also don't want to figure out preseed/kickstart/etc.
It makes creating new KVM guests easier and has handy features like the ability to copy in ssh keys so you can connect to the guest right away.
There's plenty of images for different distributions, automatic file sharing between host and guest, etc.
I am trying vanilla qemu with cloud-init. Images: https://images.linuxcontainers.org/images/
It was a forklift, to be sure, but the machines're snappier, & you buy yourself a little headroom.