15.4. RHOSP 17 へのアップグレード後のホストのデフォルトマシンタイプの更新
インスタンスのマシンタイプは、PCIe グラフィックスカードやイーサネットコントローラーなどの特定のデフォルトデバイスを提供する仮想チップセットです。クラウドユーザーは、必要な hw_machine_type メタデータプロパティーを持つイメージを使用して、インスタンスのマシンタイプを指定できます。
クラウド管理者は、コンピュートパラメーター NovaHWMachineType を使用して、各コンピュートノードアーキテクチャーをデフォルトのマシンタイプで設定し、そのアーキテクチャーでホストされているインスタンスに適用できます。インスタンスの起動時に hw_machine_type イメージプロパティーが指定されていない場合は、ホストアーキテクチャーのデフォルトのマシンタイプがインスタンスに適用されます。Red Hat OpenStack Platform (RHOSP) 17 は RHEL 9 をベースにしています。pc-i440fx QEMU マシンタイプは RHEL 9 で非推奨となったため、RHEL 9 で実行される x86_64 インスタンスのデフォルトのマシンタイプは pc から q35 に変更されました。RHEL 9 でのこの変更に基づいて、マシンタイプ x86_64 のデフォルト値も、RHOSP 16 の pc から RHOSP 17 の q35 に変更されました。
RHOSP 16.2 以降では、Compute サービスは、インスタンスの起動時にインスタンスのシステムメタデータ内にインスタンスのマシンタイプを記録します。これは、既存のインスタンスのマシンタイプに影響を及ぼすことなく、RHOSP デプロイメントの有効期間中に NovaHWMachineType を変更できるようになったことを意味します。
Compute サービスは、SHELVED_OFFLOADED 状態にないインスタンスのマシンタイプを記録します。したがって、RHOSP 17 にアップグレードした後は、SHELVED_OFFLOADED 状態にあるインスタンスのマシンタイプを手動で記録し、環境または特定のセル内におけるすべてのインスタンスのマシンタイプが記録されていることを確認する必要があります。マシンタイプを使用して各インスタンスのシステムメタデータを更新した後、既存のインスタンスのマシンタイプに影響を及ぼすことなく、NovaHWMachineType パラメーターを RHOSP 17 のデフォルト (q35) に更新できます。
RHOSP OSP17.0 以降では、Q35 がデフォルトのマシンタイプです。Q35 マシンタイプは PCIe ポートを使用します。heat パラメーター NovaLibvirtNumPciePorts を設定すると、PCIe ポートデバイスの数を管理できます。PCIe ポートに接続できるデバイスの数は、以前のバージョンで実行いているインスタンスよりも少なくなります。より多くのデバイスを使用する場合は、イメージ属性 hw_disk_bus=scsi または hw_scsi_model=virtio-scsi を使用する必要があります。詳細は、仮想ハードウェアのメタデータプロパティー を参照してください。
前提条件
- すべてのコンピュートノードを RHEL 9.2 にアップグレードします。コンピュートノードのアップグレードに関する詳細は、すべてのコンピュートノードを RHEL 9.2 にアップグレードする を参照してください。
手順
-
アンダークラウドに
stackユーザーとしてログインします。 source コマンドで
stackrcファイルを読み込みます。$ source ~/stackrcコントローラーノードに
heat-adminユーザーとしてログインします。(undercloud)$ metalsmith list $ ssh heat-admin@<controller_ip><controller_ip>をコントローラーノードの IP アドレスに置き換えます。マシンタイプが設定されていないインスタンスのリストを取得します。
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt list_unset_machine_typeインスタンスホストのデフォルトのマシンタイプについては、
nova-hw-machine-type-upgrade.yamlファイルのNovaHWMachineTypeパラメーターを確認します。RHOSP 16.2 のNovaHWMachineTypeパラメーターのデフォルト値は次のとおりです。x86_64=pc-i440fx-rhel7.6.0,aarch64=virt-rhel7.6.0,ppc64=pseries-rhel7.6.0,ppc64le=pseries-rhel7.6.0各インスタンスのシステムメタデータをデフォルトのインスタンスマシンタイプで更新します。
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt update_machine_type <instance_uuid> <machine_type>-
<instance_uuid>をインスタンスの UUID に置き換えます。 <machine_type>をインスタンスを記録するマシンタイプに置き換えます。警告インスタンスが起動したイメージのマシンタイプ以外のマシンタイプを設定すると、既存のインスタンスが起動に失敗する可能性があります。
-
すべてのインスタンスのマシンタイプが記録されていることを確認します。
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-status upgrade checkこのコマンドは、マシンタイプのないインスタンスが見つかった場合に警告を返します。この警告が表示された場合は、手順 4 からこの手順を繰り返します。
-
コンピュート環境ファイルの
NovaHWMachineTypeのデフォルト値をx86_64=q35に変更し、オーバークラウドをデプロイします。
検証
デフォルトのマシンタイプを持つインスタンスを作成します。
(overcloud)$ openstack server create --flavor <flavor> \ --image <image> --network <network> \ --wait defaultMachineTypeInstance-
<flavor>をインスタンスのフレーバーの名前または ID に置き換えます。 -
<image>をhw_machine_typeを設定しないイメージの名前または ID に置き換えます。 -
<network>をインスタンスの接続先となるネットワークの名前または ID に置き換えます。
-
インスタンスのマシンタイプがデフォルト値に設定されていることを確認します。
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt get_machine_type <instance_uuid><instance_uuid>をインスタンスの UUID に置き換えます。マシンタイプ
x86_64=pc-i440fxのインスタンスをハードリブートします。(overcloud)$ openstack server reboot --hard <instance_uuid><instance_uuid>をインスタンスの UUID に置き換えます。インスタンスのマシンタイプが変更されていないことを確認します。
[heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \ nova-manage libvirt get_machine_type <instance_uuid><instance_uuid>をインスタンスの UUID に置き換えます。