Red Hat Bugzilla – Bug 217243
xm block-attach does not give error messages when it fails to attach
Last modified: 2007-11-30 17:07:38 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
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.
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 )
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
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