On 02/28/2013 05:46 AM, Eric Blake wrote: > On 02/27/2013 11:38 AM, Skardal, Harald wrote: >> I have a service that takes new live KVM snapshots Si regularly, keeps a >> fixed number N (Si ,..,Si-N+1), and therefore needs to delete Si-N in >> this cycle. >> >> Until libvirt includes support for this capability that is said to be >> available in qemu, what is a safe workflow to delete old live KVM >> snapshots w/o losing data. Do I need to pause/shut down the VM? > >> >> The development environment is Fedora 18 with qemu, libvirtd and libvirt >> upgrades to the more recent stable versions. > > Are you using the fedora-virt-preview repo? If so, that gives you: > qemu-1.4.0-1.fc18.x86_64 > libvirt-1.0.2-2.fc18.x86_64 > > which is indeed the latest upstream releases of both projects at the > time of my email. In which case, you're in luck! You can delete old > snapshots without any guest downtime. > > Next question: are your snapshots internal or external? Or in other > words, what command did you use to create the snapshots? I'll try to > answer for both setups: > > > Assuming your snapshot was internal (such as one created via 'virsh > snapshot-create' without the --disk-only or --memspec flag), then you > have the following setup: > > 'virsh snapshot-list $dom' shows a list of snapshots, and 'qemu-img info > /path/to/file' also shows[*] the same list of internal snapshots. You > can delete the snapshots you no longer need with 'virsh snapshot-delete > $dom $snapname' whether the guest is running or offline; but be aware > that while it frees up the reference counting in the qcow2 file, current > qemu is unable to make decent use of that space (that is, qemu is lousy > at defragmentation). If you must reclaim disk space, then using > 'qemu-img convert' or something like 'virt-sparsify' from libguestfs, > while your guest is offline, would be a good followup operation for > saving JUST the current image, but I don't know of any good command for > preserving all of the existing internal snapshots of a qcow2 image while > still compacting away unused space. > > [*] Technically, using qemu-img info on a file in active use by qemu is > not guaranteed to be safe, but as a read-only operation, the worst it > can do is see inconsistent information. Be careful, though, as there > are other qemu-img operations that can corrupt an in-use image in a > manner visible to the guest. Hence, I prefer to use qemu-img only on > files while the guest is offline. > > > Assuming your snapshot was external (such as one created via 'virsh > snapshot-create --disk-only'), then your version of libvirt does not yet > support deletion of entire snapshots (although we have posted some > design ideas on the list on how we plan to get there in a future > libvirt). But what you can do is one of two techniques to shorten the > backing chain, then tell libvirt to discard the metadata for the > snapshots that no longer make sense, then manually delete the files you > no longer need. Notationally, you are starting from a disk chain that > looks like: > > base <- snap1 <- snap2 <- snap3 <- current > > and you want to get rid of snap1. The two choices are to commit the > contents of snap1 into a lower level, using 'virsh blockcommit $dom > $disk --top snap2 --base base ...': > > base' <- snap2 <- snap3 <- current > > or to pull the contents of snap1 into a higher level, using 'virsh > blockpull $dom $disk --base base ...': > > base <- current' > > Use 'virsh help blockcommit' or 'virsh help blockpull' to see more > details on the commands, and use 'virsh domblklist $dom' to see a list > of disk names tied to a given domain. Personally, I like the '--wait > --verbose' flags, as it gives a nice log of progress in a potentially > long-running operation. > > Blockcommit in your version of qemu has a limitation - it can only > commit data from one backing file into another (that is, you can commit > from snap3 into any earlier image to remove snap3 from the chain, but > cannot commit from current into snap3 to remove current from the chain). > We are still trying to design how to make blockcommit run from the top > of a chain, although it might not make qemu 1.5. Also, blockcommit has > a caveat - if you use thin provisioning (that is, if more than one guest > shares a common base file), then you must NOT commit into that common > base file (someday, I'd like to teach libvirt to have the smarts to > prevent you from doing stupid actions on common shared backing files, > but that also involves teaching libvirt to track entire backing chain > information in domain xml). > > Likewise, blockpull in your version of qemu has a limitation - it can > only pull data into the current (topmost) image of the chain; we are > still trying to design how to make blockpull target an intermediate > point in the chain of a running qemu, but that might not make qemu 1.5. > However, while blockcommit invalidates any images that have branched > off a common backing file, blockpull leaves all other images intact, so > you can still revert to the images that have been removed from the > backing chain. > > Additionally both of these commands are limited to working on a running > guest; the same operations can be done for offline disk images with > manual use of qemu-img ['qemu-img commit' and 'qemu-img rebase'], but I > hope to someday wire up libvirt to support the same operations without > making you have to use anything outside of virsh. Depending on what > manual qemu-img actions you do, you might also have to 'virsh edit $dom' > to teach libvirt about the manual changes you made. > > Then, whether you used commit or pull to shorten your backing chains, > you would then use 'virsh snapshot-delete $dom $name --metadata' to tell > libvirt to discard the metadata about the snapshots that no longer make > sense. > > > Finally, since you are using new enough libvirt and qemu, I would > suggest looking into using 'virsh blockcopy ...' as a potential backup > mechanism. Unlike 'virsh snapshot-create' which lengthens the backing > chain of the running image so that you can then back up from the backing > file, 'virsh blockcopy' can create backups of a running guest without > ever affecting the chain length of the running image. That also comes > with a caveat - in your current tool versions, blockcopy can only be > done on a transient guest; we are waiting for persistent bitmap support > to be added in qemu 1.5 before libvirt will allow a blockcopy on a > persistent guest. But at least you can temporarily 'virsh undefine' a > guest to make it transient, do the block copy, then 'virsh define' the > guest again, all while the guest remains running. Blockcopy can also be > used to do some more interesting (aka more complex) conversions: by > doing a shallow copy, you can effectively rebase a live current image > onto a new backing chain with the same contents as the original but > where the division of contents in the new backing chain is completely > under your control. There's so much of useful information here, this shouldn't get lost. I'll try to capture it make a post. Thanks Eric, for the excellent detail. > > > > _______________________________________________ > libvirt-users mailing list > libvirt-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvirt-users > -- /kashyap _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
