Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1071654 - [engine-backend] SCSI BUS scan is not initiated as part of creation/edit FC domain
Summary: [engine-backend] SCSI BUS scan is not initiated as part of creation/edit FC d...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: vdsm
Version: 3.4
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.5.0
Assignee: Nir Soffer
QA Contact: Elad
URL:
Whiteboard: storage
Depends On:
Blocks: 1057284
TreeView+ depends on / blocked
 
Reported: 2014-03-02 16:58 UTC by Elad
Modified: 2016-02-10 18:53 UTC (History)
13 users (show)

Fixed In Version: v4.16.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-17 12:27:21 UTC
oVirt Team: Storage


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 27122 master MERGED multipath: Rescan also FC devices Never
oVirt gerrit 30984 ovirt-3.5 MERGED multipath: Rescan also FC devices Never

Description Elad 2014-03-02 16:58:53 UTC
Description of problem:
Creation and edit of a Fibre-channel storage domain doesn't trigger ConnectStorageServer to be sent to vdsm. This issue is problematic in a situation of adding a new LUN on the storage server and exposing it to host which is connected by FC, because vdsm doesn't scan and refresh its FC connected devices. Extending FC storage domain by a new PV has to include manual intervention of rescanning the SCSI bus on the host itself.
 

Version-Release number of selected component (if applicable):
ovirt-engine-3.4.0-0.11.beta3.el6.noarch
vdsm-4.14.3-0.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
Have a shared DC and host connected and logged-in to a storage server by its FC HBA. 
1. Create and map a LUN to the host from the storage server
2. Create a FC storage domain (consist of the revealed LUN - PV from vdsm side)
3. Create and map a new LUN to the host 
4. Edit the FC domain, look for the new LUN

Actual results:
The Physical devices list presented in UI does not include the new LUN added and mapped to the host which is connected to it by FC. 

Workaround:
I've executed the following commands on host after mapping the new LUN to it:
- echo "1" > /sys/class/fc_host/host/issue_lip     ----> for each HBA (i.e fc_host0, fc_host1) 
- rescan-scsi-bus

New LUN is now presented by 'multipath -ll' 

Expected results:
Engine should ask vdsm to rescan its devices as part of creating/editing FC storage domain.

Comment 1 Sandro Bonazzola 2014-03-04 09:25:18 UTC
This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Comment 2 Nir Soffer 2014-05-12 17:58:23 UTC
We need testing by qe before we can merge this patch.

Comment 5 Elad 2014-06-02 14:12:14 UTC
Tested the patch on my 3.5-alpha env. with 2 storage servers: EMC-xtremIO and EMC-VNX
Performed the following tests:

Add LUN 
added LUN on storage server and opened 'new' domain dialog  
• tested 4 times with EMC-xtremIO - All went fine
• tested 4 times with EMC-VNX - All went fine


Remove LUN
• tested 3 times with EMC-VNX: getDeviceList failed with timeout (LUNs which were detected on previous server boot)
• tested 2 times with EMC-xtremIO - 
       - Removed a specific LUN and another one was shown as missing - happened twice



Replacing lun with EMC-xtremIO 
remove a lun from lun masking and added a new one with different size 
• Tested with XtremIO - the detected lun is the old one and is possible to be picked as a PV for a storage domain   BZ #1103722 
• tested with VNX -  failed because of BZ #1102829


Adding a device and calling multipath rescan while VM performs IOs:
Created VM with disk on FC domain and started it. Installed OS from PXE and performed the rescan (edit the FC domain). Checked that the installation went fine. VM started after the installation (executed getDevicesList in loop using vdsClient)
• tested with XtremIO - preallocated disk - succeeded (both when no new devices were added and when they did)
                      - thin-provision - succeeded (both when no new devices were added and when they did)
• tested with VNX -  preallocated - succeeded (both when no new devices were added and when they did)
                  - thin-provision - succeeded (both when no new devices were added and when they did)

Comment 6 Allon Mureinik 2014-07-17 06:47:56 UTC
Moving BZ back to post - this should be backported to the ovirt-3.5 branch

Comment 7 Sean Cohen 2014-07-23 08:33:36 UTC
Possible duplicate of 1071654 - if indeed the case, we will need to backport from 3.5 branch.
Sean

Comment 8 Allon Mureinik 2014-07-27 06:45:04 UTC
(In reply to Allon Mureinik from comment #6)
> Moving BZ back to post - this should be backported to the ovirt-3.5 branch
Nir, can you handle the backport please?

Comment 9 Nir Soffer 2014-07-27 11:02:15 UTC
(In reply to Allon Mureinik from comment #8)
> Nir, can you handle the backport please?
Seems that there are no ack on this bug - I guess we need all 3 - right?

Comment 10 Allon Mureinik 2014-07-27 11:16:37 UTC
(In reply to Nir Soffer from comment #9)
> (In reply to Allon Mureinik from comment #8)
> > Nir, can you handle the backport please?
> Seems that there are no ack on this bug - I guess we need all 3 - right?
It's an **oVirt** bug - no triple ack process ;-)

Comment 11 Elad 2014-09-15 08:51:47 UTC
Tested using rhev3.5 vt3.1

Removal and add of device are being scanned by vdsm properly using the scsi bus scan operation.

But when replacing a LUN in the storage server (removing a lun from lun masking and adding a new one with different size), the device list isn't updated.

I even got to a situation in which the FC domain was moved to inactive after I replaced 1 LUN which is not part of the domain. 

Nir, I don't think we can verify this bug while unrelated LUN replacement causes the FC domain to become inactive

Comment 12 Nir Soffer 2014-09-29 11:06:35 UTC
I don't see how I can help with this.

Comment 13 Sandro Bonazzola 2014-10-17 12:27:21 UTC
oVirt 3.5 has been released and should include the fix for this issue.


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