Description of problem: When importing VMware OVA, the import succeed but using fallback. engine.log: 2018-01-15 14:20:33,204+02 ERROR [org.ovirt.engine.core.utils.ovf.OvfManager] (default task-15) [17739841-cb66-49af-ba2d-07919cbf6e5f] Error parsing OVF due to OVF error: RHEL 7_6: cannot read 'rasd:VirtualQuantity' with value: null 2018-01-15 14:20:33,210+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetOvaInfoVDSCommand] (default task-15) [17739841-cb66-49af-ba2d-07919cbf6e5f] START, GetOvaInfoVDS Command(HostName = intel_vGPU, GetOvaInfoParameters:{hostId='79786002-39a9-413f-b8a6-ab7752d77b2a', path='/home/nisim/RHEL7_6_extra'}), log id: 23ad6a03 Version-Release number of selected component (if applicable): rhvm-4.2.1.1-0.1.el7 qemu-kvm-rhev-2.9.0-16.el7_4.13.x86_64 libvirt-client-3.2.0-14.el7_4.7.x86_64 vdsm-4.20.13-1.el7ev.x86_64 sanlock-3.5.0-1.el7.x86_64 virt-v2v-1.36.3-6.el7_4.3.x86_64 How reproducible: 100% Steps to Reproduce: 1. Import VMware OVA or OVA folder 2. Observe engine.log 3. Actual results: Import VMware OVA using the new mechanism failed and import is moving to fallback mechanism. Expected results: OVA import should be done using the mechanism of OVF parsing. Additional info: engine.log attached
Created attachment 1381587 [details] engine.log, issue occured at: 2018-01-15 14:20:33,204+02 ERROR
That happens because we use different IDs for devices than the ones defined in the OVF specification for: Monitors - we use 20 while this identifier is used for SATA controllers in the specification (no identifier is set for monitors in the specification) Graphics - we use 26 while this identifier is used for "Partitionable Unit" in the specification (the identifier of graphics controllers in the specification is 24)
(In reply to Arik from comment #2) > Monitors - we use 20 while this identifier is used for SATA controllers in Actually not specifically to SATA controllers but to "Other storage device", we saw it used for SATA controllers in our tests.
Verification builds: rhvm-4.2.2.1-0.1.el7 vdsm-4.20.19-1.el7ev.x86_64 qemu-kvm-rhev-2.10.0-19.el7.x86_64 libvirt-client-3.9.0-13.el7.x86_64 sanlock-3.6.0-1.el7.x86_64 virt-v2v-1.36.10-6.el7.x86_64 Verification scenario: 1. Export RHV VM with SPICE and 4 monitors as OVA. 2. Export VMware VM with SATA controller as OVA. 3. Import both VMs. 4. Verify VMs imported successfully, validate correct VMs configuration. 5. Run both VMs and verify VMs are running properly.
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.