On 06/09/2013 02:46 PM, Thomas Stein wrote: Wait - is that really the command you used after "snapshot-create" ? Because: You cannot undefine a guest with a snapshot without first deleting its metadata To cleanly delete, maybe you should've done: $ virsh snapshot-delete --domain gentoo-template SNAPSHOTID --metadata Can you also paste the output of: $ qemu-img info --backing-chain \ /opt/virt-backup-blockcopy/gentoo-template/gentoo-template.qcow2 Here's how I used blockcopy (few months ago, slightly outdated) -- http://kashyapc.fedorapeople.org/virt/lc-2012/live-backup-with-blockcopy.txt -- /kashyap

On 06/10/2013 01:20 PM, Thomas Stein wrote: Yes. (I just understood what you wanted to do). Noted my details below. Let's try. I just did the below test (also I noted it in the URL below) # Take an (internal) snapshot when the guest was shutdown $ virsh snapshot-list fed18 Name Creation Time State ------------------------------------------------------------ 1370847718 2013-06-10 12:31:58 +0530 shutoff # Start the guest $ virsh start fed18 # Undefine the guest while it is running - this will # make the guest transient (libvirt expects it to be 'transient') $ virsh undefine fed18 Domain fed18 has been undefined # List the guest root@~$ virsh list Id Name State ---------------------------------------------------- 3 fed18 running $ # Do blockcopy (it's only when the guest is "live") $ virsh blockcopy --domain fed18 vda \ /export/backup/images/fed18.qcow2 --wait --finish --verbose Block Copy: [ 100 %] # Query the info of original image: =========== root@~$ qemu-img info --backing-chain /var/lib/libvirt/images/el6box1.qcow2 image: /var/lib/libvirt/images/el6box1.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 1.2G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 1370853048 0 2013-06-10 14:00:48 00:00:00.000 =========== $ qemu-img snapshot -l /var/lib/libvirt/images/el6box1.qcow2 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 1370853048 0 2013-06-10 14:00:48 00:00:00.000 =========== # Query info of the backup: =========== $ qemu-img info --backing-chain /export/backup/images/el6box1-back.qcow2 image: /export/backup/images/el6box1-back.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 10G cluster_size: 65536 =========== $ qemu-img snapshot -l /export/backup/images/el6box1-back.qcow2 =========== Hm, from what it looks, it doesn't appear to preserve the internal snapshot.. -- /kashyap

Some more details - blockcopy's usecase is different: (1) to create a copy of a chain, and optionally "pivoting" live qemu to use that copy instead of the original. Here, 'pivoting' means: Going from base<-snap1<-path1/to/snap2 to base<-snap1<-path2/to/snap2, where path{1,2}/to/snap2 are copies at the time of the pivot. (2) It is also possible to take a copy but not pivot to it, for backup purpose, so blockcopy has a choice of shallow or full: If you use --shallow, only the leaf image is copied, the rest of the chain is untouched. So if you have base <- snap1 <- active; copy --shallow creates base <- snap1 <- copy (where copy matches active); copy without shallow creates "copy", where copy matches the entire chain. -- /kashyap