This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 217243 - xm block-attach does not give error messages when it fails to attach
xm block-attach does not give error messages when it fails to attach
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Glauber Costa
:
Depends On:
Blocks: 217853
  Show dependency treegraph
 
Reported: 2006-11-25 12:06 EST by Chris Lalancette
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-13 17:45:50 EST
Type: ---
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 Chris Lalancette 2006-11-25 12:06:32 EST
Description of problem:
When running xm block-attach, if the attach fails, proper error messages are not
returned to the user and the device is not un-set properly.  In particular, the
following sequence causes a problem:

1.  Start up RHEL-5 domU.
2.  In the domU, run "modprobe sd_mod"
3.  On the dom0, run "xm block-attach rhel5-file file://tmp/testblock.img
/dev/sda w"

The block-attach command will seemingly succeed.  However, in the domU, you will
see the following error messages:

Registering block device major 8
register_blkdev: cannot get major 8 for sd
xen_blk: can't get major 8 with name sd
vbd vbd-2160: 19 xlvbd_add at /local/domain/0/backend/vbd/1/2160

The fact that the block-attach fails is fine (after all, the scsi device is
already in use); the fact that it doesn't inform the user on dom0 is not. 
Additionally, on the dom0, "xm block-detach rhel5-file /dev/sda" will say:

Error: Device /dev/sda not connected
Usage: xm block-detach <Domain> <DevId>

Destroy a domain's virtual block device.

So there is no (easy) way to detach the broken block device.

I did a little bit of debugging on this.  On the domU side, when the "cannot get
major 8 with name sd" message is printed, it looks like the kernel correctly
writes an error into the xenstore.  The problem is that the scripts on the dom0
side never check for the error in the xenstore, and hence never know that it
wasn't set up properly.  In particular the /etc/xen/scripts/block script doesn't
actually check for any errors.

I think the solution here is probably to properly check for errors in the
block-attach, and then un-setup the loop device and in xenstore (on the dom0)
when it fails.  This will also get rid of the xm block-detach problem.
Comment 1 Glauber Costa 2006-11-29 14:32:28 EST
Chris, how does the relevant parts of xenstore-ls looks like ?
I'm also unable to detach them, but due to a different problem:
kernel gives the error message, but hotplug-status in xenstore appears as
connected. (Which partially explains it )
Comment 2 RHEL Product and Program Management 2006-11-29 16:30:53 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Glauber Costa 2006-12-13 17:45:50 EST
This is not a bug. Xend is too much fire & forget, and it provides us no
mechanism to detect failure/success. Error messages will most probably be
displayed only in guest, anyway. The important part of it, which is the fact
that the device is held forever, is handled in 217853

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