[libvirt] remote access libvirtd / bindings for php/asp

Daniel Veillard veillard at redhat.com
Wed Jun 4 08:04:01 UTC 2008

On Wed, Jun 04, 2008 at 02:01:21AM +0200, Stefan de Konink wrote:
> Daniel P. Berrange schreef:
> >On Wed, Jun 04, 2008 at 01:36:17AM +0200, Stefan de Konink wrote:
> >>Or just exending libvirtd with proxy functionality. I would like to hear 
> >>the Red Hat ideas on this one.
> >
> >This kind of functionality doesn't really belong in libvirtd. It is not
> >intended to be a centralized management daemon for multiple nodes.
> I disagree on this point. It can make the entire process a distributed 
> effort. Operating as a single cluster, essentially the thing that lacks 
> in XenD/KVM/etc. Without any single point of failure, connecting to any 
> cluster node will do for management.

  Hum, no really we disagree on this. libvirtd is just here because 
it's the only way to implement the API in a correct and secure way
and garantee transparent remote access.
  The kind of APIs that have been designed in libvirt are based on
the assumption you talk to one Node (please go back to the introduction
on the architecture http://libvirt.org/intro.html ), there is no notion
of cluster. You don't list domains or peripherals on a cluster with
the same kind of APIs as you can do on a node. The latter allows direct
immediate answers part of synchronous single call. For a cluster you need
asynchronous queries, filtering built into the API or it becomes useless.

  Trying to turn libvirt into a cluster management API is something
which doesn't make sense. The goal is to provide an API which allows
to build those tools relatively easilly on top, or simpler tools for
smaller solutions.

  Turning libvirtd into a cluster management daemon just doesn't make
sense to me based on the previous point and the fact that the daemon
has been designed to be a libvirt API server not a client querying 
other nodes, this would need threading, caching, local state, 
change in security, plus a change of the kind of API being served.

  Really what you're looking for is a different development, better
done on top of libvirt but not in libvirt.


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

More information about the libvir-list mailing list