yahoo-eng-team team mailing list archive

[Kashyap Chamarthy <kchamart@xxxxxxxxxx>]

Public bug reported:

Background
----------

QEMU supports two main variants of "machine type" (think of it as a
virtual chipset) for x86 hosts: (a) 'pc', which corresponds to Intel's
'i440FX' chipset; and (b) 'q35', which corresponds to Intel's 82Q35
chipset.  (For AArch64 hosts, the machine type is called: 'virt')

The 'q35' machine type provides some advanced features by default:
native PCIe hotplug (which is faster than ACPI-based hotplug, which
older 'pc' machine type uses), IOMMU, faster SATA emulation, Secure Boot
and so forth.  (Details: https://wiki.qemu.org/images/4/4e/Q35.pdf)


Proposed change
---------------

QEMU plans to change the default machine type to 'q35', so that they can
get rid of the legacy machine type 'pc'.  Nova should be prepared to not
break when that happens.  (Refer the "What will break?" section below.)


How does Nova handle machine types today?
-----------------------------------------

Nova by default does *not* hard-code any machine type; it just uses
whatever libvirt provides it by default.  But Nova allows configuring
machine type in two ways:

  (1) Disk image metadata property, so that when you boot a guest from
      that disk image, it gets the configured machine type:
      
        $ openstack image set \
            --property hw_machine_type=x86_64=pc-i440fx-2.9 Fedora-28-Template

  (2) Per-Compute host configuration file, so that _all_ guests launched
      on that host gets the configured machine type:

       [libvirt]
       ...
       hw_machine_type=x86_64=q35


What will break?
----------------

>From a discussion with libvirt and QEMU developers (thanks: Eduardo
Habkost, Daniel Berrangé), management applications like Nova will
break _only_ if we have a code pattern like:

   if guest machine type == q35:
       ... do something 'q35' related ...
   else:
       ... do something 'pc' related ...

As the above code pattern assumes that not providing a machine type will
result in 'pc'.  So we should avoid such a pattern.

Auditing the Nova code[+], we precisely have the above pattern when
configuring PCIe ports (from nova/virt/libvirt/driver.py,
_get_guest_config() function):

        [...]   
        # Add PCIe root port controllers for PCI Express machines
        # but only if their amount is configured
        if (CONF.libvirt.num_pcie_ports and
                ((caps.host.cpu.arch == fields.Architecture.AARCH64 and
                guest.os_mach_type.startswith('virt')) or
                (caps.host.cpu.arch == fields.Architecture.X86_64 and
                guest.os_mach_type is not None and
                'q35' in guest.os_mach_type))):
            self._guest_add_pcie_root_ports(guest)
        [...]   

The above code is assuming when 'guest.os_mach_type' == None, then you
have 'pc' machine type -- which is _not_ going to be valid in the
future.

To fix this, Nova needs to make sure 'guest.os_mach_type' is always set.


[*] http://git.openstack.org/cgit/openstack/nova/commit/?id=a234bbf8 --
    Allow to configure amount of PCIe ports

** Affects: nova
     Importance: Undecided
         Status: New

-- 
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/1780138

Title:
  Gracefully handle when QEMU switches its default machine to 'q35'

Status in OpenStack Compute (nova):
  New

Bug description:
  Background
  ----------

  QEMU supports two main variants of "machine type" (think of it as a
  virtual chipset) for x86 hosts: (a) 'pc', which corresponds to Intel's
  'i440FX' chipset; and (b) 'q35', which corresponds to Intel's 82Q35
  chipset.  (For AArch64 hosts, the machine type is called: 'virt')

  The 'q35' machine type provides some advanced features by default:
  native PCIe hotplug (which is faster than ACPI-based hotplug, which
  older 'pc' machine type uses), IOMMU, faster SATA emulation, Secure Boot
  and so forth.  (Details: https://wiki.qemu.org/images/4/4e/Q35.pdf)

  
  Proposed change
  ---------------

  QEMU plans to change the default machine type to 'q35', so that they can
  get rid of the legacy machine type 'pc'.  Nova should be prepared to not
  break when that happens.  (Refer the "What will break?" section below.)

  
  How does Nova handle machine types today?
  -----------------------------------------

  Nova by default does *not* hard-code any machine type; it just uses
  whatever libvirt provides it by default.  But Nova allows configuring
  machine type in two ways:

    (1) Disk image metadata property, so that when you boot a guest from
        that disk image, it gets the configured machine type:
        
          $ openstack image set \
              --property hw_machine_type=x86_64=pc-i440fx-2.9 Fedora-28-Template

    (2) Per-Compute host configuration file, so that _all_ guests launched
        on that host gets the configured machine type:

         [libvirt]
         ...
         hw_machine_type=x86_64=q35

  
  What will break?
  ----------------

  From a discussion with libvirt and QEMU developers (thanks: Eduardo
  Habkost, Daniel Berrangé), management applications like Nova will
  break _only_ if we have a code pattern like:

     if guest machine type == q35:
         ... do something 'q35' related ...
     else:
         ... do something 'pc' related ...

  As the above code pattern assumes that not providing a machine type will
  result in 'pc'.  So we should avoid such a pattern.

  Auditing the Nova code[+], we precisely have the above pattern when
  configuring PCIe ports (from nova/virt/libvirt/driver.py,
  _get_guest_config() function):

          [...]   
          # Add PCIe root port controllers for PCI Express machines
          # but only if their amount is configured
          if (CONF.libvirt.num_pcie_ports and
                  ((caps.host.cpu.arch == fields.Architecture.AARCH64 and
                  guest.os_mach_type.startswith('virt')) or
                  (caps.host.cpu.arch == fields.Architecture.X86_64 and
                  guest.os_mach_type is not None and
                  'q35' in guest.os_mach_type))):
              self._guest_add_pcie_root_ports(guest)
          [...]   

  The above code is assuming when 'guest.os_mach_type' == None, then you
  have 'pc' machine type -- which is _not_ going to be valid in the
  future.

  To fix this, Nova needs to make sure 'guest.os_mach_type' is always
  set.

  
  [*] http://git.openstack.org/cgit/openstack/nova/commit/?id=a234bbf8 --
      Allow to configure amount of PCIe ports

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