15.5. Updating the default machine type for hosts after an upgrade to RHOSP 17
The machine type of an instance is a virtual chipset that provides certain default devices, such as a PCIe graphics card or Ethernet controller. Cloud users can specify the machine type for their instances by using an image with the hw_machine_type metadata property that they require.
Cloud administrators can use the Compute parameter NovaHWMachineType to configure each Compute node architecture with a default machine type to apply to instances hosted on that architecture. If the hw_machine_type image property is not provided when launching the instance, the default machine type for the host architecture is applied to the instance. Red Hat OpenStack Platform (RHOSP) 17 is based on RHEL 9. The pc-i440fx QEMU machine type is deprecated in RHEL 9, therefore the default machine type for x86_64 instances that run on RHEL 9 has changed from pc to q35. Based on this change in RHEL 9, the default value for machine type x86_64 has also changed from pc in RHOSP 16 to q35 in RHOSP 17.
From RHOSP 16.2 and later, the Compute (nova) service records the instance machine type within the system metadata of the instance when it launches an instance. This means that it is now possible to change the NovaHWMachineType during the lifetime of a RHOSP deployment without affecting the machine type of existing instances.
The Compute service records the machine type of instances that are not in a SHELVED_OFFLOADED state. Therefore, after an upgrade to RHOSP 17 you must manually record the machine type of instances that are in SHELVED_OFFLOADED state, and verify that all instances within the environment or specific cell have had a machine type recorded. After you have updated the system metadata for each instance with the machine types, you can update the NovaHWMachineType parameter to the RHOSP 17 default, q35, without affecting the machine type of existing instances.
From RHOSP OSP17.0 onwards, Q35 is the default machine type. The Q35 machine type uses PCIe ports. You can manage the number of PCIe port devices by configuring the heat parameter NovaLibvirtNumPciePorts. The number of devices that can attach to a PCIe port is fewer than instances running on previous versions. If you want to use more devices, you must use the hw_disk_bus=scsi or hw_scsi_model=virtio-scsi image property. For more information, see Metadata properties for virtual hardware.
Prerequisites
- You have upgraded all Compute nodes to RHEL 9.2. For more information about upgrading Compute nodes, see Upgrading all Compute nodes to RHEL 9.2.
- You have updated any image properties that specified IDE to SATA or SCSI because the IDE bus is not supported with q35. For more information about how to update the image properties, see Updating the machine type to q35.
Procedure
-
Log in to the undercloud as the
stackuser. Source the
stackrcfile.$ source ~/stackrcLog in to a Controller node as the
heat-adminuser:(undercloud)$ metalsmith list $ ssh heat-admin@<controller_ip>Replace
<controller_ip>with the IP address of the Controller node.Retrieve the list of instances that have no machine type set:
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt list_unset_machine_typeCheck the
NovaHWMachineTypeparameter in thenova-hw-machine-type-upgrade.yamlfile for the default machine type for the instance host. The default value for theNovaHWMachineTypeparameter in RHOSP 16.2 is as follows:x86_64=pc-i440fx-rhel7.6.0,aarch64=virt-rhel7.6.0,ppc64=pseries-rhel7.6.0,ppc64le=pseries-rhel7.6.0Update the system metadata of each instance with the default instance machine type:
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt update_machine_type <instance_uuid> <machine_type>-
Replace
<instance_uuid>with the UUID of the instance. Replace
<machine_type>with the machine type to record for the instance.주의If you set the machine type to something other than the machine type of the image on which the instance was booted, the existing instance might fail to boot.
-
Replace
Confirm that the machine type is recorded for all instances:
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-status upgrade checkThis command returns a warning if an instance is found without a machine type. If you get this warning, repeat this procedure from step 4.
-
Change the default value of
NovaHWMachineTypein a Compute environment file tox86_64=q35and deploy the overcloud.
Verification
Create an instance that has the default machine type:
(overcloud)$ openstack server create --flavor <flavor> \ --image <image> --network <network> \ --wait defaultMachineTypeInstance-
Replace
<flavor>with the name or ID of a flavor for the instance. -
Replace
<image>with the name or ID of an image that does not sethw_machine_type. -
Replace
<network>with the name or ID of the network to connect the instance to.
-
Replace
Verify that the instance machine type is set to the default value:
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt get_machine_type <instance_uuid>Replace
<instance_uuid>with the UUID of the instance.Hard reboot an instance with a machine type of
x86_64=pc-i440fx:(overcloud)$ openstack server reboot --hard <instance_uuid>Replace
<instance_uuid>with the UUID of the instance.Verify that the instance machine type has not been changed:
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt get_machine_type <instance_uuid>Replace
<instance_uuid>with the UUID of the instance.