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:
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.
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: /wiki.qemu. org/images/ 4/4e/Q35. pdf)
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:/
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 libvirt/ driver. py,
configuring PCIe ports (from nova/virt/
_get_guest_config() function):
[...] 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)
# Add PCIe root port controllers for PCI Express machines
# but only if their amount is configured
if (CONF.libvirt.
[...]
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