Patrick O'Callaghan <pocallaghan(a)gmail.com&gt; 于2020年12月23日周三 下午9:29写道： > > I have a directory I use to hold a Windows VM disk image > (/home/Windows/...), and would like to snapshot it before playing with > the QEMU settings. However it's already part of the /home subvolume, so > is there a way of splitting it off on its own without having to create > a new subvolume and sending the contents over? AFAIK subvolumes can be > hierarchical so it would seem like a useful thing to be able to convert > a subtree without all the copying, but the man page doesn't seem to > address it. You could create a subvolume, use cp --reflink=always to create a reflink, and delete the old directory, this turns a directory into subvolume easily without actual copying. But I don't suggest you do so, since using snapshot/reflink on VM images will make it Copy-on-Write, VM images should be nocow for performance. But can anyone figure out if creating a reflink then removing old references before any write to the file happens turns on CoW for the file? I am not sure. But writing after snapshot definitely turns on CoW.

Patrick O'Callaghan <pocallaghan(a)gmail.com&gt; 于2020年12月23日周三 下午9:29写道： > > I have a directory I use to hold a Windows VM disk image > (/home/Windows/...), and would like to snapshot it before playing with > the QEMU settings. However it's already part of the /home subvolume, so > is there a way of splitting it off on its own without having to create > a new subvolume and sending the contents over? AFAIK subvolumes can be > hierarchical so it would seem like a useful thing to be able to convert > a subtree without all the copying, but the man page doesn't seem to > address it. You could create a subvolume, use cp --reflink=always to create a reflink, and delete the old directory, this turns a directory into subvolume easily without actual copying. But I don't suggest you do so, since using snapshot/reflink on VM images will make it Copy-on-Write, VM images should be nocow for performance. But can anyone figure out if creating a reflink then removing old references before any write to the file happens turns on CoW for the file? I am not sure. But writing after snapshot definitely turns on CoW.

mv will fail between destinations with different nodatacow settings, hence cp.

The Windows image file is in fact just an fallocated file used as a raw disk, not a qcow. It's on an SSD and seems quite fast, so I wouldn't worry overmuch about fragmentation. This system is basically only used for gaming with GPU passthrough so pretty much everything can be lost.

My interest in snapshotting it is just to avoid the pain of a misconfig in QEMU, which is notoriously picky (lomng story short, I'm trying to modify it to use a Q35 CPU instead of the basic i440). The VM was set up on virt-manager when the filesystem was ext4, so it won't have any of the special BTRFS stuff unless I add it myself.

Expect further questions later :-)

You can also create a new vm from this exported xml using virsh create $vmname.xml Note that the name of the VM is in this file, so if you want to create a new VM you need to edit the xml file and change the name of the VM so it gets created with a new name.

Two other ideas: You could create an "original" copy of the VM that you never touch, and then clone it to restore. What I don't know is whether clone implies duplicating all the storage too. If so then you might want the original to have no file set for the virtual drive. I've gotten somewhat adept at fiddling with the xml using 'virsh edit $vm' but there's a somewhat recent feature you can enable in virt-manager to directly edit xml in virt-manager. For every device on the left side UI, there's GUI configuration on the right side, but at the top there's a tab to see the xml. You have to go dig in virt-manager preferences to enable xml editing, otherwise you just get to look at the xml, not change it. I've started doing this rather than editing the xml directly via virsh edit.

(I did read the whole thread but I'm gonna reply three times anyway :D) On Wed, Dec 23, 2020 at 6:29 AM Patrick O'Callaghan <pocallaghan(a)gmail.com&gt; wrote: > I have a directory I use to hold a Windows VM disk image > (/home/Windows/...), and would like to snapshot it before playing with > the QEMU settings. However it's already part of the /home subvolume, so > is there a way of splitting it off on its own without having to create > a new subvolume and sending the contents over? AFAIK subvolumes can be > hierarchical so it would seem like a useful thing to be able to convert > a subtree without all the copying, but the man page doesn't seem to > address it. Direct answer: cd /home btrfs subvolume create Windows2 chattr +C Windows2 cp Windows/* Windows2/ rm -rf Windows mv Windows2 Windows Explanation: The logic of this is to set the nodatacow attribute on Windows2, which then means overwrites by the guest will overwrite those same areas in the file, rather than COW. There's no direct COW penalty per se, it's just a redirection. The issue is it can result in fragmentation and that'll make subsequent reads slower due to having to seek for that fragment. It's a bigger problem on rotational drives, the seek latency is high and so is rotational latency. For all the libvirt locations, this is done for you on default clean Btrfs installs, when the pool (directory) is activated. Includes: virt-manager, gnome-boxes, cockpit. mv will fail between destinations with different nodatacow settings, hence cp. If the source and destination can support reflink copy, then reflink copy is used by default starting with Fedora 33 on both Btrfs and XFS. Note that reflink copies cannot cross mount points, that's a VFS limitation. So what'll happen is, cp falls back to regular copy, rather than being efficient. The reason for making /home/Windows a subvolume in my opinion is not to snapshot /home/Windows. But so you can snapshot /home and *exclude* /home/Windows. Snapshots aren't recursive (for developers they can be, see libbtrfsutil C API and Python bindings). So this keeps your VM images nodatacow. Instead what I do is "snapshot" the VM files by reflink copy within their own directory. And yes they get quite a lot more fragmented. cp win10.raw win10-updated.raw Again, it's a reflink copy because (a) that's the cp default on F33 and (b) the source and destination files are going to be nodatacow since we're staying in the same directory. So this cp is fast. And if you 'du' the ../Windows directory it'll hilariously count these files twice, but if you use 'btrfs fi du -s' you'll be introduced to some new terminology: exclusive and shared data. You might prefer doing snapshots the qcow2 way, although I have no idea what "qemu-img snapshot" does because I've never used it. I've only used "qemu-img create -b" to create a new qcow2 file that points to the original as a backing file. Why? *shrug* I don't know. But I throw it out there as an option. Whether you use 'cp' to make a reflink copy (fast copy, efficient copy) or you 'btrfs sub snap /home/Windows /home/Windows.20201223' or however you want to name them, there is a gotcha. Those nodatacow extents now *cannot* be overwritten because they've been snapshot. They are now cow again for any writes that would be an overwrite. But it's only a one time redirect. It'll COW a shared block to a new location (exclusive block) and any subsequent changes for that block will be nodatacow again... unless you make another snapshot. So yeah, no free lunch. There's always a tradeoff. And that's why you might consider a different way to preserve the images. Windows NTFS in particular has fairly remarkable write patterns that result in a lot of fragmentation on any file system. But it is especially bad on Btrfs. I speculate that the dual journaling technique it uses just ends up being turned into piles of "appends" onto a sparse raw file if it's COW. Your best bet really is to fallocate a raw file in a subvolume or directory with chattr +C set and don't snapshot or reflink copy it. That's very much like what you get with a raw file on XFS or ext4. And perhaps a tiny bit more overhead than a conventional LVM LV, which is really your best bet if performance is the top concern. Another thing I use in virt-manager is cache mode unsafe. I can't recommend it because, I mean, it's not safe. But it's a lot faster. So if you don't care about your data, and I definitely don't, and you care about performance, unsafe cache mode is awesome. And worth finding another way to mitigate the possibility of guest writes happening when power is yanked from the host and totally trashes the guest's file system. (I have had it trash NTFS in this scenario; but never once have I damaged Btrfs in such a guest. The unsafeness does come from the host crashing, not the guest. You can probably get away with force quitting the guest all you want. I do this all the time because (a) I hate my data and (b) I'm impatient. :D But yeah I also backup my data other ways so if it goes kaboom, it's actually fun because I get to use my backups. I am the reason for my backups...