Re: Setting 'nodatacow' on VM image when on Btrfs
On Fri, Jul 10, 2020 at 6:16 AM Daniel P. Berrangé <berrange(a)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(a)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/...
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