Bug 1066081 - Enable sync of LUNs after storage domain activation for FC
Summary: Enable sync of LUNs after storage domain activation for FC
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: 3.4.0
Assignee: Daniel Erez
QA Contact: Elad
Whiteboard: storage
Depends On:
Blocks: 1074297 rhev3.4beta 1142926
TreeView+ depends on / blocked
Reported: 2014-02-17 16:11 UTC by Pablo Iranzo Gómez
Modified: 2019-04-28 09:15 UTC (History)
12 users (show)

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.
Clone Of:
: 1074297 (view as bug list)
Last Closed: 2014-06-09 15:04:21 UTC
oVirt Team: Storage
Target Upstream Version:
tpoitras: needinfo-

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:0506 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.4.0 update 2014-06-09 18:55:38 UTC
oVirt gerrit 24714 None None None Never
oVirt gerrit 24889 None None None Never
oVirt gerrit 24895 None None None Never

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.


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

- 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.


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:

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.


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?

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