[libvirt] with latest libvirt(from git) on F18, time to take internal snapshot increases as snapshot count rises

Eric Blake eblake at redhat.com
Fri Oct 5 17:14:33 UTC 2012


On 10/05/2012 11:00 AM, Kashyap Chamarthy wrote:
> On 10/05/2012 08:07 PM, Eric Blake wrote:
>> On 10/05/2012 07:09 AM, Kashyap Chamarthy wrote:
>>>
>>> Hi,
>>>
>>> the below three internal snapshots were taken when the guest is running 'live'. Any hints
>>> on why the time to take snapshots keep increasing ?
>>
>> That's a question for qemu folks, as it is a problem in qemu's 'savevm'
>> command and nothing that libvirt can do about it.  Which is part of the
>> reason that I'd really like to move away from 'savevm' over to external
>> snapshots, as those are more deterministic in time.
> 
> I see, so the intention is to move away from 'savevm' over to external snapshots --
> Meaning, internal snapshots(both online/offline), where everything is in a single qcow2
> file are not much desired ? or am I misunderstanding it?

Internal snapshots:
pro - single file holds everything, so move that file, and you've moved
the snapshot
con - qemu doesn't test it very much, and it shows, with poor performance
con - the guest is paused for seconds or even minutes while taking the
snapshot
con - there is no way to access the data at the time of the snapshot
while qemu is running (although this feature has been requested of qemu,
no one has yet indicated that they plan to implement it any time soon)

External snapshots:
pro - you can do read-only operations on the data at the time of the
snapshot even while qemu continues to run
pro - currently very well tested, and qemu continues to enhance what is
supported
pro - the guest is paused for less than a second while taking the snapshot
con - you now have multiple files to track, so tasks like reverting and
cloning become more difficult to conceptually manage (but even here,
libvirt is trying to add code to eventually get to the point where we
can guarantee that any commit, pull, revert, or other snapshot operation
on one file managed by libvirt will be prevented if any other file would
be corrupted by the change, rather than the current state of things of
letting you shoot yourself in the foot)

Both are useful, and the end goal is to have libvirt expose both options
as well as document some of the tradeoffs so that you can use the method
best suited for your needs.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121005/4c3a3a14/attachment-0001.sig>


More information about the libvir-list mailing list