Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt

[Avi Kivity]

On 03/24/2010 12:36 PM, Daniel P. Berrange wrote:
> On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
>    
> > On 03/23/2010 08:00 PM, Avi Kivity wrote:
> >      
> > > On 03/23/2010 06:06 PM, Anthony Liguori wrote:
> > >        
> > > > > I thought the monitor protocol *was* our API. If not, why not?
> > > > >            
> > > > It is.  But our API is missing key components like guest
> > > > enumeration.  So the fundamental topic here is, do we introduce these
> > > > missing components to allow people to build directly to our interface
> > > > or do we make use of the functionality that libvirt already provides
> > > > if they can plumb our API directly to users.
> > > >
> > > >          
> > > Guest enumeration is another API.
> > >
> > > Over the kvm call I suggested a qemu concentrator that would keep
> > > track of all running qemus, and would hand out monitor connections to
> > > users.  It can do the enumeration (likely using qmp).  Libvirt could
> > > talk to that, like it does with other hypervisors.
> > >
> > >        
> > To elaborate
> >
> > qemud
> >    - daemonaizes itself
> >    - listens on /var/lib/qemud/guests for incoming guest connections
> >    - listens on /var/lib/qemud/clients for incoming client connections
> >    - filters access according to uid (SCM_CREDENTIALS)
> >    - can pass a new monitor to client (SCM_RIGHTS)
> >    - supports 'list' command to query running guests
> >    - async messages on guest startup/exit
> >      
> My concern is that once you provide this, then next someone wants it to
> list inactive guests too.

That's impossible, since qemud doesn't manage config files or disk 
images.  It can't even launch guests!

> Once you list inactive guests, then you'll
> want this to start a guest. Once you start guests then you want cgroups
> integration, selinux labelling&  so on, until it ends up replicating all
> of libvirt's QEMU functionality.
>
> To be able to use the list functionality from libvirt, we need this daemon
> to also guarentee id, name&  uuid uniqueness for all VMs, both running and
> inactive, with separate namespaces for the system vs per-user lists. Or
> we have to ignore any instances listed by qemud that were not started  by
> libvirt, which rather defeats the purpose.
>    

qemud won't guarantee name uniqueness or provide uuids.

> The filtering access part of this daemon is also not mapping well onto
> libvirt's access model, because we don't soley filter based on UID in
> libvirtd. We have it configurable based on UID, policykit, SASL, TLS/x509
> already, and intend adding role based access control to further filter
> things, integrating with the existing apparmour/selinux security models.
> A qemud that filters based on UID only, gives users a side-channel to get
> around libvirt's access control.
>    

That's true.  Any time you write a multiplexer these issues crop up.  
Much better to stay in single process land where everything is already 
taken care of.

So, at best qemud is a toy for people who are annoyed by libvirt.

--
error compiling committee.c: too many arguments to function