[libvirt] with latest libvirt(from git) on F18, time to take internal snapshot increases as snapshot count rises
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 ? If you notice, the 2nd and 3rd internal snaphtots took more than 4 minutes each (note: there is no noticeable content change from snap1 ) #==================================================# [root@localhost vmimages]# time virsh snapshot-create-as f17vm3-with-b snap1 snap1-f17vm3-desc Domain snapshot snap1 created real 0m57.734s user 0m0.009s sys 0m0.024s [root@localhost vmimages]# [root@localhost vmimages]# virsh snapshot-list f17vm3-with-b Name Creation Time State ------------------------------------------------------------ snap1 2012-10-04 06:55:38 -0400 running [root@localhost vmimages]# #==================================================# [root@localhost vmimages]# time virsh snapshot-create-as f17vm3-with-b snap2 snap2-f17vm3-desc Domain snapshot snap2 created real 4m19.126s user 0m0.020s sys 0m0.030s [root@localhost vmimages]# #==================================================# [root@localhost vmimages]# time virsh snapshot-create-as f17vm3-with-b snap3 snap3-f17vm3-desc Domain snapshot snap3 created real 4m45.053s user 0m0.013s sys 0m0.032s [root@localhost vmimages]# #==================================================# [root@localhost qemu]# qemu-img info /home/kashyap/vmimages/f17vm3-with-b.qcow2 image: /home/kashyap/vmimages/f17vm3-with-b.qcow2 file format: qcow2 virtual size: 5.0G (5368709120 bytes) disk size: 755M cluster_size: 65536 backing file: /home/kashyap/vmimages/base-f17.qcow2 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 snap1 232M 2012-10-04 06:55:38 19:58:19.804 2 snap2 247M 2012-10-04 07:03:09 20:04:53.360 3 snap3 244M 2012-10-04 07:08:23 20:05:48.889 4 snap4 0 2012-10-04 08:51:16 00:00:00.000 5 snap5 0 2012-10-04 08:53:04 00:00:00.000 [root@localhost qemu]# #==================================================# [root@localhost qemu]# virsh snapshot-list f17vm3-with-b Name Creation Time State ------------------------------------------------------------ snap1 2012-10-04 06:55:38 -0400 running snap2 2012-10-04 07:03:08 -0400 running snap3 2012-10-04 07:08:23 -0400 running snap4 2012-10-04 08:51:16 -0400 shutoff snap5 2012-10-04 08:53:04 -0400 shutoff [root@localhost qemu]# #==================================================# -- /kashyap
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. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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?
-- /kashyap
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@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
participants (2)
-
Eric Blake -
Kashyap Chamarthy