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): RHEV 3.0 Hypervisor: rhevh-6.2-20120320.0.iso How reproducible: 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" Actual results: 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 Expected results: vdsm should be more robust (cit. Haim Ateya), and it should skip local disks attached to multipath by mistake, instead of halting Additional info: topic discussed on ovirt mailing list http://lists.ovirt.org/pipermail/users/2012-August/003537.html 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. See http://lists.ovirt.org/pipermail/users/2012-August/003573.html
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.