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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
