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

Bug 1115845

Summary:	Enable sync of LUNs after storage domain activation for FC - duplicate LUNs
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Paul Dwyer <pdwyer>
Component:	ovirt-engine	Assignee:	Daniel Erez <derez>
Status:	CLOSED ERRATA	QA Contact:	Elad <ebenahar>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.4.0	CC:	adahms, amureini, derez, ebenahar, iheim, jentrena, lpeer, pdwyer, rbalakri, Rhev-m-bugs, scohen, yeylon
Target Milestone:	---
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Linux
Whiteboard:	storage
Fixed In Version:	ovirt-3.5.0_rc1.1	Doc Type:	Bug Fix
Doc Text:	LUN information synchronization [1] is now invoked whenever the status of a storage domain changes to 'Active' (for example, when a storage domain is detected as active upon activating the storage pool manager). Previously, this process was activated only when manually activating a domain. [1] The process of synchronizing LUN information from the underlying storage with the engine database, such as when adding, removing, or extending a LUN in storage, is properly reflected in the engine database and consequently in the user interface and REST API.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-11 18:05:15 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:	1142923, 1156165

Description Paul Dwyer 2014-07-03 08:57:52 UTC

Description of problem:
Customer has tested feature included in RHEV3.4 (https://bugzilla.redhat.com/show_bug.cgi?id=1066081), following similar process that was tested by QA results in for the original LUNS alongside new replicated LUNS and does not sync the new replicated LUNS

Version-Release number of selected component (if applicable):
RHEV3.4

How reproducible:
Always

Steps to Reproduce:
Full details (& screenshots) in attached doc

Replicated LUNs are attached to hypervisors in DR (hypervisors only see replicated LUNS)
edit storage domain

Actual results:
Duplicate LUNs (old and new)

Expected results:
New Replicated LUNs listed after syncing

Additional info:
See attached doc for full details of customer testing and results

Comment 3 Daniel Erez 2014-07-03 09:10:22 UTC

Hi Paul,

* Have you reactivated (maintenance + activate) the storage domain after attaching the LUNs (the sync operation should be performed on storage domain activation).

* Can you please attach the full engine logs.

Comment 5 Daniel Erez 2014-07-03 12:56:59 UTC

According to the attached engine log, it seems that the SD hasn't been reactivated, and hence the LUNs info synchronization wasn't invoked.
Please check whether the issue is resolved after reactivation (in any case, I think we should add it as a note in the documentation/release-notes).

Comment 15 Elad 2014-09-16 10:34:09 UTC

From what I got from the conversation above, the steps to reproduce are:
In 2 DCs env:
1) In DC1: Have a FC domain resides on a LUN from the storage server
2) Have a replicated LUN which contains the exact same data as in the LUN which is part of the storage domain in the DC1
3) Expose the replicated LUN to a different host in DC2
4) Maintenance the SD in DC1 and activate it
5) The device list in DC2 should include the replicated LUN and the should be available to be picked 

Daniel, Please correct me if I'm wrong

Comment 16 Daniel Erez 2014-09-21 07:22:00 UTC

(In reply to Elad from comment #15)
> From what I got from the conversation above, the steps to reproduce are:
> In 2 DCs env:
> 1) In DC1: Have a FC domain resides on a LUN from the storage server
> 2) Have a replicated LUN which contains the exact same data as in the LUN
> which is part of the storage domain in the DC1
> 3) Expose the replicated LUN to a different host in DC2
> 4) Maintenance the SD in DC1 and activate it
> 5) The device list in DC2 should include the replicated LUN and the should
> be available to be picked 
> 
> Daniel, Please correct me if I'm wrong

Instead of step (4), you should have a storage domain in DC2 ready for activation. The enhancement addressed in this bug is that the 'syncLunsInfo' operation should now be invoked when an SD is being detected as Active. So, for example, try a similar scenario which instead of manually reactivating the domains, reactivate the hosts. E.g. have DC2 up and running, move hosts to maintenance, expose the replicate LUN, reactivate the hosts - check whether 'syncLunsInfo' action is being invoked when the storage domain is back to Active status.

Comment 17 Elad 2014-10-13 14:09:57 UTC

SyncLunsInfoForBlockStorageDomainCommand is called for auto activate a block domains and not only for manual activation.

Verified using rhev3.5 vt5

Comment 19 errata-xmlrpc 2015-02-11 18:05:15 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.

https://rhn.redhat.com/errata/RHSA-2015-0158.html