[Libguestfs] Connecting to existing guests / guestfsd

[Richard W.M. Jones]

[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]
  ><fs> copy-in files /tmp

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