Messages in this thread | | | Date | Tue, 23 Mar 2010 09:09:14 -0500 | From | Anthony Liguori <> | Subject | Re: [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
| |