[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt-users] Disk-only internal snapshot



First of all, I'd like to thank you all for the very detailed replies.

Even if I've learnt a lot today about libvirt snapshot features, I'm stuck because I'm currently using Ubuntu Precise which is very "conservative" about libvirt/qemu/kvm versions. :)

I'll soon create a new hypervisor for testing purpose and I'll experiment the features/patches you've pointed out.

Cheers,
 Davide. 


On 25/ott/2012, at 06:26, Kashyap Chamarthy <kchamart redhat com> wrote:

> On 10/25/2012 03:14 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?
>> 
>> 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).
> 
> 
> Just expanding on Eric's very lucid detail.
> 
> David, here's some examples I posted with 'blockcommit' & 'blockpull'(with QEMU git &
> Libvirt git as of 21st OCT) --
> 
> - http://kashyapc.fedorapeople.org/virt/blockcommit/recursive-blockcommit-base-raw.txt
> - http://kashyapc.fedorapeople.org/virt/blockpull/test-blockpull.txt
> 
> 
> Hope that helps.
> 
>> 
>>> 
>>> 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 redhat com
>> https://www.redhat.com/mailman/listinfo/libvirt-users
>> 
> 
> 
> -- 
> /kashyap



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]