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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
