On Thu, 2020-12-24 at 14:27 -0700, Chris Murphy wrote: > On Thu, Dec 24, 2020 at 4:23 AM Patrick O'Callaghan > <pocallaghan@xxxxxxxxx> wrote: > > > > 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. > > Latencies are much lower on SSD. > > > 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. > > Note that the VM image file contains no VM settings. So a snapshot of > the VM image only helps you preserve/rollback to a previous state of > that image. The image contains only file systems. So if the idea is to > roll back the guest's file system, then you're on the right track. If > the idea is to be able to rever qemu configuration, you want something > else. Yes, good point. > My advice is to use: > virsh dumpxml $vmname > $vmname.xml > > You can then make modifications, and dump that out as a separate name, > and you can diff the xml files. > > 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. Yes. poc _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx