Bug 910711 - snapshot-revert causes spurious hardware mismatch errors
Summary: snapshot-revert causes spurious hardware mismatch errors
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt   
(Show other bugs)
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Krempa
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-13 11:14 UTC by Francois Gouget
Modified: 2013-09-16 12:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-16 12:04:57 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dumpxml done with libvirt 1.0.2 and QEmu 1.1.2 (3.52 KB, application/xml)
2013-02-17 00:22 UTC, Francois Gouget
no flags Details
dumpxml done with libvirt 1.0.2 and QEmu 1.3.90 (3.52 KB, application/xml)
2013-02-17 00:30 UTC, Francois Gouget
no flags Details

Description Francois Gouget 2013-02-13 11:14:12 UTC
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

Comment 1 Francois Gouget 2013-02-13 13:59:03 UTC
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

Comment 2 Eric Blake 2013-02-13 17:24:04 UTC
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.

Comment 3 Francois Gouget 2013-02-17 00:22:27 UTC
Created attachment 698342 [details]
dumpxml done with libvirt 1.0.2 and QEmu 1.1.2

Comment 4 Francois Gouget 2013-02-17 00:30:39 UTC
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

Comment 5 Peter Krempa 2013-09-16 12:04:57 UTC
This issue is now fixed upstream with:

commit 53c39f5837a6eed543465a7a55690786d0655ad0
Author: Peter Krempa <pkrempa@redhat.com>
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.


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