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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list