[libvirt-users] Deleting and coalescing live snapshots

[Kashyap Chamarthy]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
> 


-- 
/kashyap