Bug 1319524

Summary:	[RFE] Allow downloading VM to named OVF/OVA to client or to nfs paths (even if VM has snapshots)
Product:	[oVirt] ovirt-engine	Reporter:	md
Component:	Backend.Core	Assignee:	Arik <ahadas>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Nisim Simsolo <nsimsolo>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	future	CC:	ahadas, amureini, bgraveno, bugs, ebenahar, herrold, klaas, mavital, md, michal.skrivanek, mtessun, nsimsolo, ratamir, tnisan, ylavi
Target Milestone:	ovirt-4.2.2	Keywords:	FutureFeature
Target Release:	---	Flags:	rule-engine: ovirt-4.2+ ebenahar: testing_plan_complete+ mtessun: planning_ack+ michal.skrivanek: devel_ack+ ratamir: testing_ack+
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	ovirt-engine-4.2.2.4	Doc Type:	Enhancement
Doc Text:	This update enables you to export a virtual machine as an OVA file to a specified path on a host in the data center. The specified path can also be NFS shared storage that is mounted on the host.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-03-29 10:57:41 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:	659847

Description md 2016-03-20 22:11:29 UTC

Description of problem:

If you want to export a VM (live) to a Export Domain, you have to create a Snapshot, create a Clone of the Snapshot and then export the Clone to the Export Domain. After all, you have to delete the Clone and the Snapshot.
It would be easier and less time ans Storage IO consuming if it its possible to Export a Snapshot directly.
 
Version-Release number of selected component (if applicable):


How reproducible:

always

Steps to Reproduce:
1. Create Snapshot
2. Clone Snapshot to a new VM
3. Exort new VM to Export Domain
4. Delete Clone
5. Delete Snapshot

Actual results:

Cloning required before Export is possible

Expected results:

Direct Export the Snapshot to Export Domain

Additional info:

Would make the Backup faster and more efficient, unnessecary Storage Traffic would be avoided

Comment 1 Tal Nisan 2016-03-21 08:40:21 UTC

iiuc the problem resides in the fact that you can't export a running VM so you need to create a snapshot, clone it to a stopped VM, export the new one and delete all the steps, is that correct?

Comment 2 Allon Mureinik 2016-03-21 10:17:29 UTC

The requirement seems to make sense, IMHO. However, looking forwards, we're looking to get rid of the export domain altogether - so we may not implement this RFE, but with any solution we provide, we need to consider it and give some equivalent capability.

Comment 3 md 2016-03-21 18:34:18 UTC

Yes Tal Nisan, these are the Steps required for Exporting a VM which is running, for now its the only Solution for a Backup, I think.

Comment 4 Yaniv Lavi 2016-12-06 13:17:18 UTC

(In reply to md from comment #3)
> Yes Tal Nisan, these are the Steps required for Exporting a VM which is
> running, for now its the only Solution for a Backup, I think.

We are working to allow downloading and uploading VMs as OVAs.
The download\upload api we have in 4.1 is the basis for this.

Export domain will be gone, but backup in another storage domain you only need to clone the VMs to that storage and it can be attached and detached like export domain to another systems.

You can also create a script based on this via SDK.
I'll re-purpose this RFE to track VM download.

Comment 5 Daniel Erez 2017-12-04 14:43:23 UTC

@Arik - do we need requires_doc_text here? Will it be ready for 4.2?

Comment 6 Arik 2017-12-20 11:23:04 UTC

A separate RFE was opened for downloading templates as OVA files: bz 1526033

Comment 7 RHV bug bot 2018-01-05 16:57:35 UTC

INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No external trackers attached]

For more info please contact: infra

Comment 8 RHV bug bot 2018-01-12 14:38:55 UTC

INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No external trackers attached]

For more info please contact: infra

Comment 9 RHV bug bot 2018-01-18 17:38:56 UTC

INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No external trackers attached]

For more info please contact: infra

Comment 10 RHV bug bot 2018-01-24 22:07:39 UTC

INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No external trackers attached]

For more info please contact: infra

Comment 11 RHV bug bot 2018-01-30 11:22:43 UTC

INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No external trackers attached]

For more info please contact: infra

Comment 12 RHV bug bot 2018-02-02 22:05:19 UTC

INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No external trackers attached]

For more info please contact: infra

Comment 13 Nisim Simsolo 2018-02-07 10:05:51 UTC

Reassigned, fix is not included yet in pack_ova.py 
Build: rhvm-4.2.1.6-0.1.el7

Comment 14 Yaniv Kaul 2018-03-15 06:48:26 UTC

Does it need backport to 4.2.x?

Comment 15 Arik 2018-03-19 08:13:29 UTC

(In reply to Yaniv Kaul from comment #14)
> Does it need backport to 4.2.x?

Merged before branching 4.2 so the fix is already available for quite a while.

Comment 16 Nisim Simsolo 2018-03-26 07:26:45 UTC

Verified:
rhvm-4.2.2.5-0.1.el7
libvirt-client-3.9.0-14.el7_5.2.x86_64
qemu-kvm-rhev-2.10.0-21.el7_5.1.x86_64
vdsm-4.20.23-1.el7ev.x86_64
sanlock-3.6.0-1.el7.x86_64

Verification scenario:
Polarion test plan added to external trackers

Comment 17 Sandro Bonazzola 2018-03-29 10:57:41 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.