Bug 1533431

Summary:	[Tracker] Support HE with DR
Product:	[oVirt] ovirt-ansible-collection	Reporter:	Maor <mlipchuk>
Component:	disaster-recovery	Assignee:	Maor <mlipchuk>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Elad <ebenahar>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	cshao, lsvaty, mlipchuk, ycui, ylavi, yzhao
Target Milestone:	ovirt-4.2.2	Keywords:	TestOnly, Tracking
Target Release:	---	Flags:	rule-engine: ovirt-4.2+ ylavi: blocker+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	DR
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-05-14 15:10:55 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 Maor 2018-01-11 10:42:48 UTC

Description of problem:
We should verify that HE is supported through the DR scenario of fail over and fail back

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Maor 2018-01-18 13:29:11 UTC

We need to define the exact use case of the customer regarding HE first.
One question that cross my mind is how should we replicate a hosted engine storage domain while the hosted engine is up on the destination setup?
What I mean is that the replicated storage domain in the destination should be R/O, so how can the destination setup run that storage domain without writing to it?

One possible solution is to ask the user to clone the HE storage domain, and use that cloned storage domains as R/W to run the engine on it.
We can then import the replicated storage domain from the secondary site and import its entities from it.

Comment 2 Maor 2018-01-22 22:53:43 UTC

since the last discussion which was done on hosted engine, it was decided that for oVirt 4.2, the DR will support Hosted Engine Storage Domain without any additional entities (VMs/Templates) which are reside on the hosted storage domain.
So the recovery process will be done on all the rest of the storage domains in the system, and should be supported with the regular use case.
Therefore downgrade the bug priority to medium for now.

Yaniv Lavi, can you please confirm that the use case I described is good enough for oVirt 4.2 or we should aim to something different?

Comment 3 Yaniv Lavi 2018-02-06 10:55:44 UTC

Ack.

Comment 4 Allon Mureinik 2018-02-28 13:40:33 UTC

(In reply to Maor from comment #2)
> since the last discussion which was done on hosted engine, it was decided
> that for oVirt 4.2, the DR will support Hosted Engine Storage Domain without
> any additional entities (VMs/Templates) which are reside on the hosted
> storage domain.
> So the recovery process will be done on all the rest of the storage domains
> in the system, and should be supported with the regular use case.
> Therefore downgrade the bug priority to medium for now.
> 
> Yaniv Lavi, can you please confirm that the use case I described is good
> enough for oVirt 4.2 or we should aim to something different?

Based on this, can we move the BZ to ON_QA?

Comment 5 Elad 2018-05-12 21:33:49 UTC

DR site to site works properly with hosted engine.
Tested failover and failback.
Hosted engine's storage domain does not participate in these processes.

Used:
ovirt-ansible-disaster-recovery-0.4-1.el7ev.noarch
ansible-2.5.2-1.el7ae.noarch

Comment 6 Sandro Bonazzola 2018-05-14 15:10:55 UTC

This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.