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

[Stefan de Konink]

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.


> 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.


> One such application is oVirt which talks to multiple libvirtd enabled 
> hosts and provides an aggegrate view. There are other people working on
> similar types of application.

The problem of this external solution is that again a wrapper is 
required or a reimplementation of an API. The developer doesn't care if 
it connects to one management server or connects to some local node, he 
cares about the fact that it is API transparent.

If I have Python/C/Ruby written for one host, and want to circumvent the 
problem, I would write my own methods to lookup where a VM is running. I 
think these capabilities OR belong to the api, which is unaware because 
it is not an active process, so it would need to browse first OR it 
should be part of libvirtd, so any libvirtd on the network can manage 
any libvirtd.



Stefan