6 ms·

I think there is too much cruft in Qemu and a simple install can pull in hundreds of dependencies. For instance if you just want to run x86_64 VMs there is no p

by throw2016 9y ago

I think there is too much cruft in Qemu and a simple install can pull in hundreds of dependencies. For instance if you just want to run x86_64 VMs there is no point getting 20 different platforms. For the standard run of the mill VM there is also rarely any need for the multitude of devices. The more stuff you put in the more surface area for exploits. The Qemu install candidate needs to be seriously redesigned and pruned down by package maintainers. Intel Clear Linux tried running VMs without qemu altogether with Kvmtool but are now using 'Qemu lite'. But there are no packages, instructions or even a readme on what exactly they have done to make 'Qemu lite'. Kvmtool is one of those packages with zero documentation. Libvirt is needlessly convoluted and its usage complexity has led to an inferior solution like Virtualbox gaining traction on Linux, inspite of kvm in the kernel. For those looking for a simpler way to use kvm I suggest trying something like Aqemu or even just resorting to the command line. I found it far more lightweight and reasonable than libvirt's heavy handed way of running a simple qemu-kvm command line and adding an XML mess to it.

bonzini 9y ago
QEMU-lite is just a set of patches on top of QEMU, which are in the process of being merged.
kashyapc 9y ago
Please don't make suggestions like "libvirt is too convoluted, just resort to [QEMU] command-line" -- FWIW, I'm saying this as an every day QEMU command-line user -- without having the complete picture. Yes, there are some valid scenarios where people who know what they're doing can (and they do) directly use the QEMU command-line. But for the most majority, libvirt makes life far simpler, because of the following. Daniel Berrangé (lead maintainer of libvirt) articulates it much more succintly than I could, allow me to quote him: "It is a common attitude among people who look at QEMU and see a deceptively simple command-line syntax for launching a VM and don't realize that you'll enter a world of hurt when you go beyond the initial simple command-line syntax. This[1] was written in 2011, but is pretty valid and probably more besides: https://www.berrange.com/posts/2011/06/07/what-benefits-does-libvirt-offer-to-developers-targetting-qemukvm/ Recently, we had a very nice example of benefit of libvirt to security when the VENOM bug came out. Anyone using libvirt automatically had anti-VENOM available thanks to SELinux/AppArmour which would prevent exploitation in most cases." More on it (from his very detailed response on this thread[+], specifically from the 4th paragraph on): "Also note that this kind of bug [VENOM] in QEMU device emulation is the poster child example for the benefit of having sVirt (either SELinux or AppArmor backends) enabled on your compute hosts.. With sVirt, QEMU is restricted to only access resources that have been explicitly assigned to it. This makes it very difficult (likely/hopefully impossible[1]) for a compromised QEMU to be used to break out to compromise the host as a whole, likewise protect against compromising other QEMU processes on the same host. The common Linux distros like RHEL, Fedora, Debian, Ubuntu, etc all have sVirt feature available and enabled by default and OpenStack doesn't do anything to prevent it from working. Hopefully no one is actively disabling it themselves leaving themselves open to attack... [1] I'll never claim anything is 100% foolproof, but it is intended to be impossible to escape sVirt, so any such viable escape routes would themselves be considered security bugs. " [+] http://lists.openstack.org/pipermail/openstack-operators/2015-May/006947.html http://lists.openstack.org/pipermail/openstack-operators/201...
- throw2016 9y ago
  I think you are presuming here about the 'complete picture'. The point is not to encourage anyone. I am sure people can make their own decisions. We need to highlight the issues with libvirt that leaves a great technology like kvm unused. Security can be used to close down any discussion but the result is many people are using virtualbox and not libvirt. Seccomp, selinux or Apparmor can be used without libvirt as required so I don't see this as a security issue. On the contrary the needlessly complex XML config files likely put many users off from using it properly or using it as all.
  - kashyapc 9y ago
    You are simply overstating the issue. Was not closing the discussion down with security -- that line of thought didn't even occur to me. The `virtual-box` equivalent in the KVM stack is `virt-manager` (under the hood, it uses libvirt APIs) -- these are primarily for desktop Virtualization, not for server Virtualisation. To manage a fleet of servers in a data center, people don't fire up a desktop application. Can some aspects of the experience with `virt-manager` / libvirt stack be improved? Certainly yes. But saying things like it "leaves a great technology like kvm unused" is ridiculous hyperbole. A clarification about why it is partly a "security issue": The sVirt guest confinement mechanism in libvirt builds on top of basic SELinux / AppArmour confinement. As in, with sVirt: each VM (the QEMU proces that is managed by libvirt) and its associated disk gets a unique SELinux label -- this means, even if a guest (in a fleet of 1000 VMs) is compromised, it is contained to just that specific guest.
    - throw2016 9y ago
      I think you are conflating issues here. Obviously virtualbox users do not need data center level security and should not have to deal with that complexity, and naturally choose not to, and use virtualbox. You have turned a simple observation about the complexity of libvirt's configuration and the resulting traction of virtualbox on Linux into a discussion on data centers, 1000's of VMs, and security. This seem to be talking around the issue so this discussion is moot. Are you saying selinux, apparmor and seccomp cannot be used on qemu processes without libvirt?

bonzini 9y ago

QEMU-lite is just a set of patches on top of QEMU, which are in the process of being merged.

kashyapc 9y ago

Please don't make suggestions like "libvirt is too convoluted, just resort to [QEMU] command-line" -- FWIW, I'm saying this as an every day QEMU command-line user -- without having the complete picture. Yes, there are some valid scenarios where people who know what they're doing can (and they do) directly use the QEMU command-line. But for the most majority, libvirt makes life far simpler, because of the following. Daniel Berrangé (lead maintainer of libvirt) articulates it much more succintly than I could, allow me to quote him: "It is a common attitude among people who look at QEMU and see a deceptively simple command-line syntax for launching a VM and don't realize that you'll enter a world of hurt when you go beyond the initial simple command-line syntax. This[1] was written in 2011, but is pretty valid and probably more besides: https://www.berrange.com/posts/2011/06/07/what-benefits-does-libvirt-offer-to-developers-targetting-qemukvm/ Recently, we had a very nice example of benefit of libvirt to security when the VENOM bug came out. Anyone using libvirt automatically had anti-VENOM available thanks to SELinux/AppArmour which would prevent exploitation in most cases." More on it (from his very detailed response on this thread[+], specifically from the 4th paragraph on): "Also note that this kind of bug [VENOM] in QEMU device emulation is the poster child example for the benefit of having sVirt (either SELinux or AppArmor backends) enabled on your compute hosts.. With sVirt, QEMU is restricted to only access resources that have been explicitly assigned to it. This makes it very difficult (likely/hopefully impossible[1]) for a compromised QEMU to be used to break out to compromise the host as a whole, likewise protect against compromising other QEMU processes on the same host. The common Linux distros like RHEL, Fedora, Debian, Ubuntu, etc all have sVirt feature available and enabled by default and OpenStack doesn't do anything to prevent it from working. Hopefully no one is actively disabling it themselves leaving themselves open to attack... [1] I'll never claim anything is 100% foolproof, but it is intended to be impossible to escape sVirt, so any such viable escape routes would themselves be considered security bugs. " [+] http://lists.openstack.org/pipermail/openstack-operators/2015-May/006947.html http://lists.openstack.org/pipermail/openstack-operators/201...

throw2016 9y ago
I think you are presuming here about the 'complete picture'. The point is not to encourage anyone. I am sure people can make their own decisions. We need to highlight the issues with libvirt that leaves a great technology like kvm unused. Security can be used to close down any discussion but the result is many people are using virtualbox and not libvirt. Seccomp, selinux or Apparmor can be used without libvirt as required so I don't see this as a security issue. On the contrary the needlessly complex XML config files likely put many users off from using it properly or using it as all.
- kashyapc 9y ago
  You are simply overstating the issue. Was not closing the discussion down with security -- that line of thought didn't even occur to me. The `virtual-box` equivalent in the KVM stack is `virt-manager` (under the hood, it uses libvirt APIs) -- these are primarily for desktop Virtualization, not for server Virtualisation. To manage a fleet of servers in a data center, people don't fire up a desktop application. Can some aspects of the experience with `virt-manager` / libvirt stack be improved? Certainly yes. But saying things like it "leaves a great technology like kvm unused" is ridiculous hyperbole. A clarification about why it is partly a "security issue": The sVirt guest confinement mechanism in libvirt builds on top of basic SELinux / AppArmour confinement. As in, with sVirt: each VM (the QEMU proces that is managed by libvirt) and its associated disk gets a unique SELinux label -- this means, even if a guest (in a fleet of 1000 VMs) is compromised, it is contained to just that specific guest.
  - throw2016 9y ago
    I think you are conflating issues here. Obviously virtualbox users do not need data center level security and should not have to deal with that complexity, and naturally choose not to, and use virtualbox. You have turned a simple observation about the complexity of libvirt's configuration and the resulting traction of virtualbox on Linux into a discussion on data centers, 1000's of VMs, and security. This seem to be talking around the issue so this discussion is moot. Are you saying selinux, apparmor and seccomp cannot be used on qemu processes without libvirt?