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