Libguestfs - Dec 2012 - Supporting btrfs subvolumes during inspection

We've currently got a bug in libguestfs which means we can't inspect 
filesystems in btrfs subvolumes:

https://bugzilla.redhat.com/show_bug.cgi?id=824021

This is the default configuration if you select btrfs in F17+. The issue 
is that it requires an api to fix it, as the return values of 
inspect_os, inspect_get_filesystems and inspect_get_mountpoints can't 
express a btrfs subvolume as they're expected to be the names of block 
devices.

As a starter for 10, I propose the addition of parallel apis suffixed 
_ext which return annotated device descriptions, e.g.:

block:/dev/vda2
btrfsvol:/dev/vda4,root

The string before the colon is a descriptor. The format of the string 
after the colon is custom to the descriptor, and is described in the 
API. A client program can ignore strings with unknown descriptors. New 
descriptors can be added as required.

The old apis would return the same as the _ext versions, except they 
would only return block devices. Other devices would be omitted.

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

On Thu, Dec 20, 2012 at 05:24:37PM +0000, Matthew Booth
wrote:
> We've currently got a bug in libguestfs which means we can't
inspect
> filesystems in btrfs subvolumes:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=824021
> 
> This is the default configuration if you select btrfs in F17+. The
> issue is that it requires an api to fix it, as the return values of
> inspect_os, inspect_get_filesystems and inspect_get_mountpoints
> can't express a btrfs subvolume as they're expected to be the names
> of block devices.
> 
> As a starter for 10, I propose the addition of parallel apis
> suffixed _ext which return annotated device descriptions, e.g.:
> 
> block:/dev/vda2
> btrfsvol:/dev/vda4,root
> 
> The string before the colon is a descriptor. The format of the
> string after the colon is custom to the descriptor, and is described
> in the API. A client program can ignore strings with unknown
> descriptors. New descriptors can be added as required.
> 
> The old apis would return the same as the _ext versions, except they
> would only return block devices. Other devices would be omitted.
Hmm, sounds ugly.  We are now allowed to promote non-optargs functions
to optargs functions (as long as you set once_has_no_optargs = true),
so a better way to do what you're proposing would be to add an OBool
flag to the existing APIs.

However ..  Could we instead modify inspect_os to return a modified
'root' string (for btrfs subvolumes only) which would be something
like "/dev/vda4:/root" (ie. "device:subvolume").  It depends
whether
you consider the root that's returned now to be essentially an opaque
string.

Maybe we could have an OBool flag to turn on this behaviour, and give
an error if the flag is not specified.  That's roughly isomorphic to
your proposal.

inspect-get-mountpoints & inspect-get-filesystems also have to be
changed or extended, or we could replace them with inspect-get-*2
variants that can return (device, subvolume) pairs.

This also gets me thinking if there are many other places in the API
where the current device is not sufficient to specify a filesystem
(eg. inspect-list-filesystems?  probably not).

Is the Fedora proposal that multiple snapshots will be represented by
separate subvolume names?  Or that multiple parallel Fedora installs
will be possible in subvolumes?  Or a bit of both?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top