Bug 720889 - libvirt does not report error when attach device with wrong xml
Summary: libvirt does not report error when attach device with wrong xml
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Osier Yang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-13 06:53 UTC by weizhang
Modified: 2011-12-06 11:16 UTC (History)
6 users (show)

Fixed In Version: libvirt-0.9.4-rc1-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 11:16:26 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

Description weizhang 2011-07-13 06:53:55 UTC
Description of problem:
when do disk hotplug with command attach-device, if give the wrong disk.xml content, libvirt doesn't report error, although the disk is not attached to the guest

cat disk.xml
    <disk type='ttt' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/tt.img'/>
      <target dev='vdc' bus='virtio'/>
    </disk>

virsh attach-device domain disk.xml
Device attached successfully

it is a regression bug, because when I test on libvirt-0.8.7-18.el6.x86_64, it will report error like
error: Failed to attach device from disk.xml
error: internal error unknown disk type 'ttt'

Version-Release number of selected component (if applicable):
libvirt-0.9.3-2.el6.x86_64
qemu-kvm-0.12.1.2-2.169.el6.x86_64
kernel-2.6.32-166.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. start a guest
2. qemu-img create tt.img 10M 
3. cat disk.xml
    <disk type='ttt' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/tt.img'/>
      <target dev='vdc' bus='virtio'/>
    </disk>
4. virsh attach-device guest disk.xml

Actual results:
Device attached successfully

Expected results:
error: Failed to attach device from disk.xml
error: internal error unknown disk type 'ttt'

Additional info:

Comment 3 Osier Yang 2011-07-13 14:44:33 UTC
patch posted to upstream, https://www.redhat.com/archives/libvir-list/2011-July/msg00745.html

Comment 4 Osier Yang 2011-07-16 03:32:05 UTC
commit fab4f0c699d3f0b330060aa3fb2743c6696271de
Author: Osier Yang <jyang>
Date:   Sat Jul 16 11:24:49 2011 +0800
   
    qemu: Fix a regression of attaching device
    
    The regression is introduced by Commit da1eba6b, the new
    codes with this commit doesn't reset "ret" to "-1" when
    codes with this commit doesn't reset "ret" to "-1" when
    it fails on parsing the device XML (live device attachment)
    
    This patch changes the codes to reset the "ret" and "-1",
    and also changes the codes so that it don't modify "ret"
    for condition checking.
    
    How to reproduce:
    
    % cat test.xml
    <disk type='oops' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    
    % virsh attach-device $domain test.xml
    Device attached successfully
    
    The device attachment failed actually with error "unknown disk type 'oops'",
    however, it reports success.

Patch is in upstream, move to POST.

Comment 7 yanbing du 2011-08-01 09:09:46 UTC
Test this bug on libvirt-0.9.4-0rc2.el6, verified.
libvirt-0.9.4-0rc2.el6
qemu-kvm-0.12.1.2-2.172.el6
kernel-2.6.32-171.el6
when attach device use the wrong disk type(such as 'ttt'), get error message.
#virsh attach-device test disk.xml
error: Failed to attach device from disk.xml
error: internal error unknown disk type 'ttt'

Comment 8 errata-xmlrpc 2011-12-06 11:16:26 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/RHBA-2011-1513.html


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