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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/24/2010 12:17 AM, 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

Then guests run with the wrong security context.

Regards,

Anthony Liguori

> qemu
>   - with -qemud option, connects to qemud (or maybe automatically?)
>
> qemudc
>   - command-line client, can access qemu human monitor
>