Bug 520850 - funny error message on detaching nonexistent device
Summary: funny error message on detaching nonexistent device
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen
Version: 5.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Michal Novotny
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 514498
TreeView+ depends on / blocked
 
Reported: 2009-09-02 16:17 UTC by Paolo Bonzini
Modified: 2014-02-02 22:37 UTC (History)
7 users (show)

Fixed In Version: xen-3.0.3-114.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-13 22:18:53 UTC


Attachments (Terms of Use)
Patch to fix error message when trying to detach non-existing device (1.64 KB, patch)
2010-06-24 14:44 UTC, Michal Novotny
no flags Details | Diff
New version of the patch (2.23 KB, patch)
2010-06-28 15:47 UTC, Michal Novotny
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0031 normal SHIPPED_LIVE xen bug fix and enhancement update 2011-01-12 15:59:24 UTC

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


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