Bug 830900 - Unable to restore saved VM after upgrade from F16 to F17
Unable to restore saved VM after upgrade from F16 to F17
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
Depends On:
Blocks: 857126
  Show dependency treegraph
Reported: 2012-06-11 11:24 EDT by Darryl L. Pierce
Modified: 2015-06-21 20:07 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 857126 (view as bug list)
Last Closed: 2013-04-01 08:23:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Darryl L. Pierce 2012-06-11 11:24:03 EDT
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

How reproducible:

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 -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
Comment 1 Paolo Bonzini 2012-09-11 06:23:30 EDT
Can you find what version you had for QEMU in F16?
Comment 2 Cole Robinson 2013-02-20 20:20:23 EST
Since I've been looking at other migration issues, I looked into this too.

This patch in f16 is the culprit:


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.
Comment 3 Paolo Bonzini 2013-02-22 05:37:31 EST
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?).
Comment 4 Cole Robinson 2013-02-22 12:53:11 EST
(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.
Comment 5 Cole Robinson 2013-04-01 08:23:21 EDT
No extra response for a month, closing as suggested in Comment #3.

Note You need to log in before you can comment on or make changes to this bug.