Comment 3 for bug 1123975

> 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 :-(