Bug 1133938

Summary:	SD inactive after 2nd extension (with already added LUN)
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Julio Entrena Perez <jentrena>
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:	acanan, amureini, derez, ebenahar, ecohen, iheim, jentrena, lpeer, mlipchuk, pdwyer, rbalakri, Rhev-m-bugs, scohen, tnisan, yeylon
Target Milestone:	---	Keywords:	Reopened, Triaged
Target Release:	3.5.0
Hardware:	All
OS:	Linux
Whiteboard:	storage
Fixed In Version:	ovirt-engine-3.5.0_rc2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-11 18:08:42 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:

Description Julio Entrena Perez 2014-08-26 13:33:17 UTC

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:

Comment 3 Maor 2014-09-02 08:35:18 UTC

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)?

Comment 6 Allon Mureinik 2014-09-10 11:52:01 UTC

Daniel - Can this be related to bug 955661 ?

Comment 7 Daniel Erez 2014-09-10 12:16:59 UTC

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

Comment 8 Allon Mureinik 2014-09-11 13:40:56 UTC

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

Comment 9 Daniel Erez 2014-09-15 16:36:17 UTC

(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 ***

Comment 10 Julio Entrena Perez 2014-09-16 10:01:50 UTC

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

Comment 11 Daniel Erez 2014-09-16 10:52:13 UTC

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

Comment 14 Aharon Canan 2014-09-29 06:07:38 UTC

How did you do it? via rest api?

Comment 16 Aharon Canan 2014-10-05 07:30:46 UTC

verified using vt4

Luns that in use are greyed out.

Comment 18 errata-xmlrpc 2015-02-11 18:08:42 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