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)
