lkml.org 
[lkml]   [2010]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project
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



\
 
 \ /
  Last update: 2010-03-23 15:11    [W:0.186 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site