[Libguestfs] Connecting to existing guests / guestfsd

[Continuing the discussion from: http://lists.gnu.org/archive/html/qemu-devel/2011-01/msg02600.html Sent to libguestfs mailing list] What we are looking at is something like this: guestfish --rw -i LiveGuest [connected read-write to a live guest] This is not possible at the moment: it's causes disk corruption to write to disks attached to a live guest, and in the above case guestfish wouldn't let you do it anyway. How this would work: (1) '-i' option causes inspection code to look in the libvirt XML for a virtio-serial channel with a particular name: <channel type='pty'> <source path='/path/to/unix/socket'/> <target type='virtio' name='org.libguestfs.daemon'/> </channel> (2) guestfish issues the libguestfs guestfs_set_attach_method call to attach to the Unix domain socket: guestfs_set_attach_method (g, "unix:/path/to/unix/socket"); This is also how other programs work if they aren't using libvirt or want to attach to arbitrary guestfsd. (3) guestfs_launch attaches to the Unix domain socket (instead of launching the ordinary appliance). (4) All other guestfs_* commands and tools work as normal. The issues as I see it are: (a) Only one client could be attached to a guest at once (this is both a restriction of virtio-serial and of guestfsd itself). Do we need locking to enforce this? Can/should we lift this restriction? (I think not for initial version, consider lifting it later) (b) This would limit changes we can make to the protocol. At the moment we are fairly free about changing the protocol in ways which are not backwards-compatible. If the daemon is embedded in guests then we couldn't change the protocol freely (at least not without requiring everyone to upgrade). (c) Need to change how the NEED_ROOT macro works so it consults /proc/self/mountinfo instead of using a global flag. This is a sensible change to make anyway since having the global flag has caused us a series of other problems. [See also libguestfs.org/TODO.txt] (d) Need to port the daemon to Windows properly. (e) What other attach-methods would be useful? (f) Protocol sends back LAUNCH flag. We wouldn't receive this flag after the first connection. This is not necessarily a problem, but raises other issues: should the daemon restart/reinitialize itself between connections? If we allow multiple connections, should guestfsd fork so that each connection has a separate guestfsd process? (g) Are there access control / permissions / security issues? (h) Need to add a command line flag to guestfsd to allow sysroot to be set, then check that all of the code is OK with sysroot == "/". Any other issues? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org