Red Hat Bugzilla – Bug 1133938
SD inactive after 2nd extension (with already added LUN)
Last modified: 2016-02-10 11:55:33 EST
Description of problem: After adding a FC LUN to a SD, RHEV allows the same LUN to be added again to the SD thus rendering the SD inactive. Version-Release number of selected component (if applicable): rhevm-3.3.3-0.52.el6ev How reproducible: Unknown End user lost connection to RHEV-M after requesting first extension with LUN A. After logging back in he requested extension with LUNs A and B but LUN A had already been added. Steps to Reproduce: 1. Present two LUNs (A and B) to the hosts. 2. Add LUN A to a storage domain. A PV is created on LUN A with UUID UA1. 3. Add LUNs A and B to the same storage domain. A PV is created in LUNs A and B with UUIDs UA2 and UB. Actual results: LVM will miss the PV with UUID UA1. getMetaDataMapping fails. Storage domain becomes inactive. Expected results: RHEV does not allow the user to add the same LUN _again_ to the SD. Additional info:
Hi Julio, when the customer tried the second extension of the Storage Domain, did he get any warning that the LUN was being used by a VG (see warning example at [1]) Since we can not be sure if the PV is currently being used by another user or it is already un-relevant, the GUI should warn the user before overriding this certain PV. [1] This operation might be unrecoverable and destructive! The following LUNs are already in use: - 3600144f09dbd050000004ddcc2550027 (Used by VG: p6GoVe-0CHV-Qoh5-zlVZ-SWpa-vabz-iPBAu1)?
Daniel - Can this be related to bug 955661 ?
(In reply to Allon Mureinik from comment #6) > Daniel - Can this be related to bug 955661 ? Yes, seems to be a similar issue. We should check if the described scenario can be reproduced on a recent build.
(In reply to Daniel Erez from comment #7) > (In reply to Allon Mureinik from comment #6) > > Daniel - Can this be related to bug 955661 ? > > Yes, seems to be a similar issue. We should check if the described scenario > can be reproduced on a recent build. Please do, and close as a duplicate if it really is.
(In reply to Allon Mureinik from comment #8) > (In reply to Daniel Erez from comment #7) > > (In reply to Allon Mureinik from comment #6) > > > Daniel - Can this be related to bug 955661 ? > > > > Yes, seems to be a similar issue. We should check if the described scenario > > can be reproduced on a recent build. > Please do, and close as a duplicate if it really is. Couldn't reproduce the described scenario on latest 3.5 build. Marking as duplicate. *** This bug has been marked as a duplicate of bug 955661 ***
(In reply to Daniel Erez from comment #9) > > *** This bug has been marked as a duplicate of bug 955661 *** Bug 955661 reads: "Happens only when force overriding LUN when extending storage domain" But as per comment 1 that's not the case in support case 01179519: Thread-270623::INFO::2014-08-22 15:04:30,348::logUtils::44::dispatcher::(wrapper) Run and protect: extendStorageDomain(sdUUID='0d0c9197-d494-4c95-b07d-cf0ac85ec9f8', spUUID='6a02ed2b-2fc1-45e7-8980-c53a720b180c', guids=['200173800642a0e25'], force=False, options=None) so re-opening this BZ and re-attaching this case to it, please review.
(In reply to Julio Entrena Perez from comment #10) > (In reply to Daniel Erez from comment #9) > > > > *** This bug has been marked as a duplicate of bug 955661 *** > > Bug 955661 reads: > > "Happens only when force overriding LUN when extending storage domain" > > But as per comment 1 that's not the case in support case 01179519: > > Thread-270623::INFO::2014-08-22 > 15:04:30,348::logUtils::44::dispatcher::(wrapper) Run and protect: > extendStorageDomain(sdUUID='0d0c9197-d494-4c95-b07d-cf0ac85ec9f8', > spUUID='6a02ed2b-2fc1-45e7-8980-c53a720b180c', guids=['200173800642a0e25'], > force=False, options=None) > > so re-opening this BZ and re-attaching this case to it, please review. Correct, missed it. The underlined issue seems to be the same; i.e. the same patch resolved both scenarios (couldn't reproduce on latest 3.5 build). But since the scenarios are a bit different, moving to modified for re-verification.
How did you do it? via rest api?
verified using vt4 Luns that in use are greyed out.
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