Red Hat Bugzilla – Bug 618205
SPICE - race in KVM/Spice would cause migration to fail (slots are not registered properly?)
Last modified: 2013-01-10 22:09:17 EST
This bug has been copied from bug #567046 and has been proposed to be backported to 5.5 z-stream (EUS).
Reproduce this problem with kvm-83-164.el5_5.12, do migration immediately after "system_reset", got 3 failed results: 1. (qemu) Error while reading ram block header Error block header 2. (qemu) load of migration failed 3. (qemu) ram_save_block: update dirty pages log failed -2 ram_save_block: update dirty pages log failed -2 ram_save_block: update dirty pages log failed -2 ram_save_block: update dirty pages log failed -2 steps: 1. start source guest with spice: # /usr/libexec/qemu-kvm -m 1G -smp 2 -cpu qemu64,+sse2 -monitor stdio -drive file=/root/rhel5.5-64-virtio.qcow2,if=virtio,boot=on,cache=none -net nic,macaddr=20:20:20:12:23:16,model=virtio,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -usbdevice tablet -spice host=0,ic=on,port=5930,disable-ticketing -qxl 1 2. start destination: <qemu-kvm commandline> -incoming tcp:0:5888 3. in src qemu monitor, do migration immediately after system_reset: (qemu) system_reset (qemu) qxl_display_resize qxl_reset handle_dev_input: detach handle_dev_input: attach create_cairo_context: using cairo canvas vdi_port_io_map: base 0xc040 size 0x10 vdi_port_ram_map: addr 0xc1000000 size 0x10000 ram_map: addr 0xc4000000 size 0x4000000 vram_map: addr 0xc8000000 size 0x1000 rom_map: addr 0xc8002000 size 0x2000 ioport_map: base 0xc050 size 0x8 (qemu) migrate -d tcp:ip:5888 Tested with kvm-83-164.el5_5.20 using the above 3 steps and do ping-pong migration for 10 times, all migrations completed successfully, so this bug has been fixed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the migration process would fail for a virtual machine because the virtual machine could not map all the memory. This was caused by a conflict that was initiated when a virtual machine was initially run and then migrated right away. With this update, the conflict no longer occurs and the migration process no longer fails.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0627.html