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

[Avi Kivity <avi@redhat.com>]

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