Bug 1693571

Created attachment 1548899 [details]
ovirt-engine.log

Created attachment 1548900 [details]
Configuration for import vm from VMware

Created attachment 1548901 [details]
The wrong BIOS type page

Created attachment 1548902 [details]
VM failed to boot up page

I'm not seeing the expected ‘pflash’ parameters.

the integrated import is not using the OVF output and creates the VM beforehand, it's missing there

Hi all,
I can also reproduce this issue when i try to IMPORT a VM to rhv via "KVM (Via Libvirt)" method.

Packages:
libvirt-4.5.0-12.el7.x86_64
libguestfs-1.40.2-3.el7.x86_64
virt-v2v-1.40.2-3.el7.x86_64
qemu-kvm-rhev-2.12.0-26.el7.x86_64
python-ovirt-engine-sdk4-4.3.1-1.el7ev.x86_64
OVMF-20180508-6.gitee3198e672e2.el7.noarch


rhv4.3: ovirt-engine-4.3.0.1-0.1.el7.noarch


Steps to Reproduce:
1. Prepare a vm with Q35 machine type.
...
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/rhel7.6-uefi_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
...

2. Setup tcp env on kvm host
#vi /etc/sysconfig/libvirtd and remove # for LIBVIRTD_ARGS="--listen"
#vi /etc/libvirt/libvirtd.conf and remove # for listen_tcp = 1 and listen_tls = 0
#vi /etc/libvirt/libvirtd.conf and remove # for auth_tcp = "sasl" and change "sasl" to "none"
#service libvirtd restart

Disable firewall on kvm server
#service firewalld stop

3. Login with administration portal, System->Virtual Machines. 

4. Click "Import" button, then "Import Virtual Machine(s)" window pop up. Then you can choose "Data Center" and "Source" which you want to use.
Data Center
Source:Export Domain
            Virtual Appliance (OVA)           
            XEN (Via RHEL)
            KVM (Via Libvirt)
            VMware

5. Select KVM as source and complete details information as Screenshot attached, then click "Load" button.

6. After load, then select vm "rhel7.7-uefi" in "Virtual Machines on Source" to import, then click "OK" in next page, then guest import start.

Results:
6.1 Import vm from KVM finished successfully.
6.2 VM failed to boot up, the BIOS type is set as 'default'.

Created attachment 1556094 [details]
screenshot for import vm via kvm

I'm unclear why libvirt is involved here.  Virt-v2v -o vdsm writes an OVF file to a
particular location.  You can find the exact OVF file that is written by looking at
the end of the import log file attached to this bug.  It contains the <BiosType>
field and as far as I'm concerned VDSM ought to be reading the file and not
asking libvirt for anything.

I dont' see a reason why you can't take the final OVF and "Edit" the VM, we have UpdateConvertedVmCommand for that....

(In reply to Michal Skrivanek from comment #22)
> I dont' see a reason why you can't take the final OVF and "Edit" the VM, we
> have UpdateConvertedVmCommand for that....

Well the issues are as follows:

1. If we just take the Bios Type from the final OVF which only comes when the import has completed, the user can see that the Bios Type is the default until the import completely ends. So the question here is if it is enough.
2. The OVF files do not currently have the Bios Type so it would need to be added to the file.
3. Then the engine would have to extract the Bios Type from the return of the getConvertedVm() function.


If we agree we can live with the Bios Type being incorrect until the "final OVF" than we can eliminate item 1. 

We still have Item 2 in order for Item 3 to work.

We can avoid finalizing the import until it's complete, which we should do anyway (as this is tracked as an event inside the engine), so we can live with 1 as long as we block

In Richard's last comment, it looks like BiosType is present in the OVF. If it isn't in your tests, do you have one I can look at? I don't have a VMware environment to check

Created attachment 1559943 [details]
Example ovf file from VMWare Importing

This is an example ovf file I created during VMWare Importing. I do not see a Bios Type field nor the expected Bios Type as we see in the log.

(In reply to Ryan Barry from comment #24)
> We can avoid finalizing the import until it's complete, which we should do
> anyway (as this is tracked as an event inside the engine), so we can live
> with 1 as long as we block
> 
> In Richard's last comment, it looks like BiosType is present in the OVF. If
> it isn't in your tests, do you have one I can look at? I don't have a VMware
> environment to check

https://bugzilla.redhat.com/show_bug.cgi?id=1693571#c25

(In reply to Ryan Barry from comment #24)
> We can avoid finalizing the import until it's complete, which we should do
> anyway (as this is tracked as an event inside the engine), so we can live
> with 1 as long as we block
> 
> In Richard's last comment, it looks like BiosType is present in the OVF. If
> it isn't in your tests, do you have one I can look at? I don't have a VMware
> environment to check

Actually though the point is we do not "block", the user can still enter the VM details screen and the edit during the importing and see the details received from the initial details message (what Richard seems to call -o vdsm mode) and thus that the Bios Type is the Default before the import has completed. Again I can always implement the ovf prart, assuming we are able to obtain the Bios Type from the ovf file (I have attached what I have).

>  <!-- generated by virt-v2v 1.36.10rhel=7,release=6.el7_5.2,libvirt -->

This version is older than the one which supports BiosType.  You need >= 1.39.12
(upstream), and I'm not sure of the RHEL version but the latest version for
RHEL 7.7 is libguestfs-1.40.2-4.el7 which should contain this.

Thanks Richard -

Steven, safe enough. 4.3.5 should be 7.7. Can you put libguestfs from 7.7 (fetched from brew) on your environment for testing?

(In reply to Ryan Barry from comment #29)
> Thanks Richard -
> 
> Steven, safe enough. 4.3.5 should be 7.7. Can you put libguestfs from 7.7
> (fetched from brew) on your environment for testing?

I recently installed a Host from the master and it gave me:

libguestfs.x86_64                        1:1.38.2-12.el7_6.2

Which according to you is still too low. What is the date of the libguestfs 1.39.12 and is it available yet for installing from the current master:

https://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm

Dated April 29, 2019? 
  

This is how I am currently installing hosts.

I have checked now and there was no BZ filed for the BiosType feature so it was never
backported.  Instead we got it in the rebase in RHEL 7.7.  So you will need
libguestfs >= 1.40 for RHEL 7.7 (from brew).

After some investigation it seems it is not advisable to mix versions and this issue is specifically for oVirt, not Rhel. As per our conversation please confirm.

This issue has been addressed by obtaining the Bios Type from the ovf file during post conversion as per Michal's suggestion in using the UpdateConvertedVmCommand module. This means that the Bios Type will only be updated when:

1. The import is VMWare and possibly Xen. KVM does not use the Post Convert update VM functionality and will not be supported via this change.
2. When the libguestfs' version is at least 1.40. Older versions do not include the Bios Type update within the ovf file.
3. Only after the File Conversion has been completed, which means that during import, the VM details and edit functionality will display the default which is i440fx/seabios.

To resolve Items 1 and 3, the getExternalVMs response message would need to include the Bios Type and the oVirt engine modified accordingly.
To resolve Item 2, one would need to upgrade the libguestfs version which currently needs to be back ported to the upstream for this implementation to work.

*** Bug 1675721 has been marked as a duplicate of this bug. ***

Reassigned: 
- Although import of VMware VM with EFI BIOS succeeds, the BIOS type and custom emulated machine of the imported VM remains default (in my case it's default BIOS and pc-i440fx).
- Running the imported VM will get stuck in "booting from hard disk" phase and will never complete boot.
- Changing BIOS and emulated machine type manually from WebAdmin to Q35 with UEFI BIOS is solving the boot issue.

Verification builds:
host and engine are running on RHEL 7.7 Beta (Maipo)
rhvm-4.3.5-0.1.el7
vdsm-4.30.19-1.el7ev.x86_64
virt-v2v-1.40.2-5.el7.x86_64
libguestfs-1.40.2-5.el7.x86_64
qemu-kvm-rhev-2.12.0-32.el7.x86_64
libvirt-4.5.0-22.el7.x86_64

vdsm.log, engine.log and import.log attached.
VM name which changed to Q35 with UEFI BIOS is RHEL77_Beta_EFI

Created attachment 1582261 [details]
reassigned: vdsm.log

Created attachment 1582264 [details]
reassigned: engine.log

Created attachment 1582265 [details]
reassigned: import.log

(In reply to Nisim Simsolo from comment #39)
> Reassigned: 
> - Although import of VMware VM with EFI BIOS succeeds, the BIOS type and
> custom emulated machine of the imported VM remains default (in my case it's
> default BIOS and pc-i440fx).
> - Running the imported VM will get stuck in "booting from hard disk" phase
> and will never complete boot.
> - Changing BIOS and emulated machine type manually from WebAdmin to Q35 with
> UEFI BIOS is solving the boot issue.
> 
> Verification builds:
> host and engine are running on RHEL 7.7 Beta (Maipo)
> rhvm-4.3.5-0.1.el7
> vdsm-4.30.19-1.el7ev.x86_64
> virt-v2v-1.40.2-5.el7.x86_64
> libguestfs-1.40.2-5.el7.x86_64
> qemu-kvm-rhev-2.12.0-32.el7.x86_64
> libvirt-4.5.0-22.el7.x86_64
> 
> vdsm.log, engine.log and import.log attached.
> VM name which changed to Q35 with UEFI BIOS is RHEL77_Beta_EFI

Back Ported to 4.3

Reassigned:
- Importing VMware VMs with EFI BIOS are now converted to "Q35 chipset with UEFI BIOS" as expected.
- But importing VMware VMs with EFI BIOS and secure boot enabled are converted also to "Q35 chipset with UEFI BIOS" instead of being converted to "Q35 chipset with SecureBoot".
In such case, the VM is running but without secured boot.
- Possible workaround is to manually change VM BIOS type from "Q35 chipset with UEFI BIOS" to "Q35 chipset with SecureBoot" before running the VM.
- VMs imported from VMware are with operating system type that works OOB when using secure boot (Windows 10 and Fedora 28).

Verification builds: 
rhvm-4.3.5.2-0.1.el7
vdsm-4.30.22-1.el7ev.x86_64
virt-v2v-1.40.2-5.el7.x86_64
libvirt-4.5.0-23.el7.x86_64
qemu-kvm-rhev-2.12.0-33.el7.x86_64

Verification scenario:
1. Import from VMware  Windows 10 VM and Fedora 28 VM with EFI BIOS and secure boot enabled.
2. After import completion, from WebAdmin -> Compute -> VMs -> edit VM -> system: observe VMs BIOS type.
3. Run VMs and verify VMs are running with secure boot.
4. Work around: power off VMs and change BIOS type to "Q35 chipset with SecureBoot". Run VMs.

Actual results:
2. BIOS type is  "Q35 chipset with UEFI BIOS" instead of "Q35 chipset with SecureBoot" on both VMs.
3. Both VMs are running without secure boot. 
An example from Windows PowerShell:
PS C:\Confirm-SecureBootUEFI
False

Import logs, vdsm.log and engine.log attached.
engine.log Windows import started at 2019-06-30 18:15:50,461+03, Fedora import started at 2019-06-30 13:36:05,056+03

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Created attachment 1586597 [details]
secure boot issue, engine.log

Created attachment 1586598 [details]
secure boot issue, vdsm.log

Created attachment 1586599 [details]
secure boot issue, vdsm.log

Created attachment 1586600 [details]
secure boot issue, Windows10 import.log

Created attachment 1586601 [details]
secure boot issue, Fedora28 import.log

If this works without secureboot enabled, let's pass it through and open a separate bug for secureboot, which isn't quite there yet

Verified:
rhvm-4.3.5.2-0.1.el7
vdsm-4.30.22-1.el7ev.x86_64
virt-v2v-1.40.2-5.el7.x86_64
libvirt-4.5.0-23.el7.x86_64
qemu-kvm-rhev-2.12.0-33.el7.x86_64

Verification scenario: 
Polarion test case added to external trackers.

This bugzilla is included in oVirt 4.3.5 release, published on July 30th 2019.

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