[libvirt-users] After a 'virsh blockpull', 'virsh snapshot-list --tree' o/p does not reflect reality
10:59 a.m.
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
5:26 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
6:03 p.m.
On 09/13/2012 08:56 PM, Eric Blake wrote:
--
/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,
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.
4389
days inactive
4389
days old
2 comments
2 participants
participants (2)
-
Eric Blake -
Kashyap Chamarthy