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

[Anthony Liguori]

On 04/26/2010 08:41 AM, Avi Kivity wrote:
> > 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?

There are a variety of ways.  My original proposal used a policy file.

> > > > 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

Both 2 and 3 are appealing to me.

> > (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.

As I mentioned earlier, remoting is not a very important use-case to me.

Does RHEV-M actually use the remote libvirt interface?  I assume it'll 
talk to vdsm via some protocol and vdsm will use the local libvirt API.  
I suspect most uses of libvirt are actually local uses.

Regards,

Anthony Liguori