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
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.
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).
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
(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.
SyncLunsInfoForBlockStorageDomainCommand is called for auto activate a block domains and not only for manual activation. Verified using rhev3.5 vt5
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