Bug 1528724 - Import ova playbooks assume that ovf comes first in OVA
Summary: Import ova playbooks assume that ovf comes first in OVA
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ovirt-4.2.1
: ---
Assignee: Arik
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-22 23:53 UTC by Dan Kenigsberg
Modified: 2018-03-29 10:47 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-03-29 10:47:31 UTC
oVirt Team: Virt
Embargoed:
michal.skrivanek: ovirt-4.2?
rule-engine: blocker?
michal.skrivanek: planning_ack?
rule-engine: devel_ack+
mavital: testing_ack+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 85784 0 master MERGED core: do not assume ovf to be the first entry of ova 2017-12-28 08:08:25 UTC

Description Dan Kenigsberg 2017-12-22 23:53:21 UTC 
Description of problem:
Engine fails to import formerly-importable OVA because it assumes that first element in tarball is ovf.

Version-Release number of selected component (if applicable):
ovirt-engine-4.2.1-0.0.master.20171221141808.git6835552.el7.centos.noarch

How reproducible:
100%
Comment 1 Michal Skrivanek 2017-12-23 07:44:22 UTC 
Any example? Such OVAs are invalid
Comment 2 Dan Kenigsberg 2017-12-23 12:27:26 UTC 
I received https://drive.google.com/a/redhat.com/file/d/0BxpLE_1jmZyFSlMwRTdSMW5JaEE/ from Kun Wei as a reproducer for bug 1503947. I believe that this is something that ESX has generated, and that orders of files in a tarball should not be trusted (regardless of what vmware does).
Comment 3 Michal Skrivanek 2017-12-27 14:47:08 UTC 
WA is to repack the OVA to adhere to standard with OVF file being the first in the archive
Comment 4 Red Hat Bugzilla Rules Engine 2017-12-27 14:47:14 UTC 
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Comment 5 Nisim Simsolo 2018-02-27 13:10:47 UTC 
Verification builds:
rhvm-4.2.2.1-0.1.el7
sanlock-3.6.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-19.el7.x86_64
libvirt-client-3.9.0-13.el7.x86_64
virt-v2v-1.36.10-6.el7.x86_64

Verification scenario:
1. Extract OVA file using tar xvf
2. Pack it again in a way that the OVF is not in the first entry, for example:
# tar cvf rhel7.ova rhel7.mf rhel7-disk1.vmdk rhel7.ovf
3. Import new OVA.

Verify OVA imported successfully.
validate VM configuration and parameters are correct.
Run VM and verify VM is running properly.
Comment 6 Sandro Bonazzola 2018-03-29 10:47:31 UTC 
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.1 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.
Note You need to log in before you can comment on or make changes to this bug.