[libvirt] remote access libvirtd / bindings for php/asp
Hi, A few people around me want to use php or asp to access libvirtd. Along this wish is to access it as 'proxy' for the entire cluster (this is where I come in). My target it to make a proxy for libvirtd that allows all host in the network to be managed by any libvirtd instance that has the sufficient certificate. Now it seems clear that this dispatch/proxy functions are doable. But what I wonder about is the actual access to libvirtd. There seems to be a pretty big warning about the XDR/ RPC calls. My people would like to see bindings to connect to libvirtd by php or asp/.net, is there any progress on that one? Stefan
On Tue, Jun 03, 2008 at 05:27:45PM +0200, Stefan de Konink wrote:
My people would like to see bindings to connect to libvirtd by php or asp/.net, is there any progress on that one?
Not a lot of progress ... I looked at PHP bindings, as that is a big pain point for people who want to use libvirt in web hosting environments. I don't have a lot of time to write such bindings myself, particularly not before the Red Hat Summit. However we would support anyone who wanted to start such a project. Even binding just the common connection and domain calls (perhaps 10-15 in all) would be a great start. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
Richard W.M. Jones schreef:
On Tue, Jun 03, 2008 at 05:27:45PM +0200, Stefan de Konink wrote:
My people would like to see bindings to connect to libvirtd by php or asp/.net, is there any progress on that one?
Not a lot of progress ... I looked at PHP bindings, as that is a big pain point for people who want to use libvirt in web hosting environments. I don't have a lot of time to write such bindings myself, particularly not before the Red Hat Summit. However we would support anyone who wanted to start such a project. Even binding just the common connection and domain calls (perhaps 10-15 in all) would be a great start.
I think I can get motivated or get someone that is motivated or even motivate someone to write these bindings for PHP. I'll discuss the implications on friday. The problem is probably not the writing of the binding, but more getting it distributed as a stable extension. But my personal interest goes out to libvirtd overlord capabilities. By extending the API with the capability of transparently connecting to an other machine announced by avahi or added by an xml file. Or just exending libvirtd with proxy functionality. I would like to hear the Red Hat ideas on this one. So going for an 'architecture' like storage that is able to register/discover neighbor nodes. Or just sticking with an 'external' program that is able to do this task. Stefan
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. It has one job - provide remote access to the libvirt APIs for a single node. 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. 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. 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. 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 :|
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
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. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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 :|
In case Stephan isn't aware, we have node discovery working already. libvirtd instances broadcast their availability over Avahi. To be practically useful they need to broadcast a little bit more information via some TXT fields, but adding a patch to do that is surely easier than turning libvirt into a cluster management system. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones -
Stefan de Konink