Bug 988436
Summary: | qemu: internal snapshots are slow after the first one | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Zbigniew Jędrzejewski-Szmek <zbyszek> | ||||
Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 20 | CC: | amit.shah, berrange, cfergeau, clalancette, crobinso, dallan, dwmw2, eblake, itamar, jforbes, jyang, kchamart, laine, libvirt-maint, pbonzini, rjones, scottt.tw, veillard, virt-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | qemu-1.6.0-10.fc20 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-10-15 06:36:15 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: | |||||||
Attachments: |
|
Description
Zbigniew Jędrzejewski-Szmek
2013-07-25 15:19:28 UTC
This behavior looks like it's controlled by qemu, so I'm changing the component. Internal snapshots are known to be slow; upstream qemu is working on adding new ways to do snapshots so that internal snapshots are no longer a bottleneck. However, if you want fast snapshots, I _highly_ recommend using external snapshots instead of internal, as those are lightning fast in comparison, and you don't have to wait for a new qemu. Thank you for the quick answers.
> However, if you want fast snapshots, I _highly_ recommend using external
> snapshots instead of internal, as those are lightning fast in comparison
I thought that external snapshots cannot be used as --disk-only only. I need to keep the whole memory state.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > I thought that external snapshots cannot be used as --disk-only only. I need > to keep the whole memory state. Saving memory state has been possible in external snapshots since libvirt 1.0.1. Yes, I recently did a small test. Where even the memory state is also captured with external snapshots. Here is the info: External system checkpoint snapshot: Guest's disk-state will be saved in one file, its RAM & device-state will be saved in another file. Version Info ============ $ uname -r ; rpm -q qemu-kvm libvirt libguestfs 3.9.4-301.fc19.x86_64 qemu-kvm-1.5.0-4.fc19.x86_64 libvirt-1.0.5.1-1.fc19.x86_64 libguestfs-1.21.38-1.fc19.x86_64 Snapshot creation ================= 1/ Start the guest: $ virsh start fed18 Domain fed18 started 2/ List its block device in use: $ virsh domblklist fed18 Target Source ------------------------------------------------ vda /var/lib/libvirt/images/fed18.qcow2 3/ Make an XML file for snapshot: $ cat /var/tmp/ext-disk-ram-snap.xml <domainsnapshot> <memory snapshot='external' file='/var/lib/libvirt/images/fed18.mem.snap2'/> <disks> <disk name='vda'> <source file='/var/lib/libvirt/images/fed18.disk.snap2'/> </disk> </disks> </domainsnapshot> 4/ Create snapshot (disk & memory state) w/ the the above XML file of the running guest: $ virsh snapshot-create fed18 \ --xmlfile /var/tmp/ext-disk-ram-snap.xml --atomic Domain snapshot 1370930820 created from '/var/tmp/ext-disk-ram-snap.xml' 5/ List the snapshots: $ virsh snapshot-list fed18 Name Creation Time State ------------------------------------------------------------ 1370930820 2013-06-11 11:37:00 +0530 running 6/ Again, list the block device in use (note - the disk image file in use is the new qcow2 file we specified in the snapshot XML above): $ virsh domblklist fed18 Target Source ------------------------------------------------ vda /var/lib/libvirt/images/fed18.disk.snap2 7/ Find more information about the disk image (it can be seen, qcow2 overlays are being used): $ qemu-img info --backing-chain /var/lib/libvirt/images/fed18.disk.snap2 image: /var/lib/libvirt/images/fed18.disk.snap2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: /var/lib/libvirt/images/fed18.qcow2 backing file format: qcow2 image: /var/lib/libvirt/images/fed18.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 1.0G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 1370847718 0 2013-06-10 12:31:58 00:00:00.000 8/ List both files which has the snapshotted data: $ file /var/lib/libvirt/images/fed18.mem.snap2 \ /var/lib/libvirt/images/fed18.disk.snap2 /var/lib/libvirt/images/fed18.mem.snap2: data /var/lib/libvirt/images/fed18.disk.snap2: QEMU QCOW Image (v2), has backing file (path /var/lib/libvirt/images/fed18.qcow2), 21474836480 bytes Eric, Kashyap, thanks. Indeed, external snapshotting is super fast, and restoring is fast too. But I have a problem when I try to make a subsequent snapshots: when I make a second snapshot, everything seems to work, but snapshot-revert restores the *first* snapshot, completely ignoring the second one, to which it was told to revert. I created a new ext-disk-ram-snap.xml with modified paths: <domainsnapshot> <memory snapshot='external' file='/var/lib/libvirt/images/fedoratestday64.mem.snap4'/> <disks> <disk name='vda'> <source file='/var/lib/libvirt/images/fedoratestday64.disk.snap4'/> </disk> </disks> </domainsnapshot> and created the snapshot virsh$ snapshot-create fedoratestday64 --xmlfile /var/tmp/ext-disk-ram-snap.xml --atomic and restored the vm to it: virsh$ snapshot-revert fedoratestday <snapshot2> and it returns me to <snapshot1>. Looking at the xml of snapshot2: <domainsnapshot> <name>1374774685</name> <state>running</state> <parent> <name>1374774274</name> </parent> <creationTime>1374774685</creationTime> <memory snapshot='external' file='/var/lib/libvirt/images/fedoratestday64.mem.snap4'/> <disks> <disk name='vda' snapshot='external'> <driver type='qcow2'/> <source file='/var/lib/libvirt/images/fedoratestday64.disk.snap4'/> </disk> <disk name='hdc' snapshot='no'/> </disks> <domain type='kvm'> <name>fedoratestday64</name> <uuid>f1441071-9f40-68fc-13da-3f8355cbfc7b</uuid> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu placement='static'>2</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-1.4'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/fedoratestday64.disk.snap2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/home/zbyszek/images/testday-20130530-x86_64.iso'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <controller type='usb' index='0'/> <controller type='pci' index='0' model='pci-root'/> <interface type='network'> <mac address='52:54:00:85:40:50'/> <source network='default'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <graphics type='spice' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> </graphics> <sound model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='qxl' ram='65536' vram='65536' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </memballoon> </devices> <seclabel type='dynamic' model='selinux' relabel='yes'/> </domain> </domainsnapshot> Both /var/lib/libvirt/images/fedoratestday64.disk.snap2 and /var/lib/libvirt/images/fedoratestday64.disk.snap4 are there, and .snap4 is in the wrong place? Reverting to external snapshots is still under development in libvirt (see for example bug 987719); if you are trying to revert to an external snapshot, please ask on the libvirt-users list for steps to take to do the manual pieces that are not yet in place in libvirt proper. Unfortunately, bug 987719 isn't public, but the gist of the bug summary is "support deletion of external snapshots". Eric, is there anywhere on the libvirt.org wiki with the manual steps? Should this be moved to the libvirt upstream product then? (In reply to Paolo Bonzini from comment #9) > Should this be moved to the libvirt upstream product then? Libvirt already has bugs tracking the need to implement snapshot-delete/revert for external snapshots, which is a secondary issue. This bug's primary issue is still about the slowness of qemu's internal snapshots, some of which may be addressed by pending upstream work for qemu 1.6 (or maybe 1.7, as we have already entered soft freeze for 1.6). I've retitled the bug accordingly. (In reply to Dave Allan from comment #8) > Unfortunately, bug 987719 isn't public, but the gist of the bug summary is > "support deletion of external snapshots". Eric, is there anywhere on the > libvirt.org wiki with the manual steps? I'll double check that (which probably means adding such a page), and post a URL back when I'm happy with the result. I've started a wiki page; I still need to work on it more, but as it is a wiki, hopefully it will be something we can make more useful. http://wiki.libvirt.org/page/I_created_an_external_snapshot%2C_but_libvirt_won%27t_let_me_delete_or_revert_to_it To avoid any scary backports let's just track this against F20, that's where we have the virt-manager support as well. F20/qemu 1.6 is much better here, but there's apparently an issue with slowness after the first internal snapshot. Patch here: https://lists.gnu.org/archive/html/qemu-devel/2013-09/msg02353.html qemu-1.6.0-9.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qemu-1.6.0-9.fc20 Package qemu-1.6.0-9.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qemu-1.6.0-9.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18471/qemu-1.6.0-9.fc20 then log in and leave karma (feedback). qemu-1.6.0-10.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qemu-1.6.0-10.fc20 qemu-1.6.0-10.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |