Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
libvirt: Handle alternative UEFI firmware binary paths
The OVMF binary paths differ based on the Linux distribution: - Debian and Ubuntu: - /usr/share/OVMF/OVMF_CODE.fd - Fedora: - /usr/share/edk2/ovmf/OVMF_CODE.fd (`symlink`s to /usr/share/OVMF/OVMF_CODE.fd) - /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd (`symlink`s to /usr/share/OVMF/OVMF_CODE.secboot.fd) - CentOS and RHEL: - /usr/share/OVMF/OVMF_CODE.secboot.fd - SUSE: - /usr/share/qemu/ovmf-x86_64-opensuse-code.bin Currently, Nova only checks for one location OVMF_CODE.fd. Let's also check for the other two common distributions, SUSE and CentOS OVMF binary paths. This is a short-term solution to fix two bugs. In the long run: - We will get rid of the "DEFAULT_UEFI_LOADER_PATH", which is used to probe for firmware file paths. Instead, we'll use the more robust approach of the recently introduced[1] get_domain_capabilities()[1] to query for the firmware binary paths (as reported in the 'loader' attribute). - Use libvirt's (>=5.3) firmware auto-selection feature. Which is a more robust way to decide UEFI boot (secure or otherwise). More details of it in the spec here[2]. [1] https://opendev.org/openstack/nova/commit/297f3ba687 -- Add infrastructure for invoking libvirt's getDomainCapabilities API [2] http://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html Co-Authored-By: Kashyap Chamarthy <kchamart@redhat.com> Closes-Bug: 1607400 Closes-Bug: 1825386 blueprint: allow-secure-boot-for-qemu-kvm-guests Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Change-Id: I28afdb09d300be39981606d5234fd837ea738e1d
- Loading branch information