[libvirt-users] Disk-only internal snapshot

[Abbas]

On 10/25/2012 02:44 AM, Eric Blake wrote:
> On 10/24/2012 03:01 PM, Davide Guerri wrote:
>> Thank you Eric for the quick reply!
>> Do you know if there's a way to remove (not revert) an external snapshot on
>> a live domain?

I had the same needs as yours. Eric answered the questions I had.
So I wrote up live snapshots part of this wiki.
Would save your time though.

https://wiki.archlinux.org/index.php/Kvm#Live_Snapshots

There is also an article of live snapshots on Fedora's wiki too.

--
abbas

> Depends on what version of libvirt and qemu you are using :)
>
> Qemu 1.2 and libvirt 0.9.10 provide the virDomainBlockRebase (qemu
> 'block-stream') for flattening an external snapshot chain by pulling
> into the active image, while the guest is running.  You have to deal
> with the fact that every time you take a snapshot, the active image name
> changes, but it's fairly reliably as a way of reducing the impact of a
> long chain of external snapshots.
>
> Qemu 1.3 (due in December) will be adding a new 'block-commit' monitor
> command, which libvirt 1.0.0 (due next week) will also be able to reduce
> backing chains by committing data from a snapshot back into the backing
> image, while the guest is running.  As of now, qemu.git is limited to
> committing just read-only portions of the backing chain, but we hope to
> expand that to also committing the read-write active layer of the chain.
>
> You can pair these chain-shortening commands with 'virsh snapshot-delete
> $dom $snapname --metadata' to make it appear as if the snapshot never
> happened.  It is even possible to do a sequence of snapshots and
> pulls/commits to get back to the original file name (of course, with
> twice the work as you go through a temporary file name).
>
>> I'm trying to backup (live) machines with the shortest downtime possible.
> Then you may also be interested in Peter's and my recent patches, which
> make it possible to back up machine RAM state in addition to disk state,
> with very minimal downtime, and which also enhance what you can do with
> revert and delete of those snapshots:
> https://www.redhat.com/archives/libvir-list/2012-October/msg01290.html
> It's definitely faster than the current downtime of 'virsh
> snapshot-create' without --disk-only, which can take seconds or even
> minutes where the guest is paused.
>
> Since Peter posted his series after the 1.0.0 freeze, I'm not quite sure
> whether we will take his patches this late in the release cycle, or if
> it will be another month (and 1.0.1) before they are available.
>
> You may also be interested in qemu 1.3 adding the 'drive-mirror'
> command, which allows for taking a copy of a disk ('virsh blockcopy')
> without affecting the backing chain in the first place.
>
>> The script I'm using makes a (full) snapshot of a VM, restore its state,
>> copies (with qemu-img convert) the snapshot out of the qcow file and
>> removes the snapshot.
> So you want to convert back to raw?  'blockpull' can't do that, but
> 'blockcommit' (if it gains support for committing the active layer) and
> 'blockcopy' will be able to do so.
>
> Oh, and if you want an early preview of 'blockcopy', check out RHEV 3.0,
> where the qemu-kvm and libvirt versions as patched by Red Hat have
> already been using an early backport of the blockcopy code for several
> months now.
>
>
>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20121025/bb999782/attachment.htm>