Re: [libvirt] [Qemu-devel] Re: Libvirt debug API

> Today, you have to make changes to libvirt whereas in a direct launch > model, you get all of the neat security features linux supports for > free. But you lose tap networking, unless you have a privileged helper. And how is the privileged helper to authenticate the qemu calling it?

>>> And I've said in the past that I don't like the idea of a qemud :-) >> >> I must have missed it. Why not? Every other hypervisor has a >> central management entity. > > Because you end up launching all guests from a single security context. Run multiple qemuds? But what you say makes sense. It's similar to the fork() /* do interesting stuff */ exec() model, compared to the spawn(..., hardcoded list of interesting stuff). >>> Yeah, that's where I'm at. I'd eventually like libvirt to use our >>> provided API and I can see where it would add value to the stack >>> (by doing things like storage and network management). >> >> We do provide an API, qmp, and libvirt uses it? > > Yeah, but we need to support more features (like guest enumeration). What are our options? 1) qemud launches, enumerates 2) user launches, qemu registers in qemud 3) user launches, qemu registers in filesystem 4) you launched it, you enumerate it

> (3) The system management application can certainly create whatever > context it wants to launch a vm from. It's comes down to who's > responsible for creating the context the guest runs under. I think > doing that at the libvirt level takes away a ton of flexibility from > the management application. If you want to push the flexibility slider all the way to the right you get bare qemu. It exposes 100% of qemu capabilities. And it's not so bad these days. But it's not something that can be remoted.