Please provide engine.log and the relevant ovirt-export-ova-ansible-*.log (in engine.log you can find the specific log file that was created as part of the failed operation).

Created attachment 1422230 [details]
Ansible log from OVA export attempt noted in bug report

Hostname sanitized to ***.example.com

Created attachment 1422231 [details]
Relevant section of engine.log

Just based on what I saw in uploading these logs, it seems like the Python script bugged out on a non-ASCII character in the OVF XML:
```
Traceback (most recent call last):
  File "/root/.ansible/tmp/ansible-tmp-1523735896.19-40291427300158/pack_ova.py", line 94, in <module>
    write_ovf(ova_path, ovf)
  File "/root/.ansible/tmp/ansible-tmp-1523735896.19-40291427300158/pack_ova.py", line 33, in write_ovf
    ovf = ovf.encode('utf-8')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3092: ordinal not in range(128)
```

As for why there would be any non-ASCII characters, it seems like oVirt is including the list of applications (as reported by the QEMU or oVirt guest agents in Windows) in the XML, and somewhere in that mess there are glyphs with diacritical marks that require UTF-8 handling, e.g.
```
<ProductSection ovf:class="2016"><Info>Herramientas de corrección de Microsoft Office 2016: español</Info><Product>2016</Product><Version></Version></ProductSection>
```

Note that the guest OS is using English (United States); these parts of the OVF result from having Microsoft Office installed. The oVirt engine and virtualization host both have $LANG=en_US.UTF-8 as is default for a North American installation of CentOS, and Python is the system default (python-2.7.5-58.el7.x86_64).

(In reply to Frederick Ding from comment #4)
Right, nice analysis.
I wonder whether we should store the application list in OVFs that reside within OVAs.

Anyway, for now, you can just clear the application list and then export the VM:
> update vm_dynamic set app_list=NULL where vm_guid='eb6353ef-7ce4-42c9-91e2-eed53a3e211b';

(In reply to Arik from comment #5)
> (In reply to Frederick Ding from comment #4)
> Right, nice analysis.
> I wonder whether we should store the application list in OVFs that reside
> within OVAs.
> 
> Anyway, for now, you can just clear the application list and then export the
> VM:
> > update vm_dynamic set app_list=NULL where vm_guid='eb6353ef-7ce4-42c9-91e2-eed53a3e211b';

So the OVF specification declares that some elements could be localized, so apparently, that's a mistake to try to encode it with 'utf-8'...

It's my understanding that Python 2 treats strings just as bytes -- and pack_ova.py ingests the OVF as `ovf = sys.argv[2]`. So there may be no need to use `ovf = ovf.encode('utf-8')` at all?

(In reply to Frederick Ding from comment #7)
> It's my understanding that Python 2 treats strings just as bytes -- and
> pack_ova.py ingests the OVF as `ovf = sys.argv[2]`. So there may be no need
> to use `ovf = ovf.encode('utf-8')` at all?

The posted fix removes the UTF-8 encoding.

Verification builds:
rhvm-4.2.3.2-0.1.el7
vdsm-4.20.26-1.el7ev.x86_64
libvirt-client-3.9.0-14.el7_5.2.x86_64
sanlock-3.6.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-21.el7_5.2.x86_64
virt-v2v-1.36.10-6.6.rhvpreview.el7ev.x86_64

Verification scenario:
1. Export VM as OVA which its name,description and comment is encoded to UTF-8 (Rename VM name to Hebrew and add comment and description in Hebrew).
2. Remove VM and Import OVA.
3. Verify import succeeds. Run VM and verify Vm is running properly.
4. Repeat steps 1-3, this time export VM as OVA to NFS storage and import OVA as clone.

This bugzilla is included in oVirt 4.2.3 release, published on May 4th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.3 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.