On 03/23/2010 01:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest
enumeration. So the fundamental topic here is, do we introduce these
missing components to allow people to build directly to our interface
or do we make use of the functionality that libvirt already provides
if they can plumb our API directly to users.
Guest enumeration is another API.
Over the kvm call I suggested a qemu concentrator that would keep
track of all running qemus, and would hand out monitor connections to
users. It can do the enumeration (likely using qmp). Libvirt could
talk to that, like it does with other hypervisors.
If you think about network management, it's the difference between
having a central management server that you add physical machines to,
verses having physical machines use an advertisement mechanism (like
mDNS or SLP). The later mechanism scales better and tends to be more
robust.
For instance, it's very common for VNC servers to advertise themselves
via mDNS and it's also common for VNC clients to support this. It
requires no central server to keep track of VNC instances and generally
provides much better usability.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list