Bug 851478

Summary: getDeviceList fails when multipath lists a non-scsi disk
Product: [Retired] oVirt Reporter: Alberto Scotto <al.scotto>
Component: vdsmAssignee: Ayal Baron <abaron>
Status: CLOSED WONTFIX QA Contact: Haim <hateya>
Severity: low Docs Contact:
Priority: unspecified    
Version: 3.0 GACC: abaron, acathrow, al.scotto, amureini, bazulay, dyasny, iheim, mgoldboi, yeylon, ykaul
Target Milestone: ---   
Target Release: 3.3.4   
Hardware: x86_64   
OS: Linux   
URL: http://lists.ovirt.org/pipermail/users/2012-August/003537.html
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-12 09:36:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of the command "vdsClient -s 0 getDeviceList", written in vdsm.log none

Description Alberto Scotto 2012-08-24 09:40:13 UTC
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.

Comment 1 Ayal Baron 2012-08-24 21:38:59 UTC
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).

Comment 2 Alberto Scotto 2012-09-06 08:32:59 UTC
You may close.
See http://lists.ovirt.org/pipermail/users/2012-August/003573.html

Comment 3 Itamar Heim 2013-03-12 09:36:34 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.