RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1208808 - creating second and further snapshot takes ages
Summary: creating second and further snapshot takes ages
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.2
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: 7.2
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-03 09:06 UTC by Vladimir Benes
Modified: 2015-11-19 05:00 UTC (History)
11 users (show)

Fixed In Version: qemu-kvm-1.5.3-90.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 05:00:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2213 0 normal SHIPPED_LIVE qemu-kvm bug fix and enhancement update 2015-11-19 08:16:10 UTC

Description Vladimir Benes 2015-04-03 09:06:49 UTC 
Description of problem:
first snapshot is created in seconds but when I try to create second and third it takes something like 2 minutes. It is finally created correctly, you can revert to it, delete, rename. The only thing is that it takes very long time.

Version-Release number of selected component (if applicable):
gnome-boxes-3.14.3.1-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.create a vm
2.create snapshot
3.create another snapshot

Actual results:
it takes soooo long

Expected results:
should be quick as the first one

Additional info:
Comment 2 Zeeshan Ali 2015-04-15 13:31:12 UTC 
Could you please check if you can reproduce this outside Boxes (e.g virt-manager or virsh)?
Comment 3 Vladimir Benes 2015-04-22 13:57:17 UTC 
yes, i can, moving to libvirt then?
Comment 4 Vladimir Benes 2015-04-22 14:06:40 UTC 
in small live OS it takes something like 5s and 20s

but in Fedora 22 it takes 20s and somehow ~5minutes
Comment 5 Zeeshan Ali 2015-05-05 17:24:11 UTC 
(In reply to Vladimir Benes from comment #3)
> yes, i can, moving to libvirt then?

Indeed! Thanks for testing that.
Comment 6 Eric Blake 2015-05-06 12:52:14 UTC 
Slow internal snapshots are caused by qemu, not libvirt.  It has been reported in the past.  One workaround is to use external snapshots instead of internal.
Comment 7 Eric Blake 2015-05-08 19:38:33 UTC 
See also bug 1219908 for a RHEL 6 counterpart
Comment 8 Ademar Reis 2015-05-12 14:42:11 UTC 
Vladimir, you've marked this a Regression. Can you tell me in which version it works? Thanks.
Comment 9 Kevin Wolf 2015-05-29 13:28:19 UTC 
Something to consider here is upstream commit 1ebf561c. ('qcow2: Discard VM
state in active L1 after creating snapshot')
Comment 10 Ademar Reis 2015-05-29 13:37:12 UTC 
(In reply to Ademar Reis from comment #8)
> Vladimir, you've marked this a Regression. Can you tell me in which version
> it works? Thanks.

Removing regression keyword, as we see no reason for it to be one.

Vladimir: I'm keeping the NEEDINFO, please let us know if you still consider this a regression. Thanks.
Comment 11 Vladimir Benes 2015-06-01 07:39:37 UTC 
no more regression and blocker. we have workaround to use in gnome-boxes too.
Comment 12 Kevin Wolf 2015-06-01 08:41:23 UTC 
(In reply to Vladimir Benes from comment #11)
> no more regression and blocker.

Either it is a regression or it isn't. Being a regression "no more" doesn't make
sense, that's not something that changes. As you didn't mention an older version
in which it works, I suppose it's not a regression.

> we have workaround to use in gnome-boxes too.

I'm curious what kind of workaround you found (other than not using internal
snapshots at all).
Comment 13 Vladimir Benes 2015-06-01 08:47:09 UTC 
(In reply to Kevin Wolf from comment #12)
> (In reply to Vladimir Benes from comment #11)
> > no more regression and blocker.
> 
> Either it is a regression or it isn't. Being a regression "no more" doesn't
> make
> sense, that's not something that changes. As you didn't mention an older
> version
> in which it works, I suppose it's not a regression.
> 
I am looking into this issue from gnome-boxes point of view. As it was described as other package issue then no more regression mark needed.

> > we have workaround to use in gnome-boxes too.
> 
> I'm curious what kind of workaround you found (other than not using internal
> snapshots at all).

external snapshots? These were very likely used before so this issue wasn't seen.
Comment 14 Miroslav Rezanina 2015-06-04 06:32:49 UTC 
Fix included in qemu-kvm-1.5.3-90.el7
Comment 16 Vladimir Benes 2015-06-04 10:32:40 UTC 
It works well in Boxes now.
Comment 17 Shaolong Hu 2015-06-19 06:03:14 UTC 
This bug refers to "savevm" which saves guest status within snapshot image together with disk data, aka "internal snapshot", not the regular snapshot we usually mentioned, test with qemu-kvm-1.5.3-90.el7.x86_64:

# /usr/libexec/qemu-kvm -enable-kvm -M pc -smp 4 -m 4G -name rhel6.3-64 -uuid 3f2ea5cd-3d29-48ff-aab2-23df1b6ae213 -drive file=/root/nfs/RHEL-Server-7.2-64-virtio.qcow2,cache=none,if=none,rerror=stop,werror=stop,id=drive-virtio-disk0,format=qcow2,aio=native -device virtio-blk-pci,drive=drive-virtio-disk0,id=device-virtio-disk0,bootindex=1 -netdev tap,script=/etc/qemu-ifup,id=netdev0 -device virtio-net-pci,netdev=netdev0,id=device-net0,mac=aa:54:00:11:22:33 -boot order=cd -monitor stdio -usb -device usb-tablet,id=input0 -chardev socket,id=s1,path=/tmp/s1,server,nowait -device isa-serial,chardev=s1 -monitor tcp::1234,server,nowait -vga qxl -global qxl-vga.revision=3 -spice port=5920,disable-ticketing -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -vnc :10 -qmp tcp:0:5555,server,nowait
QEMU 1.5.3 monitor - type 'help' for more information
(qemu) 
(qemu) 
(qemu) 
(qemu) 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 
(qemu) savevm 

the 10th time savevm still takes less than 30s for a 4G mem guest.
Comment 19 errata-xmlrpc 2015-11-19 05:00:02 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2213.html
Note You need to log in before you can comment on or make changes to this bug.