[libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Avi Kivity
avi at redhat.com
Wed Mar 24 10:42:16 UTC 2010
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
More information about the libvir-list
mailing list