[libvirt] with latest libvirt(from git) on F18, time to take internal snapshot increases as snapshot count rises
8:09 a.m.
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
9:37 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
noon
On 10/05/2012 08:07 PM, Eric Blake wrote:
--
/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.
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?
12:14 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
1:27 p.m.
On 10/05/2012 10:44 PM, Eric Blake wrote:
--
/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.
Thanks for the detail, in your usual lucid style, Eric.
4432
days inactive
4432
days old
4 comments
2 participants
participants (2)
-
Eric Blake -
Kashyap Chamarthy