[libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Avi Kivity
avi at redhat.com
Wed Mar 24 05:17:26 UTC 2010
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
qemu
- with -qemud option, connects to qemud (or maybe automatically?)
qemudc
- command-line client, can access qemu human monitor
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
More information about the libvir-list
mailing list