Bug 1451018

Summary:	[DR] [RFE] Add backup storage connection for storage domain
Product:	[oVirt] ovirt-engine	Reporter:	Elad <ebenahar>
Component:	RFEs	Assignee:	Scott Herold <sherold>
Status:	CLOSED DEFERRED	QA Contact:	Raz Tamir <ratamir>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	4.1.2.2	CC:	bugs, ebenahar, ratamir, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	ylavi: ovirt-4.2? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-31 08:12:47 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:
Bug Depends On:
Bug Blocks:	1284364, 1534978

Description Elad 2017-05-15 14:58:31 UTC

Description of problem:

In order to allow storage replication for disaster recovery purposes, need to have an option to store a backup storage connection for each storage domain in the DR data center. 
Currently, the existing functionality is the manage storage connection feature that allows replacing the storage domain's storage connection. 
We need this secondary connection to be stored as a backup one and in a case of a disaster, the storage domain's storage connection will be replaced immediately with a minimum manual intervention.

Comment 1 Yaniv Lavi 2017-06-13 09:28:55 UTC

Do you think it really needed?
In active-active, this would mean downtime during the reconnect.
In active-passive, the tool can handle the mapping.

Shouldn't we rely on multipathing or DNS name change?

Comment 2 Elad 2017-06-16 13:48:07 UTC

In active-active we'll probably have to rely on storage relication. So at the moment, this is not needed.

Comment 3 Elad 2017-06-16 13:49:47 UTC

* Storage replication with some kind of a floating address the storage exposes, hiding the 'real' addresses to both sites.

Comment 4 Yaniv Lavi 2017-07-31 08:12:47 UTC

Closing until we know if this is needed