Bug 1066081

Summary:	Enable sync of LUNs after storage domain activation for FC
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Pablo Iranzo Gómez <pablo.iranzo>
Component:	ovirt-engine	Assignee:	Daniel Erez <derez>
Status:	CLOSED ERRATA	QA Contact:	Elad <ebenahar>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.3.0	CC:	acathrow, amureini, eedri, iheim, lpeer, pdwyer, perobins, Rhev-m-bugs, richard.davis, scohen, tpoitras, yeylon
Target Milestone:	---	Flags:	tpoitras: needinfo-
Target Release:	3.4.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	storage
Fixed In Version:	av3	Doc Type:	Bug Fix
Doc Text:	With this update, in the event of failure on a storage domain that is replicated to other storage domains, the Red Hat Enterprise Virtualization Manager automatically updates the list of available LUNs on the active storage domain, in order to reflect what is currently available.	Story Points:	---
Clone Of:
Clones:	1074297 (view as bug list)		Environment:
Last Closed:	2014-06-09 15:04: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:	1074297, 1078909, 1142926

Description Pablo Iranzo Gómez 2014-02-17 16:11:08 UTC

Description of problem:

3.3 Incorporated the Storage Connection Manager, and patch in http://gerrit.ovirt.org/#/c/17919 works for iSCSI, but something similar will be needed in FC environments.

Environment:

- SAN-replicated LUNS
- RHEV-M 
- Multi-site (or DR environment).

Issue:
- RHEV-M should provide a way to edit 'WWID' of LUNS part of a SD or do that automatically, enabling RHEV-M to recognize the LUNS when the replication direction is switched.

Example:

Site A is active, and site B is getting another set of LUN's replicated via SAN.

When Site A fails, SAN replication direction is switched so Site B becomes master and Site A becomes replica.

Unless you're using some way of virtualizing the storage, this will mean that LUNS will have another WWID, different to the ones in SiteA, making RHEV not able to recognize the storage thus enabling the SD's and allowing the VM's to boot.

Comment 5 Elad 2014-03-27 15:42:13 UTC

TCMS run was executed.
Verified using RHEV3.4 av5 according to steps written in the test case:
https://tcms.engineering.redhat.com/run/124085/

Comment 6 Elad 2014-03-27 16:05:36 UTC

Steps to reproduce:


-Install RHEL on host (make sure the host is not exposed to any devices via FC)
-Once host has RHEL OS installed, Expose a 20G LUN to it from the storage server via FC
-Create a FC storage domain resides on a 20G physical volume
-Activate the domain
-Issue SAN copy from storage server side - copy the data from the 20G LUN to a new 25G LUN
-Connect the new LUN (25G) to the host (LUN masking) and remove the original LUN (20G)
-Reboot the host so the FC connected devices will be rescanned
-Activate the storage domain
-Under 'Storage domains' tab, pick the relevant domain and click on 'Edit'.

LUN ID changed to the new one

Comment 8 Timothy 2014-05-15 04:38:52 UTC

Doc text updated, please review for accuracy.

Comment 9 Allon Mureinik 2014-05-15 05:15:07 UTC

(In reply to Timothy from comment #8)
> Doc text updated, please review for accuracy.

A small correction: The update is performed when the storage domain is updated. Clicking edit has nothing to do with the update itself, it's just an example of when this information will become visible to the user.

Comment 10 Timothy 2014-05-15 05:24:32 UTC

Thank you, Allon. Updated.

Comment 11 errata-xmlrpc 2014-06-09 15:04:21 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-0506.html

Comment 12 Richard Davis 2014-06-30 16:43:59 UTC

No , this solution does not work as expected.
Details forwared to TAM Paul Dwyer.

Comment 13 Allon Mureinik 2014-06-30 18:00:32 UTC

(In reply to Richard Davis from comment #12)
> No , this solution does not work as expected.
> Details forwared to TAM Paul Dwyer.

Paul, the details, please?