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
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?
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.
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.
(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.
@Arik - do we need requires_doc_text here? Will it be ready for 4.2?
A separate RFE was opened for downloading templates as OVA files: bz 1526033
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
Reassigned, fix is not included yet in pack_ova.py Build: rhvm-4.2.1.6-0.1.el7
Does it need backport to 4.2.x?
(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.
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
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.