Hide Forgot
Description of problem: virsh vol-clone drop the internal snapshot of qcow2 image Version-Release number of selected component (if applicable): libvirt-0.9.2-1.el6.x86_64 qemu-kvm-0.12.1.2-2.165.el6.x86_64 kernel-2.6.32-156.el6.x86_64 virt-manager-0.8.6-4.el6 How reproducible: 100% Steps to Reproduce: 1) #virsh snapshot-list snap-test Name Creation Time State --------------------------------------------------- 2) #virsh snapshot-create snap-test Domain snapshot 1309419977 created 3) # virsh snapshot-list snap-test Name Creation Time State --------------------------------------------------- 1309419977 2011-06-30 15:46:17 +0800 running 4) # virsh shutdown snap-test Domain snap-test is being shutdown 5) # virsh vol-clone /var/lib/libvirt/images/clone-2.qcow2 snap-test.qcow2 Vol snap-test.qcow2 cloned from clone-2.qcow2 6) #qemu-img info snap-test.qcow2 image: snap-test.qcow2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 4.2G cluster_size: 65536 Actual results: no snapshot Expected results: image still have the snapshot Additional info: after vol-clone check the source image still has the snapshot # qemu-img info clone-2.qcow2 image: clone-2.qcow2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 4.7G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 1309419977 491M 2011-06-30 15:46:17 00:05:00.995
It's not dropped by "vol-clone", the storage driver doesn't have any stuff related to snapshot, means it even doesn't support management of volume snapshot in storage driver. What you see snap-* in virsh is implemented by underlying hypervisor driver, currently, only ESX, VBOX, and QEMU driver support it, what libvirt does is sending request to the hypervisor for snapshot management. Agree that it might help if probing the snapshot of volume, and support it in volume def in storage driver, though.
yeah this is really something that should be handled by a higher level cloning tool or API, this isn't vol-clone's fault