[libvirt-users] After a 'virsh blockpull', 'virsh snapshot-list --tree' o/p does not reflect reality
Hi (Eric?), A couple of questions while using the 'virsh blockpull' Summary: 1] Created snapshots this way: base<-snap1<-snap2<-snap3 (online, external snapshot --disk-only) 2] I did a 'virsh blockpull' from snap2 into snap3 3] Next, did another 'virsh blockpull' from snap1 into snap3 - Here, 'qemu-img info /path/to/snap3' shows its backing file correctly as snap1. But not 'virsh snapshot-list $domain --tree' . Any hints? Detail: #=========================================# [root@moon ~]# virsh domblklist daisy --details Type Device Target Source ------------------------------------------------ file disk vda /export/vmimgs/daisy.qcow2 [root@moon ~]# #=========================================# [root@moon ~]# virsh snapshot-create-as daisy snap1-daisy "snap1 description" --diskspec vda,file=/export/vmimgs/snap1-daisy.qcow2 --disk-only --atomic Domain snapshot snap1-daisy created [root@moon ~]# #=========================================# [root@moon ~]# virsh snapshot-create-as daisy snap2-daisy "snap2 description" --diskspec vda,file=/export/vmimgs/snap2-daisy.qcow2 --disk-only --atomic Domain snapshot snap2-daisy created [root@moon ~]# #=========================================# [root@moon ~]# virsh snapshot-create-as daisy snap3-daisy "snap3 description" --diskspec vda,file=/export/vmimgs/snap3-daisy.qcow2 --disk-only --atomic Domain snapshot snap3-daisy created #=========================================# [root@moon libvirt-0.10.1-3]# virsh snapshot-list daisy Name Creation Time State ------------------------------------------------------------ clean-rawhide-f17 2011-12-08 14:34:55 +0530 shutoff snap1-daisy 2012-09-12 14:58:18 +0530 disk-snapshot snap2-daisy 2012-09-12 14:59:30 +0530 disk-snapshot snap3-daisy 2012-09-12 15:00:36 +0530 disk-snapshot #=========================================# [root@moon libvirt-0.10.1-3]# virsh snapshot-list daisy --tree clean-rawhide-f17 snap1-daisy | +- snap2-daisy | +- snap3-daisy [root@moon libvirt-0.10.1-3]# #=========================================# => For clarity, listing out the backing files of each image. #=========================================# [root@moon libvirt-0.10.1-3]# qemu-img info /export/vmimgs/snap3-daisy.qcow2 image: /export/vmimgs/snap3-daisy.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 129M cluster_size: 65536 backing file: /export/vmimgs/snap2-daisy.qcow2 #=========================================# [root@moon libvirt-0.10.1-3]# qemu-img info /export/vmimgs/snap2-daisy.qcow2 image: /export/vmimgs/snap2-daisy.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 3.6M cluster_size: 65536 backing file: /export/vmimgs/snap1-daisy.qcow2 #=========================================# [root@moon libvirt-0.10.1-3]# qemu-img info /export/vmimgs/snap1-daisy.qcow2 image: /export/vmimgs/snap1-daisy.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 2.5M cluster_size: 65536 backing file: /export/vmimgs/daisy.qcow2 [root@moon libvirt-0.10.1-3]# #=========================================# => NOTE: we're pulling snap2 data into snap3, by doing a 'virsh blockpull' <= #=========================================# [root@moon libvirt-0.10.1-3]# virsh blockpull --domain daisy --path /export/vmimgs/snap3-daisy.qcow2 --base /export/vmimgs/snap2-daisy.qcow2 --wait --verbose Block Pull: [100 %] Pull complete [root@moon libvirt-0.10.1-3]# #=========================================# [root@moon libvirt-0.10.1-3]# qemu-img info /export/vmimgs/snap3-daisy.qcow2 image: /export/vmimgs/snap3-daisy.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 143M cluster_size: 65536 backing file: /export/vmimgs/snap2-daisy.qcow2 [root@moon libvirt-0.10.1-3]# #=========================================# [root@moon libvirt-0.10.1-3]# virsh snapshot-list daisy --tree clean-rawhide-f17 snap1-daisy | +- snap2-daisy | +- snap3-daisy [root@moon libvirt-0.10.1-3]# #=========================================# => Now, let's pull the data from 'snap1' into 'snap3' (so that we can make 'snap2' redundant, and reduce the snapshot chain. #=========================================# [root@moon libvirt-0.10.1-3]# virsh blockpull --domain daisy --path /export/vmimgs/snap3-daisy.qcow2 --base /export/vmimgs/snap1-daisy.qcow2 --wait --verbose Block Pull: [100 %] Pull complete #=========================================# NOTE: now the snapshot-tree should flattened (as we pulled the data from snap1 into snap3). Let's check by running 'qemu-img' . (so the backing-file is now pointing to snap1, as expected) #=========================================# [root@moon libvirt-0.10.1-3]# qemu-img info /export/vmimgs/snap3-daisy.qcow2 image: /export/vmimgs/snap3-daisy.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 145M cluster_size: 65536 backing file: /export/vmimgs/snap1-daisy.qcow2 [root@moon libvirt-0.10.1-3]# #=========================================# Here, shouldn't 'virsh snapshot-list' --tree be updated as well ?(since 'snap2' is no more the backing file for 'snap3' ?) #=========================================# [root@moon libvirt-0.10.1-3]# virsh snapshot-list daisy --tree clean-rawhide-f17 snap1-daisy | +- snap2-daisy | +- snap3-daisy [root@moon libvirt-0.10.1-3]# #=========================================# Version Details: #=========================================# [root@moon ~]# rpm -q qemu-kvm libvirt; uname -r qemu-kvm-1.2-0.2.20120806git3e430569.fc17.x86_64 libvirt-0.10.1-3.fc17.x86_64 3.5.2-3.fc17.x86_64 [root@moon ~]# #=========================================# Any ideas why the 'tree' isn't updated yet? -- /kashyap
On 09/13/2012 02:59 AM, Kashyap Chamarthy wrote:
Hi (Eric?),
A couple of questions while using the 'virsh blockpull'
Summary:
1] Created snapshots this way: base<-snap1<-snap2<-snap3 (online, external snapshot --disk-only) 2] I did a 'virsh blockpull' from snap2 into snap3 3] Next, did another 'virsh blockpull' from snap1 into snap3
You could have also done a 'virsh blockpull' from snap1 into snap3 without the intermediate pull of snap2, but shouldn't make a difference to your end question.
- Here, 'qemu-img info /path/to/snap3' shows its backing file correctly as snap1. But not 'virsh snapshot-list $domain --tree' . Any hints?
virsh snapshot-list is still accurately listing the state of the tree at the time of the snapshot, not what you have done after the snapshot. If you were to revert to snap1 or snap2 (assuming that I ever get revert-to-disk-snapshots working), you would still be able to do that, provided you haven't deleted snap1 or snap2 from your file system. That is, it is feasible to go from: base<-snap123 (snap1 and snap2 were pulled into snap3) and then revert back to: base<-snap1 (undo the changes that were in snap2 and snap3) Libvirt does not modify any snapshot information when doing a blockpull operation, and I'm not yet convinced that it even needs to. (I'm dreading if it does, because having a blockpull update the snapshot tree seems rather complicated.)
Here, shouldn't 'virsh snapshot-list' --tree be updated as well ?(since 'snap2' is no more the backing file for 'snap3' ?)
The snapshot chain is independent of each disk's backing chain. The snapshot chain is still correct, because you haven't used 'virsh snapshot-delete' to shorten the snapshot chain (then again, I still haven't implemented that for disk snapshots...) -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 09/13/2012 08:56 PM, Eric Blake wrote:
On 09/13/2012 02:59 AM, Kashyap Chamarthy wrote:
Hi (Eric?),
A couple of questions while using the 'virsh blockpull'
Summary:
1] Created snapshots this way: base<-snap1<-snap2<-snap3 (online, external snapshot --disk-only) 2] I did a 'virsh blockpull' from snap2 into snap3 3] Next, did another 'virsh blockpull' from snap1 into snap3
You could have also done a 'virsh blockpull' from snap1 into snap3 without the intermediate pull of snap2, but shouldn't make a difference to your end question.
- Here, 'qemu-img info /path/to/snap3' shows its backing file correctly as snap1. But not 'virsh snapshot-list $domain --tree' . Any hints?
virsh snapshot-list is still accurately listing the state of the tree at the time of the snapshot,
OK.
not what you have done after the snapshot. If you were to revert to snap1 or snap2 (assuming that I ever get revert-to-disk-snapshots working),
Um, till 'revert' is implemented, I'd assume, the existing use-cases with 'external-disk/live' snapshots would be the ability to manage/manipulate the backing chain. Or take the guest offline and do the snapshot-manipulation with 'qemu-img'
you would still be able to do that, provided you haven't deleted snap1 or snap2 from your file system. That is, it is feasible to go from:
base<-snap123 (snap1 and snap2 were pulled into snap3)
and then revert back to:
base<-snap1 (undo the changes that were in snap2 and snap3)
Libvirt does not modify any snapshot information when doing a blockpull operation, and I'm not yet convinced that it even needs to. (I'm dreading if it does, because having a blockpull update the snapshot tree seems rather complicated.)
Agreed. As is, the differentiation between 'snapshot chain' and 'backing chain' can be easily missed(like I did) if not closely observed.
Here, shouldn't 'virsh snapshot-list' --tree be updated as well ?(since 'snap2' is no more the backing file for 'snap3' ?)
The snapshot chain is independent of each disk's backing chain.
This is the point, I should have had more clarity about.
The snapshot chain is still correct, because you haven't used 'virsh snapshot-delete' to shorten the snapshot chain (then again, I still haven't implemented that for disk snapshots...)
Noted. Thanks, for your lucid responses(as usual). Also, when you have a moment, can you please differentiate between 'blockcopy' and 'blockpull' /me is reading the 'virsh' man page for the details, but a bit more explanation about what scenarios it'd be useful will help clarify things while I'm experimenting with them.
-- /kashyap
participants (2)
-
Eric Blake -
Kashyap Chamarthy