10:27 a.m.
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
6:14 p.m.
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/
6:36 p.m.
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
6:43 p.m.
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 :|
7:01 p.m.
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
3:04 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:23 a.m.
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 :|
3:22 a.m.
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
6014
days inactive
6015
days old
8 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones -
Stefan de Konink