[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] libvirt and accessing remote systems



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)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]