Bug 1208808
| Summary: | creating second and further snapshot takes ages | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vladimir Benes <vbenes> |
| Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.2 | CC: | eblake, hhuang, huding, juzhang, knoel, kwolf, rbalakri, vbenes, virt-maint, xfu, zeenix |
| Target Milestone: | rc | ||
| Target Release: | 7.2 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-1.5.3-90.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-19 05:00:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Vladimir Benes
2015-04-03 09:06:49 UTC
Could you please check if you can reproduce this outside Boxes (e.g virt-manager or virsh)? yes, i can, moving to libvirt then? in small live OS it takes something like 5s and 20s but in Fedora 22 it takes 20s and somehow ~5minutes (In reply to Vladimir Benes from comment #3) > yes, i can, moving to libvirt then? Indeed! Thanks for testing that. 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. See also bug 1219908 for a RHEL 6 counterpart Vladimir, you've marked this a Regression. Can you tell me in which version it works? Thanks. Something to consider here is upstream commit 1ebf561c. ('qcow2: Discard VM
state in active L1 after creating snapshot')
(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. no more regression and blocker. we have workaround to use in gnome-boxes too. (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). (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. Fix included in qemu-kvm-1.5.3-90.el7 It works well in Boxes now. 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. 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 |