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

[Anthony Liguori]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/