|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-engine||Assignee:||Tal Nisan <tnisan>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Elad <ebenahar>|
|Version:||3.5.0||CC:||acanan, amureini, bkorren, derez, didi, ecohen, gklein, iheim, lpeer, lsurette, lveyde, mlipchuk, rbalakri, Rhev-m-bugs, sbonazzo, scohen, stirabos, tnisan, yeylon|
|Fixed In Version:||org.ovirt.engine-root-3.5.0-28||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|oVirt Team:||Storage||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1157239, 1171452|
|Bug Blocks:||1164308, 1164311|
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-126.96.36.199-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 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.