Description of problem: I have a VM that was saved under F16 prior to upgrading to F17. After the upgrade, trying to restore the VM resulted in the constant error "Connection reset by peer". See below for the output from the log file for the VM. Version-Release number of selected component (if applicable): mcpierce@mcpierce-laptop:~ $ rpm -q qemu-kvm qemu-kvm-1.0-17.fc17.x86_64 How reproducible: 100% Steps to Reproduce: 1. Attempt to restart the saved VM. Actual results: An error message, and the VM fails to restore. Expected results: The VM to be restored. Additional info: I eventually had to kill the persisted state with "virsh managesave-remove Windows7" to make the VM restartable. 2012-06-11 15:02:11.920+0000: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name Windows7 -uuid dda2225d-0e57-8396-eff5-ad4da9d9febc -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/MeetManager.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=22,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:db:50:0d,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -incoming fd:20 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 Domain id=1 is tainted: high-privileges char device redirected to /dev/pts/11 do_spice_init: starting 0.10.1 spice_server_add_interface: SPICE_INTERFACE_QXL red_worker_main: begin display_channel_create: create display channel cursor_channel_create: create cursor channel pulseaudio: pa_context_connect() failed pulseaudio: Reason: Connection refused pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused file mcoputils.cc: line 499 (static std::string Arts::MCOPUtils::mcopDirectory()): assertion failed: (home != 0) sdl: SDL_OpenAudio failed sdl: Reason: No available audio device sdl: SDL_OpenAudio failed sdl: Reason: No available audio device audio: Failed to create voice `dac' audio: Failed to create voice `adc' qemu: warning: error while loading state for instance 0x0 of device '0000:00:02.0/qxl' load of migration failed 2012-06-11 15:02:32.936+0000: shutting down
Can you find what version you had for QEMU in F16?
Since I've been looking at other migration issues, I looked into this too. This patch in f16 is the culprit: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0022-qxl-bump-pci-rev.patch?h=f16 It's an upstream change that went in after 0.15 and was in the 1.0 release. But it messes with various migration properties. So F16 pc-0.14 (the default) is different from upstream pc-0.14. We could 'fix' this in F17+ by adding compat properties to pc-0.14 that match what F16 qxl is using, but then we deviate from upstream, and have the carry that patch for an indefinite amount of time. Which isn't that big of a deal, but then again since there hasn't been much noise about this, and F16 is EOL, I'm tempted to not even bother. If anyone else has strong opinions feel free to chime in. If nothing else I keep this bug open till F17 EOL for documentation purposes.
I think that now that it is analyzed, we should close it as WONTFIX. (Does it even happen with the latest F16 qemu, which is 0.15.1?).
(In reply to comment #3) > I think that now that it is analyzed, we should close it as WONTFIX. (Does > it even happen with the latest F16 qemu, which is 0.15.1?). Yes, all F16 versions are affected. I'd prefer to keep it open for a bit, since F16 has only been EOL for less than a month. There are plenty of people who I'm sure are still running it, and who will upgrade over the next few months. And really this could be called a F17/F18/rawhide 'bug' since the fix wouldn't have lived in F16 anyways. I don't anticipate many people complaining but I'm willing to see if there's more demand.
No extra response for a month, closing as suggested in Comment #3.