yahoo-eng-team team mailing list archive

[OpenStack Infra <1607400@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/348394
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=363710b655434a15b6b85d9ca65343210b104e56
Submitter: Zuul
Branch:    master

commit 363710b655434a15b6b85d9ca65343210b104e56
Author: Dirk Mueller <dirk@xxxxxxxx>
Date:   Thu Jul 28 16:39:19 2016 +0200

    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@xxxxxxxxxx>
    Closes-Bug: 1607400
    Closes-Bug: 1825386
    blueprint: allow-secure-boot-for-qemu-kvm-guests
    Signed-off-by: Kashyap Chamarthy <kchamart@xxxxxxxxxx>
    Change-Id: I28afdb09d300be39981606d5234fd837ea738e1d


** Changed in: nova
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1607400

Title:
  UEFI not supported on SLES

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Launching an image with UEFI bootloader on a SLES 12 SP1 instances
  gives

  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800] Traceback (most recent call last):
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2218, in _build_resources
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]     yield resources
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2064, in _build_and_run_instance
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]     block_device_info=block_device_info)
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2777, in spawn
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]     write_to_disk=True)
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4730, in _get_guest_xml
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]     context)
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4579, in _get_guest_config
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]     root_device_name)
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4401, in _configure_guest_by_virt_type
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800]     raise exception.UEFINotSupported()
  2016-07-28 08:23:12.820 3224 ERROR nova.compute.manager [instance: 5289d6f7-f4f5-4f95-bd55-4812ec3ab800] UEFINotSupported: UEFI is not supported

  this is because the function probes for files that are in different
  locations on SLES, namely it looks for "/usr/share/OVMF/OVMF_CODE.fd"
  / /usr/share/AAVMF/AAVMF_CODE.fd which are the documented upstream
  defaults. However the SLES libvirt is compiled to default to different
  paths, that exist.

  one possibility would be to introspect domCapabilities from libvirt,
  which works just fine. An alternative patch is to just add the
  alternative paths for now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1607400/+subscriptions