This is a follow on to this thread:
https://www.redhat.com/archives/libvir-list/2007-January/thread.html#00064
but I think it deserves a thread of its own for discussion.
Background:
Dan drew this diagram proposing a way to include remote access to
systems from within libvirt:
http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-2.png
libvirt would continue as now to provide direct hypervisor calls,
direct access to xend and so on. But in addition, a new backend
would be written ("remote") which could talk to a remote daemon
("libvirtd") using some sort of RPC mechanism.
Position:
I gave this architecture some thought over the weekend, and I
like it for the following reasons (some not very technical):
* Authentication and encryption is handled entirely within the
libvirt / libvirtd library, allowing us to use whatever RPC
mechanism we like on top of a selection of transports of our
choosing (eg. GnuTLS, ssh, unencrypted TCP sockets, ...)
* We don't need to modify xend at all, and additionally we won't
need to modify future flavour-of-the-month virtual machine monitors.
I have a particular issue with xend (written in Python) because
in my own tests I've seen my Python XMLRPC/SSL server
actually segfault. It doesn't inspire me that this Python
solution is adding anything more than apparent security.
* The architecture is very flexible: It allows virt-manager to
run as root or as non-root, according to customer wishes.
virt-manager can make direct HV calls, or everything can be
remoted, and it's easy to explain to the user about the
performance vs management trade-offs.
* It's relatively easy to implement. Note that libvirtd is just
a thin server layer linked to its own copy of libvirt.
* Another proposal was to make all libvirt calls remote
(http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-3.png)
but I don't think this is a going concern because (1) it requires
a daemon always be run, which is another installation problem and
another chance for sysadmins to give up, and (2) the perception will
be that this is slow, whether or not that is actually true.
Now some concerns:
* libvirtd will likely need to be run as root, so another root
daemon written in C listening on a public port. (On the other
hand, xend listening on a public port also isn't too desirable,
even with authentication).
* If Xen upstream in the meantime come up with a secure remote access
method then potentially this means clients could have to choose
between the two, or run two services (libvirtd + Xen/remote).
* There are issues with versioning the remote API. Do we allow
different versions of libvirt/libvirtd to talk to each other?
Do we provide backwards compatibility when we move to a new API?
* Do we allow more than one client to talk to a libvirtd daemon
(no | multiple readers one writer | multiple readers & writers).
* What's the right level to make a remote API? Should we batch
calls up together?
RPC mechanism:
I've been investigating RPC mechanisms and there seem to be two
reasonable possibilities, SunRPC and XMLRPC. (Both would need to
run over some sort of secure connection, so there is a layer below
both). My analysis of those is here:
http://et.redhat.com/~rjones/secure_rpc/
Rich.
--
Red Hat UK Ltd.
64 Baker Street, London, W1U 7DF
Mobile: +44 7866 314 421 (will change soon)