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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvirt-users > _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
