Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1071654

Summary:	[engine-backend] SCSI BUS scan is not initiated as part of creation/edit FC domain
Product:	[Retired] oVirt	Reporter:	Elad <ebenahar>
Component:	vdsm	Assignee:	Nir Soffer <nsoffer>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Elad <ebenahar>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.4	CC:	acanan, amureini, bazulay, bugs, ecohen, gklein, iheim, mgoldboi, nsoffer, rbalakri, scohen, srevivo, yeylon
Target Milestone:	---
Target Release:	3.5.0
Hardware:	x86_64
OS:	Unspecified
Whiteboard:	storage
Fixed In Version:	v4.16.2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-17 12:27:21 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:
Bug Depends On:
Bug Blocks:	1057284

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.