Bug 1157243

Summary: [engine-backend] [importDomain] [iSCSI support] hosted-engine: import the hosted-engine's storage domain is allowed
Product: Red Hat Enterprise Virtualization Manager Reporter: Elad <ebenahar>
Component: ovirt-engineAssignee: Tal Nisan <tnisan>
Status: CLOSED CURRENTRELEASE QA Contact: Elad <ebenahar>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: acanan, amureini, bkorren, derez, didi, ecohen, gklein, iheim, lpeer, lsurette, lveyde, mlipchuk, rbalakri, Rhev-m-bugs, sbonazzo, scohen, stirabos, tnisan, yeylon
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: org.ovirt.engine-root-3.5.0-28 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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:
Bug Depends On: 1157239, 1171452    
Bug Blocks: 1164308, 1164311    
Attachments:
Description Flags
vdsm.log and setup log
none
screeshot
none
screenshots from webadmin + pg_dump none

Description Elad 2014-10-26 14:44:53 UTC
Created attachment 950798 [details]
vdsm.log and setup log

Description of problem:
On hosted engine setup, I tried to import the storage domain which the engine's VM disk was deployed on. After the import, the whole envirement crashed. I couldn't repair it.

Version-Release number of selected component (if applicable):
rhev 3.5 vt7
rhel6.6 host
ovirt-hosted-engine-setup-1.2.1-1.el6ev.noarch
rhevm-3.5.0-0.17.beta.el6ev.noarch
vdsm-4.16.7.1-1.el6ev.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Deploy hosted-engine (I used iSCSI storage)
2. When the engine is up and running, import the "hosted_storage" storage domain, which is used by the hosted-engine to host the engine's VM disk to the setup (the same engine)  


Actual results:
Import to the storage domain that host the engine's disk is allowed
During the import, the setup crashed, the engine is not operational

Expected results:
Import to this storage domain should not be allowed

Additional info: vdsm.log and setup log

Comment 1 Tal Nisan 2014-10-28 10:33:33 UTC
We currently don't have any indication in the engine of this LUN. There has to be a way for the engine to know this LUN before we can block this operation, moving to integration to set up this data so the storage flows can use it.

Comment 2 Sandro Bonazzola 2014-11-05 12:53:20 UTC
http://gerrit.ovirt.org/34783 add the HE disk to the engine.
Now the lun is known to the engine, any other change required on hosted-engine side?

Moving back to storage.

Comment 3 Tal Nisan 2014-11-23 08:59:45 UTC
Not that I can think of, Allon, Daniel can you think of something else that needs to be done?

Comment 4 Allon Mureinik 2014-11-23 20:14:01 UTC
(In reply to Tal Nisan from comment #3)
> Not that I can think of, Allon, Daniel can you think of something else that
> needs to be done?
Not that I can think about.
Daniel?

Comment 5 Daniel Erez 2014-11-24 17:01:38 UTC
What's the indication now that the LUN is being used by an hosted engine?

Comment 6 Simone Tiraboschi 2014-11-24 17:13:42 UTC
(In reply to Daniel Erez from comment #5)
> What's the indication now that the LUN is being used by an hosted engine?

It's added to the engine as a direct LUN disk

Comment 7 Tal Nisan 2014-11-25 13:19:39 UTC
I think that if it's added as a direct LUN it should be safe enough unless someone decides to remove this disk and create a storage domain on this LUN afterwards

Comment 8 Allon Mureinik 2014-11-26 08:15:01 UTC
(In reply to Tal Nisan from comment #7)
> I think that if it's added as a direct LUN it should be safe enough unless
> someone decides to remove this disk and create a storage domain on this LUN
> afterwards
Moving to MODIFIED based on this statement.

Comment 9 Elad 2014-12-10 13:40:22 UTC
It seems like exposing the LUN that used for the hosted engine


LUN exists in the DB:

          physical_volume_id           |      lun_id       |            volume_group_id             |             serial             | lun_mapping | vendor_id | product_id | device_size 
----------------------------------------+-------------------+----------------------------------------+--------------------------------+-------------+-----------+------------+-------------
                                        | 3514f0c54476006a1 |                                        |                                |             |           |            |           0
 Br4Vx9-qpta-OnCb-9AAX-jQyH-ZALT-hLHw0Q | 3514f0c54476004a1 | UovL6K-ISpI-34SN-jRpK-1DnJ-OrRk-KnVqeg | SXtremIO_XtremApp_PSNT_Not_Set |           6 | XtremIO   | XtremApp   |          40



An attempt to import the domain that resides on that LUN is allowed. The system will crash (with no option to recover).

Attaching a screenshot from webadmin.

I think that the issue here cannot be solved with the existance of the LUN as a direct LUN, as opposed to https://bugzilla.redhat.com/show_bug.cgi?id=1157238.

Comment 10 Elad 2014-12-10 13:44:35 UTC
Created attachment 966801 [details]
screeshot

Comment 11 Elad 2014-12-21 15:58:55 UTC
Cannot be tested due to https://bugzilla.redhat.com/show_bug.cgi?id=1171452

Comment 12 Elad 2014-12-24 15:56:05 UTC
Created attachment 972790 [details]
screenshots from webadmin + pg_dump

It's still allowed to import the hosted-engine storage domain.

Attching screenshots from webadmin + pg_dump 

Tested using rhev 3.5 vt13.5 
rhevm-3.5.0-0.27.el6ev.noarch

The engine was installed from scrached and wasn't updated

Comment 13 Elad 2015-01-11 14:31:45 UTC
The iSCSI storage domain, which contains the engine image, doesn't presented in the domains that are possible to be imported.

Verified using rhev 3.5 vt13.6

Comment 14 Allon Mureinik 2015-02-16 19:11:35 UTC
RHEV-M 3.5.0 has been released, closing this bug.

Comment 15 Allon Mureinik 2015-02-16 19:11:35 UTC
RHEV-M 3.5.0 has been released, closing this bug.