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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users