Description of problem: I have recently upgraded to libvirt 1.0.2 and QEmu 1.3.90 (Debian 1.4.0~rc0+dfsg-1exp) and now whenever I try to revert to a live snapshot I get spurious hardware mismatch errors telling me I have to use force to perform the revert. For instance: virsh # snapshot-create-as fgtbwinxp wtb1390 Domain snapshot wtb1390 created virsh # snapshot-revert fgtbwinxp wtb1390 error: revert requires force: Target controller type ide does not match source usb Note that the message varies a bit, sometimes I get 'Target controller type none does not match source pci' and possibly other variations. Also notice that in the above example the two snapshot commands were typed in sequence so the configuration did not change in between. How reproducible: This is systematic. Expected results: Reverting to a live snapshot should not report spurious hardware mismatches. This worked just fine with libvirt 0.9.12-6 and QEmu 1.1.2. Version-Release number of selected component (if applicable): 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
I have now retested this with a slightly modified configuration, specifically libvirt 1.0.2 and QEmu 1.1.2. Strangely enough I don't get the hardware mismatch errors. So to summarize: libvirt 0.9.12 and QEmu 1.1.2: No problem libvirt 1.0.2 and QEmu 1.1.2: No problem libvirt 1.0.2 and QEmu 1.3.90: Spurious errors So it seems the problem comes from QEmu 1.3.90 rather than libvirt. Does that make sense? Here are the new configuration details: ipxe-qemu 1.0.0+git-20120202.f6840ba-3 libvirt-bin 1.0.2-2 libvirt-doc 1.0.2-1 libvirt0 1.0.2-2 libvirtodbc0 6.1.4+dfsg1-5 python-libvirt 1.0.2-2 qemu 1.1.2+dfsg-5 qemu-keymaps 1.4.0~rc0+dfsg-1exp qemu-kvm 1.1.2+dfsg-5 qemu-system 1.1.2+dfsg-5 qemu-user 1.1.2+dfsg-5 qemu-utils 1.1.2+dfsg-5
Can you show 'virsh dumpxml' output for the running domain under libvirt 1.0.2 with both versions of qemu? I have to wonder if it has something to do with newer qemu enabling a feature that older qemu did not have, and where the new feature causes libvirt to rearrange controller objects when it should not be doing so.
Created attachment 698342 [details] dumpxml done with libvirt 1.0.2 and QEmu 1.1.2
Created attachment 698343 [details] dumpxml done with libvirt 1.0.2 and QEmu 1.3.90 Note that I cannot revert to a QEmu 1.1.2 snapshot with QEmu 1.3.90 (*) so this is from a different snapshot. Both were made from the same not-live snapsot by booting the VM and taking a live snapshot. So for the tests I did something like this: $ virsh --connect qemu:///system destroy fgtbwinxp $ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb # And again $ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb Replace wtb with wtb1390 for QEmu 1.3.90. The first snapshot-revert works fine in both cases. With QEmu 1.3.90 the second one claims it requires force. (*) See QEmu bug 1123975: https://bugs.launchpad.net/bugs/1123975
This issue is now fixed upstream with: commit 53c39f5837a6eed543465a7a55690786d0655ad0 Author: Peter Krempa <pkrempa> Date: Thu Sep 12 11:37:57 2013 +0200 qemu: Fix checking of guest ABI compatibility when reverting snapshots When reverting a live internal snapshot with a live guest the ABI compatiblity check was comparing a "migratable" definition with a normal one. This resulted in the check failing with: revert requires force: Target device address type none does not match source pci This patch generates a "migratable" definition from the actual one to check against the definition from the snapshot to avoid this problem. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1006886 Thanks for reporting it.