Description of problem: virt-launcher image do not have the edk2-ovmf package installed, which is required for UEFI testing with downstream CNV-2.0 Version-Release number of selected component (if applicable): kubevirt-manifests-0.14.0-0.gd126a38.99129b3.el8.noarch How reproducible: Install kubevirt from kubevirt-manifests packages from cnv-2.0. Steps to Reproduce: 1. create a VMI with UEFI support 2. The VM fails to start as the following file is not available, "/usr/share/edk2/ovmf/OVMF_VARS.fd" 3. Actual results: virt-launcher image do not have the edk2-ovmf package installed, Expected results: virt-launcher image should have the edk2-ovmf package installed and the file "/usr/share/edk2/ovmf/OVMF_VARS.fd" available. So that VMI Creation with UEFI support is possible. Additional info:
Created attachment 1545166 [details] edk2-ovmf package not present on 2.0.0-10 Attached the VMI and pod description. edk2-ovmf package not present on 2.0.0-10 Warning SyncFailed 7m virt-handler, cnv-executor-kbidarka2-node2.example.com server error. command Launcher.Sync failed: "LibvirtError(Code=1, Domain=10, Message='internal error: qemu unexpectedly closed the monitor: 2019-03-18T09:05:14.970078Z qemu-kvm: -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on: Could not open '/usr/share/OVMF/OVMF_CODE.fd': No such file or directory')"
2.0.0-10 virt-launcher image does not have edk2-ovmf package.
Installed kubevirt using the manifests from this particular package: kubevirt-0.15.0-7.gaabc787.432f91f.el8
This bug requested addition of the edk2-ovmf into the virt-launcher container. The log provided in Comment #2 indicates a failure in the virt-handler container. Please review and clarify which containers need this package.
Ah! I thought this was again from the virt-launcher, I missed to check it explicitly. I just checked virt-launcher pod does have edk2-ovmf package now. kbidarka ~ manifests_local oc rsh -c compute virt-launcher-vmi-fedora28-cloud-cores11-qsmgk sh-4.4# rpm -qav | grep -i ovmf edk2-ovmf-20180508gitee3198e672e2-5.el8+1789+f0947240.noarch sh-4.4# exit exit I saw the error and realized that we needed the package as it was specified here, https://github.com/kubevirt/kubevirt/pull/1814/files#diff-8a374b268e638a05647c4eb2cf62cdfeR24 I am not sure whether we need that for the virt-handler image, this feels like this would be another issue/bug.
Actually, I think this bug should stay open. The issue isn't really fixed as long as this isn't working. These paths are passed from virt-handler to virt-launcher: EFIPath = "/usr/share/OVMF/OVMF_CODE.fd" EFIVarsPath = "/usr/share/OVMF/OVMF_VARS.fd" So in upstream, the /OVMF directory contains these symlinks: 0 lrwxrwxrwx. 1 root root 25 Nov 16 08:33 OVMF_CODE.fd -> ../edk2/ovmf/OVMF_CODE.fd 0 lrwxrwxrwx. 1 root root 33 Nov 16 08:33 OVMF_CODE.secboot.fd -> ../edk2/ovmf/OVMF_CODE.secboot.fd 0 lrwxrwxrwx. 1 root root 25 Nov 16 08:33 OVMF_VARS.fd -> ../edk2/ovmf/OVMF_VARS.fd 0 lrwxrwxrwx. 1 root root 33 Nov 16 08:33 OVMF_VARS.secboot.fd -> ../edk2/ovmf/OVMF_VARS.secboot.fd 0 lrwxrwxrwx. 1 root root 26 Nov 16 08:33 UefiShell.iso -> ../edk2/ovmf/UefiShell.iso In the downstream image, only these symlinks are present: 0 lrwxrwxrwx. 1 root root 33 Sep 4 2018 OVMF_CODE.secboot.fd -> ../edk2/ovmf/OVMF_CODE.secboot.fd 0 lrwxrwxrwx. 1 root root 25 Sep 4 2018 OVMF_VARS.fd -> ../edk2/ovmf/OVMF_VARS.fd 0 lrwxrwxrwx. 1 root root 33 Sep 4 2018 OVMF_VARS.secboot.fd -> ../edk2/ovmf/OVMF_VARS.secboot.fd 0 lrwxrwxrwx. 1 root root 26 Sep 4 2018 UefiShell.iso -> ../edk2/ovmf/UefiShell.iso Essentially, we're missing the one for OVMF_CODE.fd (exactly as the error message says). David, do you know what populates these symlinks in the upstream image? Is it fair game to just create the missing one?
> David, do you know what populates these symlinks in the upstream image? Is it fair game to just create the missing one? These symlinks exist for us upstream and we aren't doing anything to generate them other than installing the rpms. If it doesn't exist, I don't see any harm in creating it. I'm not a maintainer of the edk2 package though, so I can't speak to the reasoning behind why that symlink doesn't exist downstream.
Missing symlink has been created.
Tested this with BM OCP4 and the below image hash tag turns out to be virt-launcher:v2.0.0-18 image [kbidarka@localhost manifests]$ oc describe pod virt-launcher-vmi-fedora29-efi-jbpsr | grep -A 3 "compute:" compute: Container ID: cri-o://4d7fce6ef884338a282fb9983a03e1ea36719ec5cb64f4bcd058cbafd80ded2e Image: brew.redhat.com:8888/container-native-virtualization/virt-launcher:v2.0.0 Image ID: brew.redhat.com:8888/container-native-virtualization/virt-launcher@sha256:7de129dd4cfe7725527b021d9cb820a0fdd275cb484f1ae7d7b4515609d04f1d ----------------------- kbidarka@localhost manifests]$ oc get pods NAME READY STATUS RESTARTS AGE virt-launcher-vmi-fedora28-cloud-cores11-nqrsd 2/2 Running 0 58m [kbidarka@localhost manifests]$ oc rsh -c compute virt-launcher-vmi-fedora28-cloud-cores11-nqrsd sh-4.4# ls -l /usr/share/OVMF total 0 lrwxrwxrwx. 1 root root 33 Sep 4 2018 OVMF_CODE.secboot.fd -> ../edk2/ovmf/OVMF_CODE.secboot.fd lrwxrwxrwx. 1 root root 25 Sep 4 2018 OVMF_VARS.fd -> ../edk2/ovmf/OVMF_VARS.fd lrwxrwxrwx. 1 root root 33 Sep 4 2018 OVMF_VARS.secboot.fd -> ../edk2/ovmf/OVMF_VARS.secboot.fd lrwxrwxrwx. 1 root root 26 Sep 4 2018 UefiShell.iso -> ../edk2/ovmf/UefiShell.iso sh-4.4# As seen from virt-launcher:v2.0.0-18 image, the symlink is still missing for "OVMF_CODE.fd -> ../edk2/ovmf/OVMF_CODE.fd"
When you ask libvirt to create the new domain, please use the following domain XML snippet: (1) In the long term, use the firmware auto-selection feature (BZ#1564270): <domain type='kvm'> <os firmware='efi'> <loader secure='yes'/> </os> </domain> This will give you a domain with the Secure Boot *feature* present in the firmware binary. Whether the new domain will have the Secure Boot *operational mode* enabled at once (with a set of certificates enrolled) depends on the host configuration. (2) In the short term (and assuming a RHEL8 host), use the following snippet: <domain type='kvm'> <os> <type arch='x86_64' machine='q35'>hvm</type> <loader readonly='yes' secure='yes' type='pflash' >/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader> <nvram template='${TEMPLATE}'/> </os> <features> <smm state='on'/> </features> </domain> and replace ${TEMPLATE} with one of: - /usr/share/edk2/ovmf/OVMF_VARS.secboot.fd -- if you'd like the SB operational mode to be enabled at once (with a set of certificates enrolled), - /usr/share/edk2/ovmf/OVMF_VARS.fd -- otherwise. (IIRC, this is also what libvirtd is configured to pick by default if you omit <nvram> element completely.)
Re-asking. Can we use the same OVMF_CODE-secboot.fd file for non-secureboot UEFI as well?
See the firmware metadata files in /usr/share/qemu/firmware. Per those files, valid combinations are - /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd with /usr/share/edk2/ovmf/OVMF_VARS.fd - /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd with /usr/share/edk2/ovmf/OVMF_VARS.secboot.fd
Fabian, the following two concepts need to be distinguished: #1 the Secure Boot feature (a set of software interfaces defined by the UEFI spec) #2 the Secure Boot operational mode (a system state when SB is enabled) The historical "OVMF_CODE.fd" is a firmware binary that lacks an actually-secure implementation of the "Secure Boot feature" (#1). Therefore it makes no sense to discuss (#2), in the scope of the historical "OVMF_CODE.fd" binary. "OVMF_CODE.secboot.fd" contains an actually-secure implementation of the "Secure Boot feature" (#1). Therefore enabling the SB operational mode (#2) is *possible*. It is not required. RHEL[78] only ship "OVMF_CODE.secboot.fd". They don't ship "OVMF_CODE.fd". In order to control the SB operational mode (#2) at domain creation, you can pick, as varstore template, "OVMF_VARS.fd" (which will not enable the SB mode), or "OVMF_VARS.secboot.fd" (which will enable SB mode). Your question in comment 19, "Can we use the same OVMF_CODE-secboot.fd file for non-secureboot UEFI as well", is ill-defined. If you mean a firmware binary that lacks the Secure Boot feature (#1), then the answer is "no". RHEL[78] only provide a firmware binary that contains (#1). If you mean a domain that uses a firmware binary with the Secure Boot Feature (#1) available, but with the Secure Boot operating mode (#2) disabled, then the answer is "yes". Use the variable store template "OVMF_VARS.fd".
NOTE: 1) In Openshift Virtualization setups, EFI with only secureBoot is supported. EFI with secureBoot set to false is not available. 2) Also secureBoot is set to True by default, when even using just "efi: {}" spec. firmware: bootloader: efi: {} is same as the below, ( secureBoot is set to True by default) firmware: bootloader: efi: secureBoot: True Verified with virt-operator/images/v2.4.0-53 and Centos-8 EFI image Virsh dumpxml had the below snippet. <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'>/tmp/default_vm-centos-efi-secureboot</nvram> <boot dev='hd'/> <smbios mode='sysinfo'/> </os> Tested with Centos-8 EFI image and we were able to see the /sys/firmware/efi/ , directory structure. [kbidarka@kbidarka-host secureboot]$ virtctl console vm-centos-efi-secureboot Successfully connected to vm-centos-efi-secureboot console. The escape sequence is ^] [cloud-user@vm-centos-efi-secureboot efi]$ [cloud-user@vm-centos-efi-secureboot efi]$ cd /sys/firmware/efi/ [cloud-user@vm-centos-efi-secureboot efi]$ ls config_table fw_platform_size runtime systab efivars fw_vendor runtime-map vars
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3194