Description of problem: Although BIOS type in exported OVF is correct (https://bugzilla.redhat.com/show_bug.cgi?id=1845458#c2) and the cluster compatibility version of the imported VM is the same as the cluster we import to, after importing the OVA, it will change to cluster default settings. For example, after importing OVA of RHEL 8 with Q35 and SecureBoot BIOS type, to a clusetr with cluster default settings (Q35 with seabios) The VM BIOS type will now be Q35 with seabios instead of Q35 with SecureBoot BIOS. Version-Release number of selected component (if applicable): ovirt-engine-4.4.1.8-0.7.el8ev vdsm-4.40.22-1.el8ev.x86_64 libvirt-daemon-6.0.0-25.module+el8.2.1+7154+47ffd890.x86_64 qemu-kvm-4.2.0-29.module+el8.2.1+7297+a825794d.x86_64 How reproducible: Alwayes Steps to Reproduce: 1. Export VM (under default cluster with compatibility version 4.4) with Q35 and SecureBoot BIOS type as OVA 2. Import OVA to the same cluster. 3. Try to run VM. Actual results: VM BIOS type is now cluster default. VM failed to boot from disk. Expected results: VM BIOS type should be equal to the one in OVF file. Additional info: vdsm.log, engine.log and OVA ansible logs attached (import started at 2020-07-15 09:40:44)
Created attachment 1701179 [details] vdsm.log
Created attachment 1701180 [details] engine.log
Created attachment 1701181 [details] ovirt-export-ova-ansible
Created attachment 1701182 [details] ovirt-import-ova-ansible
Should be solved by the fix for bz 1855001, not closing as duplicate because it's a bit different flow (OVA rather than v2v)
Reassigned: ovirt-engine-4.4.2.4-0.1.el8ev vdsm-4.40.26.1-1.el8ev.x86_64 libvirt-daemon-6.0.0-25.2.module+el8.2.1+7722+a9e38cf3.x86_64 qemu-kvm-4.2.0-29.module+el8.2.1+7712+3c3fe332.2.x86_64 Reason: Same behavior as described in https://bugzilla.redhat.com/show_bug.cgi?id=1857148#c0 Comparing domxml of imported VM (from OVA) to source VM (exported as OVA): Imported: <os> <type arch='x86_64' machine='pc-q35-rhel8.2.0'>hvm</type> <smbios mode='sysinfo'/> </os> Source VM: <os> <type arch='x86_64' machine='pc-q35-rhel8.2.0'>hvm</type> <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader> <nvram template='/usr/share/OVMF/OVMF_VARS.secboot.fd'>/var/lib/libvirt/qemu/nvram/1abede2e-d49c-4f48-bf63-fbcc80ab33df.fd</nvram> <smbios mode='sysinfo'/> </os>
(In reply to Nisim Simsolo from comment #6) Did the Engine build contain this change https://gerrit.ovirt.org/#/c/110880/ ? I've just tested exporting/importing a SecureBoot VM with it and the result is correct.
(In reply to Shmuel Melamud from comment #7) > (In reply to Nisim Simsolo from comment #6) > > Did the Engine build contain this change > https://gerrit.ovirt.org/#/c/110880/ ? I've just tested exporting/importing > a SecureBoot VM with it and the result is correct. In which engine build does this change included?
ok, so this bug shouldn't have switched to on_qa as it depends on bz 1726558, switching back to modified
Verified: ovirt-engine-4.4.3.5-0.5.el8ev qemu-kvm-5.1.0-10.module+el8.3.0+8254+568ca30d.x86_64 vdsm-4.40.32-1.el8ev.x86_64 libvirt-daemon-6.6.0-6.module+el8.3.0+8125+aefcf088.x86_64
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.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.