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.
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?
And you seem to be comparing Virtual Box with libvirt, which is equivalent to comparing apples to aardvarks (okay, that's an exaggeration). But seriously, a fairer comparison would be Virtual Box vs. Virt-Manager on Linux.
Here, I admit -- I'm not a daily Virt-Manager user (I live on the command-line), so I can't tell you where exactly it is lacking compared to Virtual Box.
If you've tried it, & have suggestions​, you might want to write to:
https://www.redhat.com/mailman/listinfo/virt-tools-list
---
About the libvirt's internal representation (in XML -- yes, I'm not a big fan of it either, and I suspect, nor are the current maintainers; had it been today, they would've likely chosen a more gentler-on-the-eye format like JSON or some such) of guest definition: Most users don't need to touch the XML definition at all. Most tasks that are involved in managing VMs can all be done trivially via Virt-Manager GUI, or the command-line, virsh.
And the regular libvirt configuration files are all in standard Linux configuration file format.
> Are you saying selinux, apparmor and seccomp cannot be used on qemu processes without libvirt?
No, I'm not saying that. My argument (based on daily interactions with users on public IRC & mailing lists) is that, for QEMU-based guests, libvirt makes it easier.
You have taken this discussion to unrelated security and data center issues that have got nothing to do with the topic on hand. You dwell on the security of seccomp, selinux and apparmor that have nothing to do with libvirt specifically.
I am not interested in discussing libvirt, virsh or virt-manager and its various offshoots. And given libvirt is the what virsh and virt-manager use in the context it's disingenuous pedantry to make a distinction.
I am interested in understanding how kvm can be made more accessible to virtualbox users. If that's not something that concerns you and you would rather dwell on defending libvirt then that's not a productive discussion. If libvirt was the solution we would not be having this discussion to start with.
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.