Setting 'nodatacow' on VM image when on Btrfs

Chris Murphy lists at
Sun Jul 12 01:28:43 UTC 2020

On Fri, Jul 10, 2020 at 6:16 AM Daniel P. Berrangé <berrange at> 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> 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


> > 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

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

More information about the libvir-list mailing list