[Libguestfs] RFC: OSTree support

Pino Toscano ptoscano at redhat.com
Tue Jan 13 16:03:40 UTC 2015


Hi,

currently, libguestfs does not support the inspection of OSTree/Atomic
disk images [1].
While this means that certain tools which use inspection to
automatically mount all the partitions available (virt-customize,
virt-builder, virt-sysprep, virt-diff, guestfish -i, and the default
modes of virt-cat, virt-log, virt-edit) will fail, although it's still
possible to manually mount partitions as usual.

Let's start from an example, the Fedora 21 cloud/atomic image,
Fedora-Cloud-Atomic-20141203-21.x86_64.qcow2 (or .raw.xz):

  ><fs> list-filesystems 
  /dev/sda1: ext4
  /dev/atomicos/root: xfs

/dev/sda1 is a "shared /boot", while /dev/atomicos/root contains the
root and all the deploys:

  /
  +- /ostree/deploy/fedora-atomic
     +- deploy/ba7ee9475c462c9265517ab1e5fb548524c01a71709539bbe744e5fdccf6288b.0

so there is a single deploy, "fedora-atomic", containing one OS in it,
ba7ee9475...etc (having revision 0).

Considering I would prefer to not lose information of any of the bits
in the image (root and OSTree trees), so far I see two ways to properly
represent these information within libguestfs:

A) Single OS, multiple levels of mount points
This would mean representing OSTree images like:

  /
  + deploy-A
  | + checksum-1 (mount point / of it)
  | | + mountpoint-1
  | | + ...
  | | + mountpoint-N
  | + ...
  | + checksum-N
  + ...
  + deploy-N

Pro:
- single OS found by inspection
- dynamically represent all the deploys

Contra:
- multi-level mount points are not supported
- tools would need to mount stuff in a better way than "get the list
  of mount points, sort them, and mount them"
- need to proper "remap" the mount points in each checksum to the
  actual directory of the checksum itself, so e.g. /boot found in the
  fstab would be /ostree/deploy/$DEPLOY/deploy/$CHECKSUM/boot
- need to support bind mounts, so it's easier to just mount one
  checksum to / or within its directory in the "global" root

B) Multiple roots
This would mean representing the "global" root and each "checksum root"
as different "OS", i.e. different roots returned by the inspection, so:

  inspection:
  + /
  + checksum-1 (mount point / of it)
  | + mountpoint-1
  | + ...
  | + mountpoint-N
  + ...
  + checksum-N

Pro:
- each OS is handled as separate OS
- single level of mount points for each OS, like done currently

Contra:
- tools would need to support multiple roots, and possibly let users
  select which one


So far that's the not-in-depth summary of what's needed to be done,
at least from what I could say.

Thoughts?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1102241

Thanks,
-- 
Pino Toscano




More information about the Libguestfs mailing list