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-engine | Assignee: | Tal Nisan <tnisan> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Elad <ebenahar> | ||||||||
| Severity: | urgent | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| 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 | ||||||||
| 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: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | 1157239, 1171452 | ||||||||||
| Bug Blocks: | 1164308, 1164311 | ||||||||||
| Attachments: |
|
||||||||||
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. 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. Not that I can think of, Allon, Daniel can you think of something else that needs to be done? (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? What's the indication now that the LUN is being used by an hosted engine? (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 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 (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. 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.
Created attachment 966801 [details]
screeshot
Cannot be tested due to https://bugzilla.redhat.com/show_bug.cgi?id=1171452 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
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 RHEV-M 3.5.0 has been released, closing this bug. RHEV-M 3.5.0 has been released, closing this bug. |
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