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

[Kashyap Chamarthy]

On 10/05/2012 10:44 PM, Eric Blake wrote:
> 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.

Thanks for the detail, in your usual lucid style, Eric.

> 


-- 
/kashyap