Comment 0 for bug 1780138

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