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-b...
It also includes a simple illustration of of deleting a snapshot metadata.
--
/kashyap
_______________________________________________
libvirt-users mailing list
libvirt-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users