Bug 520850

Summary: funny error message on detaching nonexistent device
Product: Red Hat Enterprise Linux 5 Reporter: Paolo Bonzini <pbonzini>
Component: xenAssignee: Michal Novotny <minovotn>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: areis, berrange, leiwang, llim, minovotn, virt-maint, xen-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: xen-3.0.3-114.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 22:18:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 514498    
Attachments:
Description Flags
Patch to fix error message when trying to detach non-existing device
none
New version of the patch none

Description Paolo Bonzini 2009-09-02 16:17:44 UTC
Description of problem:
xen gives an interesting error message for a very simple user mistake.

Version-Release number of selected component (if applicable):
xen-3.0.3-94.el5

How reproducible:
Very.

Steps to Reproduce:
1. Start a domain
2. xm block-detach DOM-NAME xvdX (where xvdX is not a valid block device name for the domain).
3. Read error message and scratch your head.
  
Actual results:
"Error: invalid literal for int(): xvdv"

Expected results:
"error: No found disk whose target is xvdv" is what virsh says, for example

Comment 2 Michal Novotny 2010-03-22 13:21:45 UTC
(In reply to comment #0)
> Description of problem:
> xen gives an interesting error message for a very simple user mistake.
> 
> Version-Release number of selected component (if applicable):
> xen-3.0.3-94.el5
> 
> How reproducible:
> Very.
> 
> Steps to Reproduce:
> 1. Start a domain
> 2. xm block-detach DOM-NAME xvdX (where xvdX is not a valid block device name
> for the domain).
> 3. Read error message and scratch your head.
> 
> Actual results:
> "Error: invalid literal for int(): xvdv"
> 
> Expected results:
> "error: No found disk whose target is xvdv" is what virsh says, for example    

I think the component of this is libvirt (virsh is a part of libvirt) so changing the component. There is no such a message in xen daemon :)

Michal

Comment 3 Daniel Berrangé 2010-03-22 13:29:12 UTC
> 2. xm block-detach DOM-NAME xvdX (where xvdX is not a valid block device name
> for the domain).

This is not a libvirt command. The error message must be coming from xm or XenD.

Comment 4 Michal Novotny 2010-03-22 13:36:33 UTC
(In reply to comment #3)
> > 2. xm block-detach DOM-NAME xvdX (where xvdX is not a valid block device name
> > for the domain).
> 
> This is not a libvirt command. The error message must be coming from xm or
> XenD.    

Oh, but as far as I know, virsh does belong to libvirt, right? Also, there is no such message in the xen code. Also, when I am doing `git grep` to the libvirt git tree, it returns:

libvirt$ git grep "disk whose target"
po/af.po:msgid "No found disk whose target is %s"
po/am.po:msgid "No found disk whose target is %s"
po/ar.po:msgid "No found disk whose target is %s"
po/as.po:msgid "No found disk whose target is %s"
po/be.po:msgid "No found disk whose target is %s"
po/bg.po:msgid "No found disk whose target is %s"
po/bn.po:msgid "No found disk whose target is %s"
po/bn_IN.po:msgid "No found disk whose target is %s"
po/bs.po:msgid "No found disk whose target is %s"
po/ca.po:msgid "No found disk whose target is %s"
po/cs.po:msgid "No found disk whose target is %s"
po/cy.po:msgid "No found disk whose target is %s"
po/da.po:msgid "No found disk whose target is %s"
po/de.po:msgid "No found disk whose target is %s"
po/el.po:msgid "No found disk whose target is %s"
po/en_GB.po:msgid "No found disk whose target is %s"
po/es.po:msgid "No found disk whose target is %s"
po/et.po:msgid "No found disk whose target is %s"
po/eu_ES.po:msgid "No found disk whose target is %s"
po/fa.po:msgid "No found disk whose target is %s"
po/fi.po:msgid "No found disk whose target is %s"
po/fr.po:msgid "No found disk whose target is %s"
po/gl.po:msgid "No found disk whose target is %s"
po/gu.po:msgid "No found disk whose target is %s"
po/he.po:msgid "No found disk whose target is %s"
po/hi.po:msgid "No found disk whose target is %s"
po/hr.po:msgid "No found disk whose target is %s"
po/hu.po:msgid "No found disk whose target is %s"
po/hy.po:msgid "No found disk whose target is %s"
po/id.po:msgid "No found disk whose target is %s"

And since the bug is about the message, this should be in libvirt. Or am I wrong?

Michal

Comment 5 Michal Novotny 2010-03-22 13:38:39 UTC
(In reply to comment #3)
> > 2. xm block-detach DOM-NAME xvdX (where xvdX is not a valid block device name
> > for the domain).
> 
> This is not a libvirt command. The error message must be coming from xm or
> XenD.    

Oh, sorry, this is the expected result. I misread the "Expected results" and "Actual results", that way it's really xen component.

Sorry,
Michal

Comment 6 Michal Novotny 2010-06-24 14:44:39 UTC
Created attachment 426602 [details]
Patch to fix error message when trying to detach non-existing device

This is the patch to fix error message when trying to detach a non-existing device from the guest. Technically it's adding one more check after trying to find appropriate integer value for device id to raise an exception when the device id is still string value.

Michal

Comment 7 Michal Novotny 2010-06-28 15:47:28 UTC
Created attachment 427447 [details]
New version of the patch

This is the new version with conversion to integer since it was failing to find appropriate device id in some circumstances (because the devid was of string type but containing the integer value).

Michal

Comment 13 errata-xmlrpc 2011-01-13 22:18:53 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0031.html