Red Hat Bugzilla – Bug 851478
getDeviceList fails when multipath lists a non-scsi disk
Last modified: 2016-02-10 13:15:44 EST
Created attachment 606813 [details]
output of the command "vdsClient -s 0 getDeviceList", written in vdsm.log
Description of problem:
If multipath lists a non-scsi local disk (attached by mistake), then the command "vdsClient -s 0 getDeviceList" will fail outputting the error "Error block device action: ()". Adding a new data domain from the console will fail as well returning "Could not retrieve LUNs, please check your storage".
See logs attached.
Version-Release number of selected component (if applicable):
Adding a non-scsi local disk to multipath (in my case: cciss!c0d1, being part of an HP Smart Array)
Steps to Reproduce:
1. on the hypervisor, add a non-scsi disk to multipath
2. execute "vdsClient -s 0 getDeviceList"
The command "vdsClient -s 0 getDeviceList" halts as soon as it tries to handle the non-scsi disk as a scsi one. Here is where it halts:
OSError: [Errno 2] No such file or directory: '/sys/block/cciss!c0d1/device/scsi_disk/'
Since cciss!c0d1 is NOT a scsi disk, the directory scsi_disk/ doesn't exist in /sys/block/cciss!c0d1/device
vdsm should be more robust (cit. Haim Ateya), and it should skip local disks attached to multipath by mistake, instead of halting
topic discussed on ovirt mailing list
As suggested by Haim Ateya, I'm opening this bug report.
Alberto, would you mind testing this with latest vdsm from upstream?
We've actually made some changes to support cciss devices but have no such hardware locally to test it on and would like to know if it works now (or at least doesn't fail miserably).
You may close.
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.