Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/23/2010 04:07 AM, Avi Kivity wrote:
> On 03/23/2010 12:06 AM, Anthony Liguori wrote:
>>> Having qemu enumerate guests one way or another is not a good idea 
>>> IMO since it is focused on one guest and doesn't have a system-wide 
>>> entity.
>>
>>
>> There always needs to be a system wide entity.  There are two ways to 
>> enumerate instances from that system wide entity.  You can centralize 
>> the creation of instances and there by maintain an list of current 
>> instances.  You can also allow instances to be created in a 
>> decentralized manner and provide a standard mechanism for instances 
>> to register themselves with the system wide entity.
>>
>> IOW, it's the difference between asking libvirtd to exec(qemu) vs 
>> allowing a user to exec(qemu) and having qemu connect to a well known 
>> unix domain socket for libvirt to tell libvirtd that it exists.
>>
>> The later approach has a number of advantages.  libvirt already 
>> supports both models.  The former is the '/system' uri and the later 
>> is the '/session' uri.
>>
>> What I'm proposing, is to use the host file system as the system wide 
>> entity instead of libvirtd.  libvirtd can monitor the host file 
>> system to participate in these activities but ultimately, moving this 
>> functionality out of libvirtd means that it becomes the standard 
>> mechanism for all qemu instances regardless of how they're launched.
>
> I don't like dropping sockets into the host filesystem, especially as 
> they won't be cleaned up on abnormal exit.  I also think this breaks 
> our 'mechanism, not policy' policy.  Someone may want to do something 
> weird with qemu that doesn't work well with this.

The approach I've taken (which I accidentally committed and reverted) 
was to set this up as the default qmp device much like we have a default 
monitor device.  A user is capable of overriding this by manually 
specifying a qmp device or by disabling defaults.

> We could allow starting monitors from the global configuration file, 
> so a distribution can do this if it wants, but I don't think we should 
> do this ourselves by default.

I've looked at making default devices globally configurable.  We'll get 
there but I think that's orthogonal to setting up a useful default qmp 
device.

Regards,

Anthony Liguori