I just found out the hard way that we have a bug in snapshot-create-as, when I corrupted a guest. I was testing with an offline domain: # virsh dumpxml win64 |grep -C1 driver <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/sda4'/> # virsh snapshot-create-as win64 --disk-only --diskspec hda,file=/var/lib/libvirt/images/win64.qcow2 --no-metadata Domain snapshot 1417850911 created # virsh dumpxml win64 |grep -C1 driver <disk type='block' device='disk'> <driver name='qemu' type='qcow2'/> <source dev='/var/lib/libvirt/images/win64.qcow2'/> # systemctl restart libvirtd # virsh dumpxml win64 |grep -C1 driver <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/sda4'/> Even though we don't want to save the snapshot metadata, we DO need to save the XML change. Otherwise, the restarted libvirtd sees the wrong disk as the source; worse, if the user started the guest before restarting libvirtd, they run the risk of accidentally reverting to the pre-snapshot state and losing all changes they made in the meantime, perhaps even getting their guest filesystem into an inconsistent state. I'm out of time to get to a root cause or fix before next week, but wanted to report it now. I'm not sure if --no-metadata is essential to reproducing the bug, or if it happens in all cases. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org