[Libguestfs] [PATCH 8/8 v2 DISCUSSION ONLY] fish: Add guestfish --live, guestmount --live options.

[Richard W.M. Jones]

On Thu, Feb 03, 2011 at 03:15:08PM +0000, Daniel P. Berrange wrote:
> On Fri, Jan 28, 2011 at 07:39:09PM +0000, Richard W.M. Jones wrote:
[...]

Thanks for reviewing these.  I'm trying to get something I can push
(even partial) before I go on holiday.

> > >From 4891a885aa7058faba901c059f08ddfbc5d43159 Mon Sep 17 00:00:00 2001
> > From: Richard W.M. Jones <rjones at redhat.com>
> > Date: Fri, 28 Jan 2011 19:25:02 +0000
> > Subject: [PATCH 8/8] fish: Add guestfish --live, guestmount --live options.
> > 
> > The other programs have the variable, but the flag is not enabled
> > either because it doesn't make sense or because the implications are
> > not well understood.
> > ---
> >  cat/virt-cat.c             |    2 ++
> >  cat/virt-filesystems.c     |    2 ++
> >  cat/virt-ls.c              |    2 ++
> >  df/main.c                  |    2 ++
> 
> I would have thought it was ok to support --live in
> these 4, since they're readonly apps in any case.

That argument is an argument _against_ doing it :-)

Currently there is nothing special about --ro in the protocol.  What
happens is that we add the drives using 'add-drive-ro' which uses
qemu's snapshot facility to unwind any writes: an anonymous snapshot
is mounted over each drive, writes are permitted, but they only update
the snapshot which is discarded at the end.

Thus you can use --ro / 'add_drive_ro' and your program can write
merrily away, safe in the knowledge that writes are being discarded by
qemu.  Your program can even read back the results of its writes.  In
fact in virt-resize we deliberately write to read-only drives.

The point anyway is the protocol itself does not have a "read only
mode" or any understanding of which operations are read-only vs write.
Some operations which seem like they must be read-only
(eg. 'mount-ro') can write to the disk.  The anonymous snapshot is
what saves us from having 'mount-ro' modify the superblock last mount
times, replay the journal, etc.

In the case of a live guest, we are able to write and there is no
snapshotting to unwind any changes we make.

'virt-cat', 'virt-df' and others almost certainly will make
unintentional changes to live guests (definitely mounting and
unmounting filesystems), and thus it is not safe to use them until we
have very carefully inspected the code and/or they are modified to
behave properly when run on a live guest.

> >  fish/fish.c                |    5 +++++
> >  fish/guestfish.pod         |    5 +++++
> >  fish/inspect.c             |    6 ++++++
> >  fish/options.h             |    1 +
> >  fish/virt.c                |    4 ++++
> >  fuse/guestmount.c          |    5 +++++
> >  fuse/guestmount.pod        |    5 +++++
> >  inspector/virt-inspector.c |    2 ++
> >  rescue/virt-rescue.c       |    2 ++
> 
> --live probably isn't useful for virt-rescue since if
> you need to rescue a machine it likely isn't running
> correctly & thus not have a guestfsd available.

Agreed.  Because of "direct mode"[1] it's not likely virt-rescue could
ever have a --live option.  Use ssh :-)

Rich.

[1] http://libguestfs.org/guestfs.3.html#guestfs_set_direct

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora