Bug 773318

Summary:	[RFE] No need for Export domain
Product:	[Retired] oVirt	Reporter:	Jaroslav Henner <jhenner>
Component:	ovirt-engine-core	Assignee:	Allon Mureinik <amureini>
Status:	CLOSED DUPLICATE	QA Contact:	Aharon Canan <acanan>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, amureini, bugs, iheim, jfenal, jlibosva, lpeer, pstehlik, ykaul
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	3.5.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	storage
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-04 09:14:02 UTC	Type:	---
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 Jaroslav Henner 2012-01-11 13:57:48 UTC

Description of problem:
From my point of view, Export domain is not needed and it's purpose -- moving VMs across Datacenters could be done using Data domains only using Destroy and "Import". The term "Destroy" for would have to be changed it is misleading anyway. 

Getting rid of Export domain would bring a system simplification there wouldn't  export and import operations. Only move operations would be required.

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

Comment 1 Itamar Heim 2012-01-15 12:12:48 UTC

how do you expect this will work between rhev-m deployments using block storage devices?

(we could solve with an download/upload api, but it will require moving the bits twice)

Comment 2 Pavel Stehlik 2012-01-21 15:35:33 UTC

From my POV it's pretty important for enterprise deployment. Customer needs backup & also possibility to use it on test environment.
I'd like to have more feats during export/import:
 - encryption & compression of files;
 - renaming (nowadays based on ID - which leads for impossibility to clearly identify images);
 - description (where will customer place comments of his images?);
 - auto-export (ok, today could be solved by REST);
 - support of 3r parties SW ?  (maybe their business);

I'd like to add I am not against 'fast' moving between DC's in same setup which Jarda originaly demanded - on the contrary.
P.

Comment 3 Jaroslav Henner 2012-01-21 21:36:47 UTC

(In reply to comment #1)
> how do you expect this will work between rhev-m deployments using block storage
> devices?
Same way as with export. I meant that I don't understand what is the difference between export and data domain. Why there are those restriction that we can attach only one export (I hope I'm not wrong there) and that it is not possible to import a data domain.

> (we could solve with an download/upload api, but it will require moving the
> bits twice)
With export domain, you also need to export the VM to ED and than import the VM in another DC from ED.

Comment 4 Jaroslav Henner 2012-01-25 12:00:44 UTC

It will also mean less copy operations to be performed in order to move the VM from one DC to another. 

Current workflow:
1) Attach Export
2) Copy from Data -> Export
3) Detach the export
4) Attach export in another DC
5) Copy form Export -> Data
6) Use your VMs

New workflow:
1) Attach (new) Data domain
2) Copy from Data -> Data domain
3) Detach the Data domain
4) Attach (Import) the data domain in another DC
5) [Nothing here]
6) Use your VMs

Note the point 5)

Comment 5 Itamar Heim 2013-06-02 07:52:07 UTC

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Comment 6 Jaroslav Henner 2014-01-30 12:35:58 UTC

I think this still applies. Reopening.

Comment 7 Itamar Heim 2014-08-04 09:14:02 UTC

done in 3.5 via import data domain

*** This bug has been marked as a duplicate of bug 1083307 ***