Bug 842557 - libvirt doesn't check ABI compatibility of watchdog and channel fully
libvirt doesn't check ABI compatibility of watchdog and channel fully
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.4
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Jiri Denemark
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-24 04:22 EDT by Luwen Su
Modified: 2013-02-21 02:19 EST (History)
8 users (show)

See Also:
Fixed In Version: libvirt-0.10.0-0rc1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 02:19:34 EST
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)

  None (edit)
Description Luwen Su 2012-07-24 04:22:23 EDT
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 Berrange 2012-07-24 04:42:49 EDT
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 15:18:47 EDT
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 15:40:38 EDT
This is now fixed upstream by v0.10.0-rc0-151-gd413464:

commit d4134642295210b00fe79adacbe10e86961e88a7
Author: Jiri Denemark <jdenemar@redhat.com>
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 03:24:30 EDT
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@10.66.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 08:55:59 EDT
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 01:46:38 EDT
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@10.66.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 02:19:34 EST
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.