diff options
Diffstat (limited to 'results/classifier/118/none/1123975')
| -rw-r--r-- | results/classifier/118/none/1123975 | 114 |
1 files changed, 114 insertions, 0 deletions
diff --git a/results/classifier/118/none/1123975 b/results/classifier/118/none/1123975 new file mode 100644 index 000000000..4360ae501 --- /dev/null +++ b/results/classifier/118/none/1123975 @@ -0,0 +1,114 @@ +risc-v: 0.400 +user-level: 0.388 +peripherals: 0.379 +mistranslation: 0.373 +permissions: 0.366 +assembly: 0.362 +debug: 0.342 +semantic: 0.341 +graphic: 0.341 +hypervisor: 0.305 +x86: 0.293 +ppc: 0.290 +virtual: 0.289 +register: 0.284 +arm: 0.271 +TCG: 0.270 +device: 0.268 +KVM: 0.243 +PID: 0.237 +socket: 0.237 +architecture: 0.236 +VMM: 0.224 +performance: 0.213 +network: 0.193 +vnc: 0.192 +boot: 0.184 +files: 0.171 +kernel: 0.152 +i386: 0.096 + +QEmu 1.3+ cannot restore a 1.1- live snapshot made in qemu-kvm + +I have upgraded to QEmu 1.3.90 (Debian 1.4.0~rc0+dfsg-1exp) but now when I try to restore a live snapshot made in QEmu 1.1.2 (Debian 1.1.2+dfsg-5) I get the following message: + +virsh # snapshot-revert fgtbbuild wtb +error: operation failed: Error -22 while loading VM state + +I have test VMs with live snapshots coreresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu. + + +ipxe-qemu 1.0.0+git-20120202.f6840ba-3 +qemu 1.4.0~rc0+dfsg-1exp +qemu-keymaps 1.4.0~rc0+dfsg-1exp +qemu-kvm 1.4.0~rc0+dfsg-1exp +qemu-system 1.4.0~rc0+dfsg-1exp +qemu-system-arm 1.4.0~rc0+dfsg-1exp +qemu-system-common 1.4.0~rc0+dfsg-1exp +qemu-system-mips 1.4.0~rc0+dfsg-1exp +qemu-system-misc 1.4.0~rc0+dfsg-1exp +qemu-system-ppc 1.4.0~rc0+dfsg-1exp +qemu-system-sparc 1.4.0~rc0+dfsg-1exp +qemu-system-x86 1.4.0~rc0+dfsg-1exp +qemu-user 1.4.0~rc0+dfsg-1exp +qemu-utils 1.4.0~rc0+dfsg-1exp +libvirt-bin 1.0.2-1 +libvirt-dev 1.0.2-1 +libvirt-doc 1.0.2-1 +libvirt-glib-1.0-0 0.1.2-1 +libvirt0 1.0.2-1 +libvirtodbc0 6.1.4+dfsg1-5 + +This sounds pretty much like a prob with video ram size. In 1.1.x, we had video ram of 8Mb, in 1.3 it is 16Mb... should this be a problem, to come from smaller to larger size? + +Besides that, debian uses almost unmodified qemu, so the same prob should exist for upstream qemu too. + +But at any rate, I never recommended any sort of cross-version migration as in practice, despite countless efforts spent to make it to work, it almost always does NOT work. + +Thanks, + +/mjt + +And one more thing -- from what to what are you trying to migrate? I see you have qemu-kvm installed too, -- were you using it previously? Note that qemu-kvm 1.1 had the same video ram size = 16Mb as current qemu have. But my cross-version migration comment stays and in this case it becomes even stronger. + +> And one more thing -- from what to what are you trying to migrate? + +I believe kvm is being used in both cases, though the command is different with QEmu 1.3.90. I have redone tests where I kept libvirt set to 1.0.2 and only switched between QEmu 1.1.2 and 1.3.90 to minimize the changes. So here the only difference is 'apt-get install -t experimental qemu'. + +Here is what 'ps aux' shows me: + +libvirt 1.0.2-2 + QEmu 1.1.2 + +127 12841 92.7 4.6 1078272 189128 ? Sl 00:45 10:46 /usr/bin/kvm -name fgtbwinxp -S -M pc-1.1 -cpu Penryn,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 768 -smp 2,sockets=2,cores=1,threads=1 -uuid e624f2c9-80fd-26c7-a38a-0f0e49b6b719 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbwinxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbwinxp.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c7:0e:97,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 vmware -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -loadvm wtb + +With libvirt 1.0.2-2 + QEmu 1.3.90 +127 18709 39.7 0.8 1075732 35304 ? Sl 01:39 0:05 qemu-system-x86_64 -machine accel=kvm:tcg -name fgtbwinxp -S -M pc-1.1 -cpu Penryn,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 768 -smp 2,sockets=2,cores=1,threads=1 -uuid e624f2c9-80fd-26c7-a38a-0f0e49b6b719 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbwinxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbwinxp.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c7:0e:97,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 vmware -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -loadvm wtb + + +There's a wrinkle I missed in my original report: the behavior is different depending on whether the VM is already running or not. + +$ virsh --connect qemu:///system destroy fgtbwinxp +$ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb;echo $? +0 +# This command looks like it succeeds but in fact I see the VM booting Windows. So either the live state was not restored at all or it crashed before virt-viewer could connect. +$ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb;echo $? +error: operation failed: Error -22 while loading VM state +1 + + +> But at any rate, I never recommended any sort of cross-version migration +> as in practice, despite countless efforts spent to make it to work, it +> almost always does NOT work. + +Ouch. I expect to end up with about 50 live snapshots. It would be pretty annoying to have to redo all of them every time I upgrade QEmu / KVM :-( + +Ok, so this is migration from qemu-kvm 1.1 to qemu 1.3. This officially does not work because the two uses different memory layout. + +There is a way to make this work from old qemu-kvm to new qemu, by patching new qemu, but this introduces incompatibilities in other areas. + +Hopefully there will be no more "major" transitions like this in the future (I mean from qemu-kvm to qemu), so there's a chance that snapshots made with 1.3 and up will be forward-compatible. + +While this bugreport is filed with debian versions in mind, we in debian especially did not apply any changes to upstream qemu in this area, -- as history shows, any attempt to "fix" this "downstream" only makes things worse. + +I think we can close this ticket nowdays - as Michael mentioned in comment #4, migration between qemu-kvm and qemu was not supported, and the mentioned versions are pretty much outdated now anyway. + |