Re: [libvirt] remote access libvirtd / bindings for php/asp
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.
I will say again, this does not belong in libvirtd. Libvirt is a stateless
daemon whose only job is exposing libvirt APIs from a local node. That is
all. It is not a cluster management server. What you are suggesting would
require every libvirtd instance to talk to every other libvirtd instance.
Applications can already talk directly to any libvirtd instance they are
authorized for without this proxy, which is more efficient and is already
without a single pointof failure.
>If you want management of a whole cluster/network of machines
then you
>want to have a separate management server talking to the libvirtd on
>each node and providing an aggregate view of some kind.
This would mean an extra layer of complexity and again stopping people
from use of the libvirt api in their applications, because this would
imply that they browse their cluster theirselves, instead of looking at
the cluster as one big machine, or implementing yet another new server
talking its own protocol. Since libvirt already wraps xend for this
problem... I don't want to have yet another daemon for the same thing:
connectivity by a *good* api.
>libvirt isn't
>intended to be a complete management application in its own right - it
>is just providing the base infrastructure on which you can build
>applications.
To make the application cluster aware is not something that is bad, for
any application that uses it.
Nothing prohibits existing applications from talking directly to every
node in the cluster - there's no need to route all nodes via a single
libvirtd. This basically comes down to two things - node discovery and
the wire transport. There are many ways to do both of these, and the
applications using libvirt have varying requirements in this area, so
a one size fits all approach will not satisfy them all. As such we do
not want to build one particular solution into libvirtd. We provide
the base level infrastructure on which more complex cluster-aware
solutions can be built. In this way layers of increasing complexity can
be stacked up as required.
Dan.
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|