[libvirt-users] Live external snapshot coalescing

[Kashyap Chamarthy]

On 03/05/2013 04:50 AM, Eric Blake wrote:
> On 03/04/2013 12:18 PM, Skardal, Harald wrote:
>> On standard Fedora 18 I was attempting blockcommit on a *live* VM,
>> libvirt said it was not supported, so I tried fedora-virt-preview as
>> recommended.
> 
> Correct - F18 shipped with libvirt 0.10.2 and qemu 1.2, but live
> blockcommit wasn't until libvirt 1.0.1 and qemu 1.3.
> fedora-virt-preview provides new enough alternatives.
> 
>>
>> We found a problem with qemu 1.4, there seems to be an acknowledged bug,
>> a missing library.
> 
> That's more of a fedora problem (and I see you reported it separately in
> a different email), so hopefully it gets fixed soon.
> 
>> On a different system we loaded Fedora 18, and then pulled qemu (1.3)
>> and libvirt (1.0.2) from rawhide.
>>
>> I tried blockcommit with domain shut down, it said must be up. Started
>> the domain, and voila, it seems to have worked.
> 
> Yeah, I still haven't finished the code to support offline blockcommit.
>  I know what needs to happen (it is basically a sequence of 'qemu-img
> commit' commands under the hood); the problem is that exposing it means
> that libvirt will have to do long-running job management.  With live
> blockcommit, qemu is doing the job management on libvirt's behalf, so
> that code was easier to write.
> 
> At least offline coalescing is something you can do yourself, if you are
> willing to get dirty with qemu-img commands yourself, followed by any
> cleanup to tell libvirt how to correct its view of the world to account
> for the changes you did behind its back with qemu-img.
> 
>>
>> Question: 
>>
>> The committed snap file (the one I committed to the image below) is
>> still in there, and virsh snapshot-list lists it. 
> 
> Another thing we have not yet coded - right now, there is no interaction
> between the libvirt snapshot code and the libvirt block commit code,
> which means any blockcommit (or blockpull) that changes the backing file
> layout may leave inconsistent snapshot metadata around.  If the bogus
> snapshot metadata is in the way, you can safely delete the metadata
> (virsh snapshot-delete --metadata $dom $name); or, you can go one step
> further and create your external snapshots without ever having libvirt
> track the metadata in the first place (virsh snapshot-create[-as] ...
> --no-metadata).
> 
> Someday, when we _properly_ represent an entire backing chain for each
> <disk> element, then we will also make sure that any libvirt operation
> that alters a backing chain (snapshot-create, blockcopy, blockcommit,
> blockpull) also alters all references to that backing chain (domain xml
> and all snapshots of that domain).  But that's a ways down the road.
> 
>> But the base and the upstream snap file has been updated, the upstream
>> snap file points to the base image as per qemu-img info.
>>
>> How/where do I update the metadata so that virsh displays the correct
>> thing? I.e. the committed snapshot should disappear?
> 
> The libvirt snapshot listing is stale, so deleting the metadata for that
> snapshot is the right solution for now.
> 
>>
>> Is it as simple as removing the committed snap? Do I have to restart
>> anything to get the virsh output correct?
> 
> No.  While 'virsh snapshot-delete' without options refuses to work on
> external snapshots, 'virsh snapshot-delete --metadata' has been working
> since libvirt 0.9.5 or so.

Adding to all the excellent points Eric said,

here's an example of recursive blockcommit --
http://kashyapc.fedorapeople.org/virt/blockcommit/recursive-blockcommit-base-qcow2.txt

It also includes a simple illustration of of deleting a snapshot metadata.

-- 
/kashyap

> 
> 
> 
> _______________________________________________
> libvirt-users mailing list
> libvirt-users at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>