[libvirt] RFC: xml-snapshot-data out-of-sync to .qcow2 data

Eric Blake eblake at redhat.com
Fri Nov 16 14:35:02 UTC 2012


On 11/15/2012 11:10 PM, Philipp Hahn wrote:
> Hello Eric, hello List,
> 
> As QEMU stores the snapshot data inside the qcow2 files, modifing them 
> directly might bring libvirts snapshot data out-of-sync. In my case a user 
> replaced a qcow2 with a new file re-using the old name. libvirt still thinks 
> that the snapshots are valid, while in reality the data is missing:
> 
>> # virsh snapshot-revert snap-test foo
>> error: internal error Child process (/usr/bin/qemu-img snapshot -a 
> foo /var/lib/libvirt/images/snap-test.qcow2) status unexpected: exit status 1
> 
> What would fix this scenario would be a validation mechanism within libvirt, 
> which walks all snapshots and checks, if each referenced qcow2 file actually 
> has the required snaphot data and mark the snapshot as invalid otherwise. 
> This would require an addition to the xml data to add such a flag.
> 
> Or I could tell my users again not to re-use names still used by older 
> snapshots, but that doesn't work as you see ;-)

Yes, and my plan has been to someday implement code in libvirt that
reads actual qcow2 files (preferably reading the new qemu-img info JSON
output mode of qemu 1.2) to learn all embedded snapshots in the image
when requested by the user, and treat those as snapshots that have no
libvirt metadata associated.  Then we can use that to prevent collisions
of pre-existing names, as well as flag libvirt snapshots that no longer
make sense due to external edits to the qcow2 files.

But someone has to do the work, and I haven't had time to look at it.
Patches are welcome.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121116/569176dc/attachment-0001.sig>


More information about the libvir-list mailing list