4 ms·

> like running the QEMU process as an unprivileged user, Anyone can run your example "qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -dev

by antocv 7y ago

> like running the QEMU process as an unprivileged user, Anyone can run your example "qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,format=qcow2,if=virtio" from the command line/bash, as non-root user, yet libvirt which requires root to install, and is expecting root to configure it, is better? How? Libvirt is one of those softwares which ads a layer of complexity for the sake of complexity, yet offers nothing of value in return.

ori_b 7y ago
Indeed. Instead of contributing a patch to qemu with better defaults, or even support for config files, someone wrote tens of thousands of lines of complex code. People forget that software is malleable. Bend it to your needs, instead of adding fragile wrapper layers.
- LukeShu 7y ago
  libvirt-the-software is tens of thousands of lines of complex code that doesn't really add much. libvirt-the-project does contribute patches in to qemu, and a lot of the reason that libvirt-the-software doesn't add much of value is because libvirt-the-project worked to get capabilities in to upstream qemu. The libvirt team definitely does view qemu as malleable, and bends it to their needs. The problem is that the libvirt authors contributing to qemu look at qemu as a machine-interface (to be consumed by libvirt), not as a human-interface. Many of the more poorly documented or otherwise difficult-for-humans flags were contributed by the libvirt team. And they're useful! They make it so qemu can do things it couldn't do before. But they're also kinda the reason qemu is difficult to use without libvirt.
  - JoshuaRLi 7y ago
    Good observations! I can't say I like it when a wrapper (loosely said here) starts to exert too much influence over what it wraps.
throwaway2048 7y ago
its not true that libvirt adds nothing of value, it adds easy networking support, easy snapshots, a nice gui interface, a very nice remote protocol and clients (that seamlessly support both graphical and serial output, aswell as on the fly reconfiguration of VMs without restarting them), template VMs (including one time initial provision setup), easy support for storage pools including remote ones, an easy way to manipulate RAM usage on live VMs, easy PCI and USB passthrough, live migration to other hosts, etc etc. Sure its possible to do all this without libvirt, but it comes as one integrated, easy to manage package instead of hundreds of disparate parts. You might not need (all) these features, but to claim libvirt is useless is extremely parochial. Its also untrue that it needs root, you can virt-manager for instance without a root libvirtd instance at all, and it will run VMs without any permissions needed.
- antocv 7y ago
  > its not true that libvirt adds nothing of value, it adds easy networking support, easy snapshots, a nice gui interface, a very nice remote protocol and clients (that seamlessly support both graphical and serial output, aswell as on the fly reconfiguration of VMs without restarting them), template VMs (including one time initial provision setup), easy support for storage pools including remote ones, an easy way to manipulate RAM usage on live VMs, easy PCI and USB passthrough, live migration to other hosts, etc etc. everything libvirt does can be done without it by talking to qemu directly. and yes, Ive done many of the above "by hand", it was easier to read man qemu and other qemu docs than to swallow libvirt.
  - throwaway2048 7y ago
    No, not everything it does can be done by qemu directly, plenty of it lies outside of the scope of QEMU entirely, like managing networks (not just network devices), or storage pools, setting up permissions for device redirection, or doing the legwork for VM provisioning and configuration (including net booting and automatically running appropriate scripts), or managing access to VMs both locally and remotely. Its fine if your use cases are covered by plain QEMU, but libvirt does a hell of a lot more than plain QEMU alone is capable of. Again all of that is possible via other means, but when other means involve recreating half of libvirt in shell scripts or other code, id rather let somebody else do the work for me. QEMU is designed to run virtual machines, libvirtd is designed to manage VM server infrastructure.
kbenson 7y ago
> Libvirt is one of those softwares which ads a layer of complexity for the sake of complexity, yet offers nothing of value in return. Isn't that sort of like saying the system startup scripts/subsystem adds complexity for the sake of complexity, and you should just use ifconfig and route manually in some script after startup? In both cases, that you can fall back to the underlying commands is great. That you should use them instead of the normalized interface provided is debatable.
jolmg 7y ago
Unless the default changed one of these last few years, I'm pretty sure if you don't use `-enable-kvm` then qemu emulates the selected architecture. That's probably why it doesn't need root. EDIT: Nevermind, `-enable-kvm` also doesn't need root. I'm not sure what libvirt uses root for.
uname_a 7y ago
Hear, hear. QEMU is excellent software, and I don't find that libvirt adds any value to its use. Instead, one of the more annoying things I have ever done was foolishly installing libvirt and having it do all kinds of whackiness to a previously excellent QEMU set-up. I still cannot figure out where it managed to change all QEMU invocations to be VNC-based.

by antocv 7y ago

ori_b 7y ago

Indeed. Instead of contributing a patch to qemu with better defaults, or even support for config files, someone wrote tens of thousands of lines of complex code. People forget that software is malleable. Bend it to your needs, instead of adding fragile wrapper layers.

LukeShu 7y ago
libvirt-the-software is tens of thousands of lines of complex code that doesn't really add much. libvirt-the-project does contribute patches in to qemu, and a lot of the reason that libvirt-the-software doesn't add much of value is because libvirt-the-project worked to get capabilities in to upstream qemu. The libvirt team definitely does view qemu as malleable, and bends it to their needs. The problem is that the libvirt authors contributing to qemu look at qemu as a machine-interface (to be consumed by libvirt), not as a human-interface. Many of the more poorly documented or otherwise difficult-for-humans flags were contributed by the libvirt team. And they're useful! They make it so qemu can do things it couldn't do before. But they're also kinda the reason qemu is difficult to use without libvirt.
- JoshuaRLi 7y ago
  Good observations! I can't say I like it when a wrapper (loosely said here) starts to exert too much influence over what it wraps.

throwaway2048 7y ago

its not true that libvirt adds nothing of value, it adds easy networking support, easy snapshots, a nice gui interface, a very nice remote protocol and clients (that seamlessly support both graphical and serial output, aswell as on the fly reconfiguration of VMs without restarting them), template VMs (including one time initial provision setup), easy support for storage pools including remote ones, an easy way to manipulate RAM usage on live VMs, easy PCI and USB passthrough, live migration to other hosts, etc etc. Sure its possible to do all this without libvirt, but it comes as one integrated, easy to manage package instead of hundreds of disparate parts. You might not need (all) these features, but to claim libvirt is useless is extremely parochial. Its also untrue that it needs root, you can virt-manager for instance without a root libvirtd instance at all, and it will run VMs without any permissions needed.

antocv 7y ago
> its not true that libvirt adds nothing of value, it adds easy networking support, easy snapshots, a nice gui interface, a very nice remote protocol and clients (that seamlessly support both graphical and serial output, aswell as on the fly reconfiguration of VMs without restarting them), template VMs (including one time initial provision setup), easy support for storage pools including remote ones, an easy way to manipulate RAM usage on live VMs, easy PCI and USB passthrough, live migration to other hosts, etc etc. everything libvirt does can be done without it by talking to qemu directly. and yes, Ive done many of the above "by hand", it was easier to read man qemu and other qemu docs than to swallow libvirt.
- throwaway2048 7y ago
  No, not everything it does can be done by qemu directly, plenty of it lies outside of the scope of QEMU entirely, like managing networks (not just network devices), or storage pools, setting up permissions for device redirection, or doing the legwork for VM provisioning and configuration (including net booting and automatically running appropriate scripts), or managing access to VMs both locally and remotely. Its fine if your use cases are covered by plain QEMU, but libvirt does a hell of a lot more than plain QEMU alone is capable of. Again all of that is possible via other means, but when other means involve recreating half of libvirt in shell scripts or other code, id rather let somebody else do the work for me. QEMU is designed to run virtual machines, libvirtd is designed to manage VM server infrastructure.

kbenson 7y ago

> Libvirt is one of those softwares which ads a layer of complexity for the sake of complexity, yet offers nothing of value in return. Isn't that sort of like saying the system startup scripts/subsystem adds complexity for the sake of complexity, and you should just use ifconfig and route manually in some script after startup? In both cases, that you can fall back to the underlying commands is great. That you should use them instead of the normalized interface provided is debatable.

jolmg 7y ago

Unless the default changed one of these last few years, I'm pretty sure if you don't use `-enable-kvm` then qemu emulates the selected architecture. That's probably why it doesn't need root. EDIT: Nevermind, `-enable-kvm` also doesn't need root. I'm not sure what libvirt uses root for.

uname_a 7y ago

Hear, hear. QEMU is excellent software, and I don't find that libvirt adds any value to its use. Instead, one of the more annoying things I have ever done was foolishly installing libvirt and having it do all kinds of whackiness to a previously excellent QEMU set-up. I still cannot figure out where it managed to change all QEMU invocations to be VNC-based.