> 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 :-( -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1123975 Title: QEmu 1.3.90 cannot restore a 1.1.2 live snapshot Status in QEMU: New Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1123975/+subscriptions
