コンピュート・サービスの問題

この項では、コンピュート・サービスに関連する既知の問題および回避策について説明します。

E5.Flexインスタンスのシェイプは、X9-2ハードウェア・プラットフォームではサポートされません

コンピュート・インスタンス・シェイプは、基礎となるコンピュート・ノードのアーキテクチャに関連付けられています。 VM.PCAStandard.E5.Flexシェイプは、Oracle Server X10コンピュート・ノードにインスタンスを作成するために特別に追加されました。 これは、X10ラック構成でサポートされている唯一のシェイプです。 Private Cloud Appliance X9-2で、他のすべてのシェイプ - Flexシェイプを含む - サポートされています。

回避策: Private Cloud Applianceコンピュート・ノード・アーキテクチャに適したシェイプを選択します。 アプライアンスのコンピュート・ノードがOracle Server X10の場合は、常にVM.PCAStandard.E5.Flexシェイプを選択します。 Oracle Server X9-2コンピュート・ノードを持つシステムでは、VM.PCAStandard.E5.Flexを除くすべてのシェイプがサポートされます。 フレキシブル・シェイプが必要な場合は、かわりにVM.PCAStandard1.Flexシェイプを選択します。

バグ: 35549831

バージョン: 3.0.2

破棄されたインスタンスが、選択したフォルト・ドメインに戻されない

置き換えられたインスタンスは、そのインスタンスの構成で指定されたフォルト・ドメインではないフォルト・ドメインで実行されているインスタンスです。 コンピュート・ノードの退避または障害時にインスタンスを停止できます。

自動リカバリが有効な場合、そのフォルト・ドメインでリソースが使用可能になると、その構成で指定されたフォルト・ドメインに、置き換えられたインスタンスが自動的に返されます。 自動リカバリはデフォルトで有効になっています。

回避策:

Private Cloud Applianceでソフトウェア・バージョン3.0.2-b852928またはソフトウェア・バージョン3.0.2-b892153を実行している場合、またはこれらのリリースのいずれかにアップグレードする場合は、サービスCLIからの自動リカバリを無効にします: 

PCA-ADMIN> disableAutoResolveDisplacedInstance

Private Cloud Applianceでソフトウェア・バージョン3.0.2-b892153より新しいリリースが実行されている場合は、自動リカバリを有効にできます。

これらのコマンドの詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「ハードウェア管理」の章の「コンピュート・ノードからのインスタンスの移行」および「高可用性のためのコンピュート・サービスの構成」を参照してください。

Private Cloud Applianceがこのバグの影響を受け、インスタンスが置き換えられた場合は、インスタンスを停止して再起動し、インスタンスを選択したフォルト・ドメインに戻します。 「Oracle Private Cloud Applianceユーザーズ・ガイド」の「コンピュート・インスタンスのデプロイメント」の章の「インスタンスの停止、起動およびリセット」に関する項を参照してください。

バグ: 35601960, 35703270

バージョン: 3.0.2

Terraformはインスタンス更新に使用できません

2023年5月のOracle Private Cloud Applianceソフトウェア・リリース以降、Oracle Cloud Infrastructure Terraformプロバイダを使用してOracle Private Cloud Applianceのインスタンスを更新することはできません。 この問題の影響を受けるのは、インスタンス更新操作のみです。

Terraformのis_live_migration_preferredプロパティが存在しないため、Terraformを使用してインスタンスを更新すると失敗します。 プロパティが不明であるため、プロパティが確認されると、Terraformはプロパティ値をfalseとして処理します。これは、サポートされている値ではありません。

回避策: コンピュートWeb UIまたはOCI CLIを使用して、インスタンスの更新を実行します。

バグ: 35421618

バージョン: 3.0.2

ブロック・ボリュームに接続するための一貫性のあるデバイス・パスがありません

ブロック・ボリュームをインスタンスにアタッチするときには、インスタンス・リブート間で一貫性を保つデバイス・パスを指定することはできません。 つまり、attach-paravirtualized-volume CLIコマンドの場合、オプションの--deviceパラメータは機能しません。 インスタンスのリブート後にデバイス名が異なる場合があるため、これは、パーティション化、ファイル・システムの作成およびマウントなど、ボリュームで実行するタスクに影響します。

回避策: 回避策はありません。

バグ: 32561299

バージョン: 3.0.1

開始またはスケーリング中にインスタンス・プールを終了できません

プール内のインスタンスが起動中であり、プール内のインスタンスの数を増減するスケーリング操作の進行中は、インスタンス・プールを終了できません。 一方、個々のインスタンスはいつでも終了できます。

回避策: インスタンス・プールを終了するには、すべてのインスタンスが起動するか、スケーリング操作が完了するまで待ちます。 その後、インスタンス・プール全体を正常に終了できます。

バグ: 33038853

バージョン: 3.0.1

インスタンス・プールにインスタンスをアタッチするときに返されるTypeError

既存のコンピュート・インスタンスをインスタンス・プールにアタッチする場合、OCI CLIコマンドでパラメータを含めることができるため、インスタンスが意図した(アクティブ)ライフサイクル状態に達したときにレポートされます。 ただし、OCI CLIのバグによって、次のエラーが発生する可能性があります: 

# oci compute-management instance-pool-instance attach \
--instance-id ocid1.instance....unique_ID --instance-pool-id ocid1.instancePool....unique_ID \
--wait-for-state ACTIVE --wait-interval-seconds 120 --max-wait-seconds 1200
Action completed. Waiting until the resource has entered state: ('ACTIVE',)
Encountered error while waiting for resource to enter the specified state. Outputting last known resource state
{
  "data": {
    "availability-domain": "AD-1",
    "compartment-id": "ocid1.tenancy....unique_ID",
    "display-name": "Standard1.4",
    "fault-domain": "FAULT-DOMAIN-3",
    "id": "ocid1.instance....unique_ID",
    "instance-configuration-id": null,
    "instance-pool-id": "ocid1.instancePool....unique_ID",
    "lifecycle-state": "ATTACHING",
    "load-balancer-backends": [],
    "region": "mypca.example.com",
    "shape": "VM.PCAStandard1.Flex",
    "state": "RUNNING",
    "time-created": "2023-10-28T03:22:45+00:00"
  },
  "opc-work-request-id": "ocid1.workrequest....unique_ID"
}
TypeError: get_instance_pool_instance() missing 1 required positional argument: 'instance_id'

回避策: 現時点では、コマンド・オプション--wait-for-stateは信頼できません。 別の方法として、コマンドlist-instance-pool-instancesを使用して、プール内のインスタンスの状態を確認できます。

バグ: 35956140

バージョン: 3.0.2

Windowsのネットワーク・インタフェースはDHCPサーバーからのMTU設定を受け入れません

インスタンスが起動されると、DHCPを介してIPアドレスがリクエストされます。 DHCPサーバーからのレスポンスには、VNIC最大転送単位(MTU)を9000バイトに設定する手順が含まれています。 ただし、Windowsインスタンスは1500バイトのMTUを使用して起動するため、ネットワーク・パフォーマンスに悪影響を及ぼす可能性があります。

回避策: インスタンスにDHCPサーバーによって初期IPアドレスが割り当てられたら、インタフェースMTUを手動で適切な値に変更します(通常は、インスタンスのプライマリVNICでは9000バイト)。 この新しい値は、ネットワーク切断およびDHCPリース更新で保持されます。

または、WindowsイメージにMTUPluginを含むcloudbase-initが含まれている場合、DHCPからインタフェースMTUを設定できます。 この機能を有効にするには、次のステップを実行します。

  1. ファイルC:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confを編集します。 次の行を追加します。 

    mtu_use_dhcp_config=true
plugins=cloudbaseinit.plugins.common.mtu.MTUPlugin

  2. コマンドRestart-Service cloudbase-initを入力します。

  3. MTU設定が変更されたことを確認します。 このコマンドを使用: netsh interface ipv4 show subinterfaces。

バグ: 33541806

バージョン: 3.0.1

Oracle Solarisバックアップからのリストア後のメンテナンス・モードのインスタンス

既存のインスタンスのブート・ボリュームのバックアップから新しいインスタンスを作成することはサポートされています。 既存のインスタンスが実行中または停止している可能性があります。 ただし、Private Cloud Applianceで提供されているOracle Solarisイメージに基づいてインスタンスのブート・ボリューム・バックアップを使用する場合、そのバックアップから作成された新しいインスタンスはメンテナンス・モードでブートします。 Oracle Solarisコンソールにこのメッセージが表示されます: 「システム・メンテナンス(バイパスするにはcontrol-d)のユーザー名を入力してください:」

回避策: ブロック・ボリューム・バックアップから作成された新しいOracle Solarisインスタンスがメンテナンス・モードで起動したら、コンピュートWeb UIまたはCLIからインスタンスをリブートします。 このリブート後、インスタンスは通常の実行状態に戻り、そのネットワーク・インタフェースを介して到達可能です。

バグ: 33581118

バージョン: 3.0.1

Oracle Solaris UEFI対話型シェルでインスタンスがスタックしています

管理ノードのwebサーバーを介して提供されたイメージからデプロイされたOracle Solaris 11.4コンピュート・インスタンスがUEFI対話型シェルでスタックし、ブートに失敗することが判明しました。 インスタンスがそのブート・シーケンスを完了しない場合、ユーザーはログインできません。 この問題は、テナンシへのインポート中に元の.ociイメージ・ファイルが破損したことが原因である可能性があります。

回避策: UEFIのブート中にOracle Solaris 11.4インスタンスがハングアップし、まだ使用できない場合は、次のように進めます:

  1. ブートに失敗したインスタンスを終了します。

  2. インポートされたOracle Solaris 11.4イメージを削除します。

  3. 管理ノードのwebサーバーからOracle Solaris 11.4イメージを再度インポートします。

  4. 新しくインポートされたイメージからインスタンスを起動し、完全にブートした後でログインできることを確認します。

バグ: 33736100

バージョン: 3.0.1

LRO/LSOを使用したOracle Solarisインスタンスでの遅いデータ転送およびバッファリング

Oracle Solarisでは、ネットワーク・コントローラ・ハードウェア(NIC)にTCPセグメンテーションをオフロードすることで、ネットワーク・パフォーマンスとCPU負荷を最適化する機能であるLarge Send/Receive Offload (LSOおよびLRO)を使用します。 この機能は、Oracle Private Cloud Applianceで提供されているOracle Solarisコンピュート・イメージでデフォルトで有効になっています。 ただし、コンピュート・インスタンス内のLSO/LROによってパケット・サイズや再送信が非常に大きくなり、Oracle Solaris (仮想)ネットワーク・インタフェースでのデータ転送速度が低下する可能性があります。

回避策: パフォーマンス上の理由から、Oracle Private Cloud ApplianceでホストされているOracle Solarisコンピュート・インスタンスでLSO/LROを無効にすることをお薦めします。 次のコマンドは、net0インタフェースのLSO/LROを無効にします。 複数のVNICを持つインスタンスでは、インタフェースごとにLROを無効にする必要があります。 

dladm set-linkprop -p lro=off net0
ipadm set-prop -p _lso_outbound=0 ip

新しいOracle Solarisインスタンス・デプロイメントの場合は、カスタム・クラウド初期化スクリプトにコマンドを追加し、インスタンスの起動時にそれをポイントします。

バグ: 36858282, 36405591

バージョン: 3.0.2

コンピュート・ノード・メトリックに表示されないインスタンス・ディスク・アクティビティ

コンピュート・インスタンスにアタッチされた仮想ディスクは、ホスト・コンピュート・ノードのハイパーバイザを介してゲストに表示されます。 そのため、インスタンスのディスクI/Oは物理ホストのレベルで検出され、Grafanaのコンピュート・ノードのディスク統計に反映されます。 残念ながら、仮想ディスク上のアクティビティは、コンピュート・ノードのディスク・メトリックに集約されません。

回避策: コンピュート・ノード・メトリックを分析するのではなく、各コンピュート・ノードでインスタンス・ディスクI/Oおよび集計された負荷をモニターするには、Grafanaを介して表示される個々のVM統計を使用します。

バグ: 33551814

バージョン: 3.0.1

Oracle Solarisインスタンス内でアタッチされたブロック・ボリュームが表示されない

追加のブロック・ボリュームを実行中のOracle Solarisコンピュート・インスタンスにアタッチしても、オペレーティング・システムには自動的に表示されません。 ディスクを手動で再スキャンした後でも、新しくアタッチされたブロック・ボリュームは非表示のままです。 この問題は、ハイパーバイザがゲストLUNを再列挙するための正しいイベント・トリガーを送信しないために発生します。

回避策: 追加のブロック・ボリュームをOracle Solarisコンピュート・インスタンスにアタッチする場合は、インスタンスをリブートして、新しい仮想ディスクまたはLUNが検出されていることを確認します。

バグ: 33581238

バージョン: 3.0.1

ホスト名が正常に起動されたWindowsインスタンスに設定されていません

DNSが有効になっているVCNおよびサブネットで作業しており、インスタンスを起動すると、ホスト名がインスタンスの表示名または指定したオプションのホスト名のいずれかと一致することが想定されます。 ただし、Windowsインスタンスを起動すると、起動コマンド・パラメータに従ってホスト名が正しく設定されていない可能性があります。 この場合、インスタンス完全修飾ドメイン名(FQDN)は想定どおりに解決され、機能低下はありません。 インスタンス自体のホスト名設定のみが正しくありません。VCN DNS構成は想定どおりに機能します。

回避策: インスタンスのホスト名が指定したインスタンス起動パラメータと一致しない場合は、インスタンス内のホスト名を手動で変更できます。 機能への影響はありません。

または、WindowsイメージにSetHostNamePluginを含むcloudbase-initが含まれている場合、インスタンスのFQDN (hostname-label)に基づいてインスタンス・ホスト名(「コンピュータ名」)を設定できます。 この機能を有効にするには、次のステップを実行します。

  1. ファイルC:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confを編集します。 次の設定を含む行が含まれていることを確認してください。 

    plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin
allow_reboot=true

  2. コマンドRestart-Service cloudbase-initを入力します。

  3. インスタンス・ホスト名が変更されたことを確認します。

バグ: 33736674

バージョン: 3.0.1

インスタンス・バックアップがEXPORTINGまたはIMPORTING状態になることがある

まれに、インスタンスがエクスポートしてバックアップを作成したり、バックアップをインポートしたりするときに、いずれかのコンポーネントの障害が発生した場合、エクスポートまたはインポートされたバックアップはEXPORTINGまたはIMPORTING状態でスタックします。

回避策:

  1. インスタンス・バックアップを削除します。
  2. 5分以上待って、すべての内部サービスが実行されていることを確認します。
  3. インスタンスのエクスポートまたはインポート操作を再度実行します。

「コンピュート・インスタンスのデプロイメント」の「インスタンスのバックアップおよびリストア」を参照してください。

バグ: 34699012

バージョン: 3.0.1

フォルト・ドメインの変更後にインスタンスが起動しない

コンピュート・インスタンスのフォルト・ドメインを変更すると、システムはそれを停止し、選択したターゲット・フォルト・ドメインのコンピュート・ノードにコールド移行して、新しいホストでインスタンスを再起動します。 このプロセスには、インスタンスがターゲット・コンピュート・ノードで正常な実行状態に戻れるようにするための多数の内部操作が含まれています。 これらの内部操作のいずれかが失敗した場合、インスタンスは停止したままになります。

フォルト・ドメインの変更で問題が発生するリスクは、操作の複雑さとともに増加します。 たとえば、複数のインスタンスを別のフォルト・ドメインに同時に移動する場合(特に、共有ブロック・ボリュームを持ち、ターゲット・フォルト・ドメイン内の異なるコンピュート・ノードに移行する場合)は、ストレージ・レベルでタイミングが重要な構成変更を多数必要とします。 移行されたコンピュート・インスタンスの新しいホストで基礎となるiSCSI接続を使用できない場合、ハイパーバイザはインスタンスを起動できません。

回避策: フォルト・ドメインを変更した後、コンピュート・インスタンスが停止したままの場合は、手動で起動してみてください。 前述のタイミングの問題が原因でインスタンスが起動できなかった場合は、手動起動コマンドによってインスタンスが通常の実行状態に戻される可能性があります。

バグ: 34550107

バージョン: 3.0.2

インスタンスの移行がMOVING状態でスタックしています

「サービスWeb UI」を使用してVMを移行する場合、移行がMOVINGライフサイクル状態でスタックする可能性があるため、これ以上の移行を続行できません。

このエラーは、ライブ移行などの管理アクティビティがパッチ適用またはアップグレード・プロセス中に実行されている場合や、パッチ適用またはアップグレード・プロセスが完全に完了する前に管理アクティビティが開始される場合に発生することがあります。

回避策: この問題を解決するには、Oracle Supportに連絡してください。

バグ: 33911138

バージョン: , 3.0.1, 3.0.2

OCI CLIコンピュート・インスタンスから実行するとコマンドが失敗

2023年初頭以降に提供されたOracle Linuxイメージに基づくコンピュート・インスタンスには、OCI CLIがPrivate Cloud Applianceアイデンティティ・サービスに接続できないようにするファイアウォール構成がある可能性があります。 Oracle Cloud Infrastructureでは、アイデンティティ・サービスにパブリックIPアドレス(またはFQDN)を介してアクセスする必要があり、Oracle Private Cloud Applianceでは内部IPアドレスを介してアクセスが提供されます。 Oracle Cloud Infrastructureイメージは、この内部IPアドレスへのすべての接続をブロックするようにデフォルトで構成されています。

この問題は、次のイメージで確認されています:

  • uln-pca-oracle-linux-7-9-2023-08-31-0-oci

  • uln-pca-oracle-linux-8-2023-08-31-0-oci

  • 2023年の利用可能日を含むすべてのOracle Linux 9イメージ

回避策: Private Cloud Appliance環境のコンピュート・インスタンスからOCI CLIを使用する場合は、そのアイデンティティ・サービスへのアクセスを確認します。 接続が拒否された場合は、インスタンス・ファイアウォール構成を確認し、アイデンティティ・サービスへのアクセスを有効にします。

  1. アイデンティティ・サービスへのインスタンス接続のテスト。 たとえば、telnetまたはnetcatを使用します。 

    # curl -v telnet://identity.mydomain:443
* connect to 169.254.169.254 port 443 failed: Connection refused

-- OR --
# nc -vz identity.mydomain 443
Ncat: Connection refused.

  2. ファイアウォール出力チェーンにBareMetalInstanceServicesという名前のルールが含まれていることを確認します。 

    # iptables -L OUTPUT --line-numbers
Chain OUTPUT (policy ACCEPT)
num  target                     prot   opt   source           destination         
1    BareMetalInstanceServices  all    --    anywhere         169.254.0.0/16

  3. ファイアウォール構成のベア・メタル・インスタンス・ルールを無効にします。

    1. これらのファイアウォール・ルールを定義するファイルの名前を変更します(/etc/firewalld/direct.xml)。

    2. firewalldサービスを再起動します。

    詳細な手順は、「ドキュメントID 2983004.1」のノートに記載されています。

バグ: 35234468

バージョン: 3.0.2

Oracle Linux 9インスタンスにOCI CLIをインストールできない

Oracle Linux 9コンピュート・インスタンスでOCI CLIを実行するには、パッケージpython39-oci-cliとその依存関係が必要です。 これらは「Oracle Linux 9 OCIに含まれるパッケージ」 (ol9_oci_included)リポジトリを介して提供されますが、このリポジトリはOracle Cloud Infrastructureの外部ではアクセスできません。

Oracle Private Cloud ApplianceのOracle Linux 9コンピュート・インスタンスは、かわりに、パブリックOracle Linux 9リポジトリから必要なパッケージを取得する必要があります - 特に: Oracle Linux 9開発パッケージ (ol9_developer)およびOracle Linux 9 Application Streamパッケージ (ol9_appstream)。 これらのリポジトリは、指定されたOracle Linux 9イメージではデフォルトで有効になっていません。

回避策: ol9_developerおよびol9_appstreamパブリックyumリポジトリを有効にして、python39-oci-cliをインストールします。 

$ sudo yum --disablerepo="*" --enablerepo="ol9_developer ol9_appstream" install python39-oci-cli -y
Dependencies resolved.
==================================================================================================================
 Package                               Architecture       Version                    Repository              Size
==================================================================================================================
Installing:
 python39-oci-cli                      noarch             3.40.2-1.el9               ol9_developer           39 M
Upgrading:
 python39-oci-sdk                      x86_64             2.126.2-1.el9              ol9_developer           74 M
Installing dependencies:
 python3-arrow                         noarch             1.1.0-2.el9                ol9_developer          153 k
 python3-importlib-metadata            noarch             4.12.0-2.el9               ol9_developer           75 k
 python3-jmespath                      noarch             0.10.0-4.el9               ol9_developer           78 k
 python3-prompt-toolkit                noarch             3.0.38-4.el9               ol9_appstream          1.0 M
 python3-terminaltables                noarch             3.1.10-8.0.1.el9           ol9_developer           60 k
 python3-wcwidth                       noarch             0.2.5-8.el9                ol9_appstream           65 k
 python3-zipp                          noarch             0.5.1-1.el9                ol9_developer           24 k

Transaction Summary
=================================================================================================================
Install  8 Packages
Upgrade  1 Package
[...]
Complete!

バグ: 35855058

バージョン: 3.0.2

OCI CLIのインスタンス・コンパートメントを変更すると、キー・エラーが返されます

OCI CLIを使用してコンピュート・インスタンスが存在するコンパートメントを変更すると、コマンドは作業リクエスト・キー・エラーを返します。 

# oci compute instance change-compartment <instance id> <new compartment id> --debug
[...]
DEBUG:oci.base_client.140018383788856: 2024-06-03 18:41:52.605103: Response status: 200
DEBUG:oci.base_client.140018383788856: 2024-06-03 18:41:52.605301: Response returned
DEBUG:oci.base_client.140018383788856:time elapsed for request: 1.5186387430876493
Traceback (most recent call last):
[...]
  File "/root/lib/oracle-cli/lib64/python3.6/site-packages/services/core/src/oci_cli_compute/compute_cli_extended.py", line 767, in change_instance_compartment
    work_request_client = cli_util.build_client('core', 'work_request', ctx)
  File "/root/lib/oracle-cli/lib64/python3.6/site-packages/oci_cli/cli_util.py", line 461, in build_client
    client_class = CLIENT_MAP[spec_name][service_name]
KeyError: 'work_request'

これは、OCI CLIの既知の問題です。 コンパートメントの変更ファンクションは、正しくない方法で作業リクエストを作成しようとします。

回避策: OCI CLIを使用してコンピュート・インスタンスのコンパートメントを変更することをお薦めします。これは、この問題がPrivate Cloud Applianceのコード実行に与える影響が不明であるためです。 テストでは、キー・エラーにもかかわらずコンパートメントの変更が正しく適用されていることが示されます。

バグ: 36691465

バージョン: 3.0.2

次の証明書更新チェックまでInstance Principalを使用できません

インスタンス・プリンシパルは、サービス・リソースに対するアクションの実行が認可されているコンピュート・インスタンスです。 これらの操作を許可する前に、Identity and Access Managementサービス(IAM)はインスタンス・プリンシパル・セキュリティ・トークンを検証: 30日後に期限切れになるTLS証明書。

失効した証明書が24時間ごとにチェックされ、必要に応じて更新されます。 ただし、停止、システム・メンテナンスまたはアップグレード・アクティビティの後、インスタンス・プリンシパルは認可を失う可能性があります。 その場合、更新後の証明書は、次の更新チェックまで取得できません(24時間後まで)。

同様に、インスタンス・プリンシパルをサポートしていないリリースから、インスタンス・プリンシパルをサポートするリリースにアップグレードした後、コンピュート・インスタンスはTLS証明書を受信するために最大24時間待機する必要がある場合があります。

回避策: この証明書をすぐにインストールまたは更新する必要がある場合は、Oracleに連絡してください。

バグ: 36165739

バージョン: 3.0.2

OKEイメージを含むプラットフォーム・イメージのリスト

Private Cloud Applianceは、コンピュート・インスタンス・デプロイメントを便利に行えるように、標準のOracle LinuxおよびOracle Solarisイメージのセットを提供します。 アプライアンスをアップグレードまたはパッチを適用すると、使用可能な最新のイメージが追加されます。 同じメカニズムを使用して、OKEサービスを使用してクラスタをデプロイするために必要なイメージを追加: Oracle Private Cloud Appliance Kubernetesエンジン(OKE). ユーザーが「コンピュートWeb UI」からインスタンスを起動すると、適切なイメージがリストされ、OKE固有のイメージがフィルタで除外されます。 ただし、OCI CLIでは、通常のコンピュート・インスタンスには使用しない「OKEサービス」のイメージを含め、すべてのイメージがデフォルトで表示されます。 

oci compute image list --compartment-id "ocid1.tenancy.... unique_id" | grep "display-name"
      "display-name": "uln-pca-Oracle-Linux-7.9-2024.04.19_0.oci",
      "display-name": "uln-pca-Oracle-Linux-7.9-2024.05.29_0.oci",
      "display-name": "uln-pca-Oracle-Linux-8-2024.04.19_0.oci",
      "display-name": "uln-pca-Oracle-Linux-8-2024.05.29_0.oci",
      "display-name": "uln-pca-Oracle-Linux-9-2024.04.22_0.oci",
      "display-name": "uln-pca-Oracle-Linux-9-2024.05.29_0.oci",
      "display-name": "uln-pca-Oracle-Linux8-OKE-1.26.6-20240210.oci",
      "display-name": "uln-pca-Oracle-Linux8-OKE-1.26.6-20240611.oci",
      "display-name": "uln-pca-Oracle-Linux8-OKE-1.27.7-20240422.oci",
      "display-name": "uln-pca-Oracle-Linux8-OKE-1.27.7-20240602.oci",
      "display-name": "uln-pca-Oracle-Linux8-OKE-1.28.3-20240210.oci",
      "display-name": "uln-pca-Oracle-Linux8-OKE-1.28.3-20240602.oci",
      "display-name": "uln-pca-Oracle-Solaris-11-2024.05.07_0.oci",

回避策: 通常のコンピュート・インスタンスまたはインスタンス・プールを起動する場合は、Oracle提供のイメージまたは独自のカスタム・イメージのいずれかを使用します。 OKE固有のイメージを使用しないでください。

バグ: 36112983

バージョン: 3.0.2

VMDA形式でのカスタム・イメージのインポートはサポートされていません

Private Cloud Applianceでは、現在、VMDA形式のカスタム・イメージのインポートはサポートされていません。

回避策: カスタム・イメージをインポートする場合は、QCOW2形式を使用します。

バグ: 37049215

バージョン: 3.0.2

容量を超えるとインスタンスのGPU使用量が増加するとインスタンスが停止

コンピュート・インスタンスのシェイプによって使用されるGPUの数が決定されるため、GPU数が多いシェイプにインスタンスを更新することで、GPU使用量を増やすことができます。 ただし、シェイプ更新によってシステムが物理GPU容量を超えると、更新はエラーなしで受け入れられ、問題のインスタンスは停止されます。

ノート:

使用可能なGPU容量が不足しているシステムで新しいGPUインスタンスを起動しようとすると、適切なエラーが返され、インスタンスの起動が予想どおりに失敗します。

回避策: GPUインスタンスのシェイプを更新してGPU使用量を増やす場合は、更新後もインスタンスが実行中であることを確認します。 インスタンスが停止した場合は、そのシェイプを元のシェイプに戻すか、インスタンスで使用するためにGPUを解放できるかどうかを確認します。 管理者は、CLIコマンドgetFaultDomainInfoを使用してGPUの可用性を検証できます。 

PCA-ADMIN> getFaultDomainInfo
Data:
  id               totalsCNs   totalMemory   freeMemory   totalvCPUs   freevCPUs   totalGPUs   freeGPUs   Notes
  --               ---------   -----------   ----------   ----------   ---------   ---------   --------   -----
  UNASSIGNED       6           0.0           0.0          0            0           0           0          N.A.
  UNASSIGNED-GPU   0           0.0           0.0          0            0           0           0          N.A.
  FD1              2           3208.0        3144.0       488          444         0           0          N.A.
  FD1-GPU          1           984.0         24.0         216          2           4           0          N.A.
  FD2              2           3208.0        3160.0       488          446         0           0          N.A.
  FD2-GPU          1           984.0         504.0        216          108         4           2          N.A.
  FD3              2           3208.0        3032.0       488          410         0           0          N.A.
  FD3-GPU          1           984.0         24.0         216          0           4           0          N.A.

バグ: 37278974

バージョン: 3.0.2

SR-IOV vNICを含むインスタンス構成で作成されたインスタンス・プールから起動されたインスタンスにアクセスできません

SR-IOV vNICでインスタンス構成を使用してインスタンス・プールを作成した場合、そのプールからインスタンスを起動すると、そのインスタンスにアクセスできなくなります。 現時点では、SR-IOV vNICを含む構成でインスタンス・プールを作成することはできません。そのvNICはアタッチされないためです。

回避策: SR-IOV vNICをアタッチせずにインスタンスを作成し、インスタンスを起動してから、SR-IOV vNICをアタッチします。

バグ: 37192651

バージョン: 3.0.2

デバイスをアタッチできないため、コンピュート・インスタンスの移行が失敗

コンピュート・インスタンスを別のコンピュート・ノードに移行する場合、デバイスへのパスが見つからず、アタッチできないため、操作が失敗することがあります。 この問題は、通常のライブ移行および置き換えられたインスタンスの移行に適用されます。 移行ジョブの出力は、次の例のようになります: 

PCA-ADMIN> show job id=71782dc1-02d8-412e-97fa-703508c606e9
Data: 
  AssociatedObj = id:a7c7bbfe-21f5-4f9d-9158-87779c7eb7b0  type:ComputeNode  name:pcacn003
  Name = OPERATION-MigrateVm
  Progress Message = Fail to attach device 600144f00d9c3e67000067bcfce30047, path not found, server 100.96.2.66 
  Run State = Failed

回避策: インスタンスの移行を手動で再試行します。 新しいジョブはうまくいくと予想されています。

バグ: 37574886

バージョン: 3.0.2

Oracle Linuxプラットフォーム・イメージに含まれないGPUドライバ

Private Cloud ApplianceインストールにGPUを含むコンピュート・ノードが含まれている場合は、専用シェイプを選択してアクセスできます。 GPUシェイプは、Oracle Linux 8またはOracle Linux 9プラットフォーム・イメージに基づいてコンピュート・インスタンス用に選択できます。 現在のイメージ・バージョンにはGPUドライバは含まれていません。 インスタンスOSは割り当てられたGPUを検出しますが、それを使用するには、必要なドライバをインストールするために「NVIDIA開発者サイト」のCUDA Toolkitが必要です。

ノート:

大規模なダウンロードおよびローカル・リポジトリのインストールには、大量のディスク領域が必要です。 デフォルトの50GBブート・ボリュームは、Oracle Linux 9では不十分で、Oracle Linux 8では十分です。 ブート・ボリューム・サイズを60GB以上に増やし、それに応じてファイル・システムを拡張することをお薦めします。

回避策: インスタンスを起動した後、コマンドラインにログインし、CUDA Toolkitをインストールします。 使用しているバージョンのOracle Linuxの手順に従ってください。

Oracle Linux 9インスタンスへのGPUドライバのインストール

  1. インスタンスのコマンドラインから、OS用のCUDA Toolkit rpmをダウンロードしてインストールします。

    $ wget https://developer.download.nvidia.com/compute/cuda/12.8.0/local_installers/cuda-repo-rhel9-12-8-local-12.8.0_570.86.10-1.x86_64.rpm
$ sudo rpm -i cuda-repo-rhel9-12-8-local-12.8.0_570.86.10-1.x86_64.rpm
$ sudo dnf clean all
$ sudo dnf install cuda-toolkit-12-8

  2. Oracle Linux 9 EPEL yumリポジトリを有効にします。 dkmsパッケージをインストールします。 

    $ sudo yum-config-manager --enable ol9_developer_EPEL
$ sudo dnf install dkms

  3. GPUドライバをインストールします。

    $ sudo dnf install cuda-12-8

  4. NVIDIAシステム管理インタフェースを使用してインストールを確認します。 

    $ nvidia-smi
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.86.10              Driver Version: 570.86.10      CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L40S                    Off |   00000000:00:05.0 Off |                    0 |
| N/A   26C    P8             23W /  350W |       1MiB /  46068MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+
Oracle Linux 8インスタンスへのGPUドライバのインストール

  1. インスタンスのコマンドラインから、OS用のCUDA Toolkit rpmをダウンロードしてインストールします。

    $ wget https://developer.download.nvidia.com/compute/cuda/12.8.0/local_installers/cuda-repo-rhel8-12-8-local-12.8.0_570.86.10-1.x86_64.rpm
$ sudo rpm -i cuda-repo-rhel8-12-8-local-12.8.0_570.86.10-1.x86_64.rpm
$ sudo dnf clean all
$ sudo dnf install cuda-toolkit-12-8

  2. Oracle Linux 8 EPEL yumリポジトリを有効にします。 dkmsパッケージをインストールします。 

    $ sudo yum-config-manager --enable ol8_developer_EPEL
$ sudo dnf install dkms

  3. GPUドライバをインストールします。

    $ sudo dnf install cuda-12-8

  4. NVIDIAカーネル・モジュールをインストールします。 

    $ sudo scl enable gcc-toolset-13 bash
# dkms install nvidia-open -v 570.86.10

    カーネル・モジュールのビルド中にこのmakeエラーが発生した場合は、無視しても問題ありません。 

    Cleaning build area...(bad exit status: 2)
Failed command:
make -C /lib/modules/5.15.0-206.153.7.el8uek.x86_64/build M=/var/lib/dkms/nvidia-open/570.86.10/build clean

  5. NVIDIAシステム管理インタフェースを使用してインストールを確認します。 

    # nvidia-smi
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.86.10              Driver Version: 570.86.10      CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L40S                    Off |   00000000:00:05.0 Off |                    0 |
| N/A   26C    P8             23W /  350W |       1MiB /  46068MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

バグ: n/a

バージョン: 3.0.2

TerraformまたはOCI SDKを使用してGPUフレックス・シェイプ・インスタンスを起動できない

Private Cloud ApplianceインストールにGPUを含むコンピュート・ノードが含まれる場合、GPUを使用できるように、専用シェイプでコンピュート・インスタンスを起動する必要があります。 これは、固定ハードウェア・リソース比率を持つ標準シェイプ、またはユーザーがCPU/RAM/GPU比率をカスタマイズできるフレックス・シェイプです。 ただし、Private Cloud ApplianceとOracle Cloud Infrastructureのシェイプ・モデリングの違いにより、OCI SDKまたはTerraformプロバイダを使用してGPUフレックス・シェイプでインスタンスを起動することはできません。 この方法でインスタンスを起動しようとすると、gpus引数が認識されないことを示すエラーが返されます。

回避策: コンピュートWeb UIまたはOCI CLIを使用して、GPUフレックス・シェイプでコンピュート・インスタンスを起動します。 別の方法として、すべての正しい引数を提供する直接curlリクエストも機能することが予想されます。

バグ: 37195244

バージョン: 3.0.2

移行不可能なインスタンスの実行時に強制コンピュート・ノードの退避が失敗

コンピュート・ノードの退避は、すべてのコンピュート・インスタンスを他のコンピュート・ノードに移行する操作であるため、メンテナンスのためにノードを安全にオフラインにできます。 また、インスタンスを1つずつ停止するのではなく、単一のコマンドでノードで実行されているすべての移行不可能なインスタンスをソフト・ストップするために使用することもできます。 ただし、ベスト・プラクティスは、ゲストOSからインスタンスを停止し、インスタンスを「コンピュートWeb UI」またはOCI CLIから正常に停止することです。

移行不可能なインスタンス(GPUシェイプに基づくインスタンスやSR-IOVで構成されたインスタンスなど)の実行中に強制ノード退避を使用することにした場合、インスタンスが正常に停止しても、ジョブはエラーを返し、失敗状態のままになります。

PCA-ADMIN> migrateVm id=<compute_node_id> force=true
JobId: 03816731-2829-471c-9aaf-b8f5e0666bdf
Data: Running

PCA-ADMIN> show job id=03816731-2829-471c-9aaf-b8f5e0666bdf
Data: 
  Name = OPERATION-MigrateVm
  Progress Message = (400, 'LimitExceeded', 'Unable to place VM instance')
                     (403, 'NotAllowed', 'instance ocid1.instance.unique_ID migration not allowed')
  Run State = Failed

回避策: 強制的なコンピュート・ノードの退避を実行した後、移行不可能なすべてのインスタンスが正常に停止されたことを確認します。 

PCA-ADMIN> getNonMigratableInstances
Data:
  id                           Display Name  Compute Node Id  Domain State
  --                           ------------  ---------------  ------------
  ocid1.instance.unique_ID     instance202   CN_ID            shut off
  ocid1.instance.unique_ID     kqh027        CN_ID            shut off

失敗したジョブからエラーをクリアするには、退避コマンドをもう一度実行します。 これで成功するはずです。

詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「コンピュート・ノードからのインスタンスの移行」を参照してください。

バグ: 37092239

バージョン: 3.0.2

複数のGPUを持つインスタンスでP2P検証が失敗

複数のGPUを持つシェイプを使用してインスタンスを起動すると、GPU間のダイレクト・ピア・ツー・ピア(P2P)データ・アクセスが最高のパフォーマンスを発揮します。 ただし、simpleP2Pテスト・ツールを使用した検証ではエラーが返され、一部のGPUペア間のピア・アクセスが期待どおりに機能しないことが示されます。

回避策: コンピュート・インスタンスにNVIDIA CUDA Toolkitをインストールした後、ドライバ永続性モードを有効にし、PCIeの緩和された順序付けを無効にします。

  1. sudo権限を持つユーザーとしてコンピュート・インスタンスにログインします。

  2. GPUドライバ永続性モードを有効にします。

    $ sudo systemctl enable nvidia-persistenced.service
$ sudo systemctl start nvidia-persistenced.service

$ systemctl status nvidia-persistenced.service
  nvidia-persistenced.service - NVIDIA Persistence Daemon
     Loaded: loaded (/usr/lib/systemd/system/nvidia-persistenced.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-02-04 09:50:12 GMT; 15s ago
    Process: 413704 ExecStart=/usr/bin/nvidia-persistenced --verbose (code=exited, status=0/SUCCESS)
   Main PID: 413705 (nvidia-persiste)
      Tasks: 1 (limit: 1284273)
     Memory: 876.0K
        CPU: 14ms
     CGroup: /system.slice/nvidia-persistenced.service
             └─413705 /usr/bin/nvidia-persistenced --verbose

  3. GPUのPCI識別子を調べます。

    $ lspci | grep -i nvidia
00:05.0 3D controller: NVIDIA Corporation AD102GL [L40S] (rev a1)
00:06.0 3D controller: NVIDIA Corporation AD102GL [L40S] (rev a1)

  4. GPUのPCIe緩和された順序付けを無効にします。 このコマンドを使用します: 

    $ sudo setpci -s <gpu-device> CAP_EXP+8.w=0

    たとえば:

    $ sudo setpci -s 00:05.0 CAP_EXP+8.w=0
$ sudo setpci -s 00:06.0 CAP_EXP+8.w=0

  5. コンピュート・インスタンスが停止および起動された場合、再起動またはライフサイクル状態を変更する別の操作のために、コマンドを繰り返して、すべてのGPUデバイスのPCIe緩和された順序を無効にします。

バグ: 37279887

バージョン: 3.0.2