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

[Daniel P. Berrange]

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

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.

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|