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