RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 842557 - libvirt doesn't check ABI compatibility of watchdog and channel fully
Summary: libvirt doesn't check ABI compatibility of watchdog and channel fully
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-24 08:22 UTC by Luwen Su
Modified: 2013-02-21 07:19 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.10.0-0rc1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 07:19:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description Luwen Su 2012-07-24 08:22:23 UTC 
Description of problem:
libvirt doesn't check ABI compatibility of watchdog and channel fully.
There are shorting of checking <action> about watchdog and <channel type> elements

Version-Release number of selected component (if applicable):
libvirt 0.9.13-2

How reproducible:
always

Steps to Reproduce:
1.
Prepare One healthy guest. 
Setup envirment and make sure migrate between 2 host can succes

2.For watchdog
add watchdog to the guest , assume action is none <action='none' >
#virsh dumpxml guest > change.xml
edit change.xml , make action is 'reset' or others <action='reset' >

3.
#virsh start guest
#virsh migrate --live --xml guest change.xml qemu+ssh://x.x.x.x/system

Actual results:
The command will work and no error showed up, on the dest the action changed from 'none' to 'reset'
for <channel type> , change from 'spicevm' to 'pty' be possible.

Expected results:
There is a error message like "Target  %s does not match source %s".And the command won't succss

Additional info:
I checked the latest code , found in  virDomainConsoleDefCheckABIStability
there is src->model != dst->model , but no action check.
and in virDomainChannelDefCheckABIStability
there is src->targetType != dst->targetType , but no channel type check.
Comment 2 Daniel Berrangé 2012-07-24 08:42:49 UTC 
The watchdog action is a host-side configuration parameter, with no guest visible effect.

The channel type is also (primarily) a host-side configuration parameter, so in general also does not need to be checked for ABI compatibilty. The one edge case in this though, is that setting 'spicevmc', then implies a specific guest visible channel name. IIRC, this should already be validated by an ABI check against the channel name field though.
Comment 3 Jiri Denemark 2012-07-27 19:18:47 UTC 
I can confirm that virtio channel name is checkedin ABI compatibility, however, if target name is not explicitly specified, the guest visible name could change when channel type changes (spicevmc defaults to "com.redhat.spice.0" while other types default to numbered ports). I think we need a new spicevmc-specific check.
Comment 4 Jiri Denemark 2012-08-17 19:40:38 UTC 
This is now fixed upstream by v0.10.0-rc0-151-gd413464:

commit d4134642295210b00fe79adacbe10e86961e88a7
Author: Jiri Denemark <jdenemar>
Date:   Fri Aug 17 14:06:13 2012 +0200

    conf: Fix ABI stability check for spicevmc channel
    
    Change device type of a virtio channel from/to spicevmc is not a user
    visible change. However, spicevmc channels use different default target
    name than other virtio channels. To maintain ABI stability during this
    change target name must be explicitly specified (and equal) in both
    configurations.
Comment 6 yuping zhang 2012-08-24 07:24:30 UTC 
Tested this issue libvirt-0.10.0-0rc1.el6.x86_64.

Steps:
1.#virsh dumpxml  kvm-win7-i386
...  
   <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
...
2.# virsh dumpxml kvm-win7-i386 > kvm-win7-i386.xml
3.Change the channel type from spicevmc to pty 
# vim kvm-win7-i386.xml
...
  <channel type='pty'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
...
4.Migrate the guest.
#  virsh migrate --live --xml kvm-win7-i386.xml kvm-win7-i386 qemu+ssh://10.66.5.10/system
root.5.10's password: 
 
# echo $?
0

Migrate the guest successfully,still doesn't check the channel type.

So change the bug status to ASSIGNED.
Comment 7 Jiri Denemark 2012-08-24 12:55:59 UTC 
The two XMLs provide exactly the same guest environment (the guest will still see a virtio channel named 'com.redhat.spice.0') and thus migration is correctly allowed. See comments #2 and #3 for more details.
Comment 8 yuping zhang 2012-08-27 05:46:38 UTC 
Verified this issue with libvirt-0.10.0-0rc1.el6.x86_64.
1.#virsh dumpxml <guest>
...
  <channel type='pty'>
      <source path='/dev/pts/15'/>
      <target type='virtio'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
...

2.Virsh dumpxml guest xml,then edit xml like this:
#vim 
...
    <channel type='spicevmc'>
      <target type='virtio' />
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
...

3.Do migration.
# virsh migrate --live --xml kvm-win7-i386.xml kvm-win7-i386 qemu+ssh://10.66.5.10/system
root.5.10's password: 
error: unsupported configuration: Changing device type to/from spicevmc would change default target channel name

So change the bug status to VERIFIED.
Comment 9 errata-xmlrpc 2013-02-21 07:19:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html
Note You need to log in before you can comment on or make changes to this bug.