Setting 'nodatacow' on VM image when on Btrfs

[Chris Murphy]

On Fri, Jul 10, 2020 at 6:16 AM Daniel P. Berrangé <berrange at redhat.com> wrote:
>
> On Thu, Jul 09, 2020 at 02:15:50PM -0600, Chris Murphy wrote:
> > On Thu, Jul 9, 2020 at 12:27 PM Daniel P. Berrangé <berrange at redhat.com> wrote:
> > Good point. I am open to suggestion/recommendation by Felipe Borges
> > about GNOME Boxes' ability to do installs by injecting kickstarts. It
> > might sound nutty but it's quite sane to consider the guest do
> > something like plain XFS (no LVM). But all of my VM's are as you
> > describe: guest is btrfs with the checksums and compression, on a raw
> > file with chattr +C set.
>
> GNOME Boxes / virt-install both use libosinfo for doing the automated
> kickstart installs. In the case of Fedora that's driven by a template
> common across all versions. We already have to cope with switch from
> ext3 to ext4 way back in Fedora 10. If new Fedora decides on btrfs
> by default, we'll need to update the kickstart to follow that
> recmmendation too
>
> https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/install-script/fedoraproject.org/fedora-kickstart-jeos.xml.in#L80

Understood.


> > For lives it's rsync today.  I'm not certain if rsync carries over
> > file attributes. tar does not. Also not sure if squashfs and
> > unsquashfs do either. So this might mean an anaconda post-install
> > script is a more reliable way to go, since Anaconda can support rsync
> > (Live) and rpm (netinstall,dvd) installs. And there is a proposal
> > dangling in the wind to use plain squashfs (no nested ext4 as today).
>
> Hmm, tricky, so many different scenarios to consider - traditional
> Anaconda install, install from live CD, plain RPM post-install,
> and pre-built disk image.

Also, the location for GNOME Boxes doesn't exist at install time, so
the installer doing it with a post-install script isn't a complete
solution.

While Boxes can use 'qemu-img create -o nocow=on' there is an
advantage of 'chattr +C' on the enclosing directory: files copied into
it, as well as new files created, inherit the attribute. Meanwhile, it
can't be set after the file has non-zero size.


> > It seems reasonable to me that libvirtd can "own"
> > /var/lib/libvirt/images and make these decisions. i.e. if it's empty,
> > and if btrfs, then delete it and recreate as subvolume and also chattr
> > +C
>
> Deleting & recreating as a subvolume is a bit more adventurous than
> I would like to be for something done transparently from the user.
> I think would need that to be an explicit decision somewhere tied
> to the libvirt pool build APIs.  Perhaps virt-install/virt-manager
> can do this though.

It's an optimization, not a prerequisite. And it's reasonable to just
cross this bridge if/when we get to it.

But it has dual benefits. And also a possible third, which is in a
'btrfs send/receive' use case where the incremental difference of the
subvolume can be computed and sent elsewhere, it's possible to
separate (e.g. backup policy) sysroot from VM images. 'btrfs send' has
a fairly cheap mechanism to identify only changed blocks without deep
traversal or comparison. Of course, it has to solve people's actual
problems, and prove itself useful.

--
Chris Murphy