Bug 1025788

Summary: [RFE] ability to move Data Storage domain between Data Centers
Product: Red Hat Enterprise Virtualization Manager Reporter: Allie DeVolder <adevolder>
Component: RFEsAssignee: Sean Cohen <scohen>
Status: CLOSED DUPLICATE QA Contact: Shai Revivo <srevivo>
Severity: unspecified Docs Contact:
Priority: high    
Version: 3.3.0CC: abaron, acathrow, amureini, iheim, lpeer, rprice, scohen, sputhenp, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: 3.5.0   
Hardware: All   
OS: Linux   
Whiteboard: storage
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-30 14:30:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Allie DeVolder 2013-11-01 15:15:40 UTC
1.	Why exactly do you need this feature? (List the business requirements here)  Note: Strong business requirements drive the feature request faster.
A – This feature will help setup a warm standby DR for RHEV VM’s. Currently RHEV only offers a Cold DR solution, which cannot be bought online within business specified 4Hr. window for large number of clusters. Other VM technologies(For eg. ESX) have this functionality in which VM’s can be started on remote site by replicating VMDK files on SAN.

2.	How would you like to achieve this? (List the functional requirements here)
A -  Data Storage domain consisting VM’s and its Virtual disks should be allowed to be detached and attached between DataCenters. This will allow us to attach a SAN replicated Prod Data Storage Domain to a DR DataCenter managed within the same RHEV-M or even on a separate DR RHEV-M environment.

3.	Any specific timeline dependencies?
A -  We would like to see this functionality in a Beta release for RHEV in next 3 months.

4.	Would you be able to assist in testing this feature - if implemented?
A -  Yes. We could assist in testing.