Libguestfs - Jan 2011 - 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]
  ><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

Thinking about the way we deal with "sessions" between the host and
the daemon in the guest over virtio-serial.  The current way this
works is as follows:

    Host                           Guest
    ----                           -----

  create socket
  start qemu
                                  start daemon
                                  open virtio device
               <--------------
  accept(2)

               ... operations ...

  close(2)
               -------------->
                                   read returns 0
                                   exit

For the case where guestfsd is running free as a daemon in a guest,
then we don't want it to just exit after the first connection.

virtio-serial and guestfsd only allow one connection on a channel at a
time (see: http://www.linux-kvm.org/page/Virtio-serial_API).

So we change this to:

    Host                           Guest
    ----                           -----

                                  start daemon

                                  open virtio device <-----+
                                  (blocks until            |
                                     accepted on host)     |
               <--------------                             |
  accept(2)                                                |
                                                           |
               ... operations ...                          |
                                                           |
  close(2)                                                 |
               -------------->                             |
                                   read returns 0          |
                                   close                   |
                                   partial reset of        |
                                     internal state        |
                                         |                 |
                                         +-----------------+

This is assuming my understanding of virtio-serial is correct.
I've not tried it yet.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/