コンピュートの既知の問題

詳細

コンピュート・インスタンスの再起動後、一部のWindowsシステムは正常に起動できず、ロード画面でスタックしたままになります。この問題は現在調査中です。

回避策

この問題に一時的に対処するには、診断リブートを実行します。診断リブートの実行のOracle Cloud Infrastructureドキュメントに記載されているステップに従います。このプロセスは、システムに影響を与えるブート問題を診断し、潜在的に解決するのに役立ちます。

詳細

ARMシェイプでOracle Linux 8を使用し、Oracle Cloud Agent (OCA)のバージョン1.43.2-18を実行するお客様は、インスタンスでアップデータ・サービスを再起動する必要があります。OCAアップデータの既知の問題により、アップデータは将来のアップグレードのためにポーリングされず、再起動によって問題が解決されます。

回避策

インスタンス上のOCAの現在のバージョンを確認するには、次のコマンドを実行します:

yum info oracle-cloud-agent

アップデータを再起動するには、次のコマンドを実行します:

sudo systemctl restart oracle-cloud-agent-updater

詳細

ClamAV署名は、不正な署名データベース(ウイルス定義26931)のために正当なバイナリをウイルスとしてマークしました。この問題により、ClamAVはOracle Cloud Agentとそのプラグインをウイルスとして識別しました。デフォルトでは、ClamAVは感染したファイルを隔離しません。したがって、誤った検出にもかかわらず、エージェントとそのプラグインは正常に機能し続けます。インスタンスで隔離アクションが実行された場合でも、エージェントとプラグインは影響を受けず、アップデータやハートビートなどの機能は期待どおりに動作します。ただし、エージェントまたはインスタンスを再起動すると機能が破損します。

回避策

インスタンスが影響を受ける場合は、Oracle Cloud Agentソフトウェアのインストールを参照して、Oracle Cloud Agentの新しいパッケージをインストールします。

詳細

仮想ネットワーク・アタッチメントの既存の制限により、BM.Standard.E5.192で合計ホスト・ネットワーク帯域幅が60Gbpsに制限されます。

回避策

回避策は存在しません。オラクルは、デプロイ時にライブ・ネットワーク・ワークロードに影響を与えないソフトウェア修正に取り組んでいます。

詳細

コンピュート・インスタンスを作成した後、そのインスタンスの機密コンピューティングを、後から有効化または無効化することができません。

回避策

解決に向けて取り組んでいます。

詳細

Oracle Linux 9では、機密コンピューティングがサポートされていません。

回避策

解決に向けて取り組んでいます。

詳細

古い世代のAMDシステム(AMD Romeプロセッサを使用するE2/E3)では、メモリーが350GBを超えるSecure Encrypted Virtualization (SEV)メモリー暗号化(デフォルトでは無効)を使用するゲストは、ゲストのブート/停止中に、ホスト/ハイパーバイザでCPUのソフト・ロックアップの警告が発生する原因になることがあります(これは、暗号化された固定メモリーのフラッシュにかかる時間がメモリー量に比例するためで、350GBを超える大量のメモリーはCPUで過剰に時間がかかり、警告が発生します)。メモリーがフラッシュされると、ハイパーバイザは通常の動作に戻ります。

E4 (ベースはAMD Milanプロセッサ)などの新しいシステムには、メモリーのフラッシュにかかる時間を最小限に抑えるハードウェア・サポートがあるため、CPUのソフトハングは発生しません。

回避策

メモリーが350GBを超えるSEV対応のゲストが必要な場合、そのゲストはE4システム(ベースはAMD Milanプロセッサ)に作成します。AMD Romeプロセッサ(E2/E3)を使用するシステムでは、SEVメモリー暗号化を使用する場合、メモリーは350GB未満に制限します。

詳細

次のコンピュート・シェイプのリストでは、同じシェイプに複数の名前が使用されています。

• BM.GPU.A10.4:この名前は、BM.GPU.A10.4とBM.GPU.GU1.4の両方に表示されます。
• BM.GPU.A100-v2.8:この名前は、BM.GPU.A100-v2.8とBM.GPU.GM4.8の両方に表示されます。
• VM.GPU.A10.1:この名前は、VM.GPU.A10.1とVM.GPU.GU1.1の両方に表示されます。
• VM.GPU.A10.2:この名前は、VM.GPU.A10.2とVM.GPU.GU1.2の両方に表示されます。

回避策

違う名前は破棄します。各シェイプで、基礎となるハードウェアは同じです。

詳細

macOS Ventura (バージョン13)を実行しているクライアントまたはOpenSSH 9.0を実行しているクライアントを使用してOracle Cloud Infrastructure上のインスタンスに接続しようとすると、次のようなエラーが表示される接続問題が発生する可能性があります:

Unable to negotiate with 192.0.2.181 port 22: no matching host key type found. Their offer: ssh-rsa
kex_exchange_identification: Connection closed by remote host

回避策

~/.ssh/configファイルに次を追加します:

Host *
  PubkeyAcceptedKeyTypes +ssh-rsa
  HostkeyAlgorithms +ssh-rsa

詳細

CentOS 7向けの2022年9月のプラットフォーム・イメージ(イメージ名はCentOS-7-2022.09.20-0)を実行するインスタンスでは、24時間経つと、iSCSIにアタッチされたブート・ボリュームへの接続が失われます。この問題は、インスタンスで24時間後にDHCPリースが失われるために発生します。

回避策

このイメージを使用する既存のインスタンスを終了(削除)し、別のCentOS 7プラットフォーム・イメージを使用してインスタンスを再作成することをお薦めします。

2022年9月CentOS 7プラットフォーム・イメージを使用する既存のインスタンスを終了できない場合は、インスタンスを再起動すると、24時間の新しいDHCPリースを取得できます。

詳細

この問題は、前世代のシェイプ(この既知の問題の趣旨としては、オーダー可能終了日が2022年10月より前のシェイプ)を使用しているベア・メタル・インスタンス、およびWindows Server 2016 Datacenter Editionを実行しているベア・メタル・インスタンスに影響します。

Hyper-Vの「仮想スイッチ マネージャー」を開いて、新しい外部仮想スイッチ(vSwitch)を作成しようとすると、「Error applying Virtual Switch Properties changes: Failed while adding virtual Ethernet switch connections」というような内容のエラー・メッセージが表示されます。

このエラーは、Microsoft Windows Updateの実行後にインストールされたBroadcomドライバが、オラクル社によって動作保証されていないために発生します。

回避策

Broadcomドライバ・バージョン20.8.24.0は、オラクル社によって動作保証されています。バージョン20.8.24.0をインストールしてください。

詳細

Ubuntu 20.04、カーネル・バージョンlinux-oracle-5.13 5.13.0-1033.39~20.04.1を使用するコンピュート・インスタンスでコンテナを実行すると、カーネル・パニックが発生します。インスタンスはクラッシュし、アクセスできません。詳細は、Dockerコンテナの作成によってlinux-aws 5.13.0.1028.31~20.04.22でカーネルoopsが発生するを参照してください。

回避策

次のコマンドを実行して、カーネルを上位バージョンにアップグレードします:

sudo apt-get update

sudo apt-get upgrade -y linux-image-oracle

詳細

メモリーが1,010GBを超えるサイズに変更された場合、2021年4月5日より前に作成されたE3/E4フレックス・シェイプVMインスタンスは起動に失敗します。この場合、「起動に失敗しました」というエラーが表示されます。

回避策1

メモリーのサイズを1,010GB未満に縮小します。

回避策2

インスタンスを再作成してから、インスタンス・メモリーのサイズを最大1,024GBに変更します。

詳細

Oracle Autonomous LinuxはAlways Freeコンピュート・インスタンスではサポートされていないのに、コンソールには、Always FreeシェイプでサポートされているイメージのリストにOracle Autonomous Linuxが表示されます。

回避策

解決に向けて取り組んでいます。

詳細

米国東部(アッシュバーン)リージョンで、プロビジョニング後に初めてOracle Linuxインスタンスを起動する際に、DNSが予想どおりに機能しないことがあり、/etc/resolv.confファイルのsearchフィールドが不完全な可能性があります。

回避策

インスタンスを再起動するか、次のDHCPリース更改を待機します。DHCPリース更改後、問題は自動的に解決されます。標準のDHCPリース時間は24時間ですが、ネットワーク設定によって異なります。

詳細

Linux 7.xを使用して保護インスタンスを作成し、インスタンスを再起動すると、PCR値が変更され、そのために赤いシールドが表示されることがあります。

回避策

一部のPCR値は実行時に変化します。この変化は予期されているものです。回避策として、ゴールデン測定をリセットします。

詳細

BM.Standard.A1.160シェイプを使用するベア・メタル・インスタンスでは、ソケット1のCPUで実行されているワークロードのネットワーク・パフォーマンスが低下します。

回避策

ネットワークからのパケットを処理するアプリケーションの場合は、それらをソケット0からCPUにバインドします。

詳細

サービス・ゲートウェイがアタッチされたプライベート・サブネット内のWindowsでコンピュート・インスタンスをプロビジョニングする場合、Oracle Cloud Agentプラグインによりメトリックが生成されない場合があります。

回避策

Microsoftの既知の問題の記事: DigiCertグローバル・ルートG2ルート証明書がインストールされていない場合の接続の問題に示されたステップに従います。

詳細

ハードウェア支援(SR-IOV)ネットワーキングでVM.Standard.A1.Flexシェイプを使用するインスタンスでは、パフォーマンスの問題が発生する場合があり、まれにデータが破損することもあります。これを回避するために、OCI Ampere A1 Compute (aarch64)のプラットフォーム・イメージは、疑似仮想化ネットワークのみを使用するように構成されています。プラットフォーム・イメージを使用してインスタンスを作成し、ハードウェア支援ネットワーキングを指定した場合は、起動に失敗し、Failed to validate instance launch optionsのようなメッセージが表示されます。

OCI Ampere A1 Computeと互換性のあるカスタム・イメージの場合、起動は成功しますが、パフォーマンスおよびデータ破損の問題を回避するために、ハードウェア支援ネットワーキングは選択しないでください。

回避策

プラットフォーム・イメージを使用してVM.Standard.A1.Flexインスタンスを作成する場合は、Oracleにより選択される推奨ネットワーク起動タイプを受け入れます。カスタム・イメージには、ハードウェア支援(SR-IOV)ネットワーキングを使用しないでください。

詳細

VM.Standard.A1を使用するインスタンスハードウェア支援(SR-IOV)ネットワークと多数のコアを持つフレックス・シェイプにより、準仮想化ネットワークを使用するよりもパフォーマンスが向上します。ただし、SR-IOVネットワークでは、コア数が76に制限され、メモリー量は456 GBに制限されます。

これらの制限のいずれかを超えるインスタンスを作成しようとすると、インスタンスを作成するための容量が不足していることを示すエラーが発生します。

回避策

解決に向けて取り組んでいます。

詳細

Terraformを使用して、Linuxプラットフォーム・イメージを使用するIntelまたはAMDコンピュート・インスタンスを作成すると、エラー・コードInvalidParameterで操作が失敗し、Shape <shape_name> is not valid for image <image_OCID>のようなメッセージが表示されます。

これは、Terraformがイメージdisplay_nameに基づいて最新イメージを識別した場合に発生します。IntelおよびAMDシェイプ(x86プロセッサ・アーキテクチャ)のイメージは、Armベースのシェイプ(aarch64プロセッサ・アーキテクチャ)のイメージと同様の名前を持ちますが、イメージはプロセッサ・アーキテクチャ間で相互に互換性がありません。最新のイメージがaarch64イメージの場合、Terraformによってx86シェイプのaarch64イメージが選択されるため、操作は失敗します。

回避策

次のTerraformファイルを変更します:

• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/global/global.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pd/pd.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/nonpd/nonpd.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/globalDR/globalDR.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pdDR/pdDR.datasources.tf

これらのファイルで、Armベースのシェイプのすべてのイメージをフィルタで除外するために、イメージを識別する正規表現を更新します。Armベースのシェイプのイメージは、イメージ名に"aarch"が含まれています。

たとえば、Oracle Linux 8イメージの場合は、次のように更新します:

• 現在の正規表現: values = ["^.*Oracle-Linux-8[.]*[\\d]*-[^G].*$"]
• 更新後の正規表現: values = ["^.*Oracle-Linux-8[.][0-9]*-[\\d]{4}.[\\d]{2}.[\\d]{2}-[\\d]*$"]

詳細

Oracle Linux Cloud Developerイメージを使用するインスタンスは、OS管理サービスで管理できません。

回避策

Oracle Linux Cloud DeveloperインスタンスにOS管理サービス・エージェント(osms-agent)をインストールしないでください。

詳細

オブジェクト・ストレージ・バケットからカスタム・イメージをインポートまたはエクスポートしようとすると、次のようなエラーが発生する場合があります:

無効なbucketName: イメージをエクスポートするために指定したネームスペースまたはバケットは存在しません

このエラーは、フェデレーテッド・ユーザーと、動的グループに関連付けられたインスタンス・プリンシパルで認証するユーザーに対して発生します。

回避策

事前認証済リクエストを作成し、事前認証済リクエストを使用してイメージをインポートまたはエクスポートします。事前認証済リクエストによって、ユーザーは独自の資格証明を持たずにバケットまたはオブジェクトにアクセスできるようになります。事前認証済リクエストの作成方法および使用方法を説明する詳細なステップについては、事前認証済リクエストの使用および事前認証済リクエストを参照してください。

詳細

コンソールでブート・ボリューム・バックアップからインスタンスを作成しようとすると、次のようなエラーが発生する場合があります:

"インスタンスを作成するためのソース・イメージのロード中にエラーが発生しました。このイメージにアクセスする権限がユーザーにないか、イメージが別のリージョンにある可能性があります。イメージが別のリージョンにある場合でも、インスタンスの起動は可能です。"

ブート・ボリューム・バックアップに使用される削除済のイメージ・メタデータが含まれていたコンパートメントも削除された場合、このエラーが発生する可能性があります。

回避策

コンパートメントが削除されている場合は、CLIを使用してインスタンスを作成します。CLIの使用の詳細は、コマンド・ライン・インタフェース(CLI)を参照してください。

CLIを使用してブート・ボリュームからインスタンスを作成するには、コマンド・プロンプトを開き、起動コマンドを実行します。イメージまたはブート・ボリュームを使用してインスタンスを起動するには、--source-detailsパラメータを含めます。

oci compute instance launch --availability-domain <availability_domain> --compartment-id, -c <compartment_ocid> --shape <shape> --subnet-id <subnet_id> --source-details <file://path/to/file>

詳細

Terraformを使用して容量予約からインスタンスを削除することはできません。

回避策

次のいずれかの回避方法を使用します。

• コンソール、CLIまたはSDKを使用して、容量予約からインスタンスを削除します。
• Terraformを使用してインスタンスを削除するには、次のTerraformスクリプトの例のように、capacity_reservation_idを空白に設定します:

  capacity_reservation_id = " "

詳細

容量予約に50を超える容量構成を作成すると、内部エラーが発生します。エラーが発生した後は、容量予約に対してインスタンスを起動できません。

回避策

この問題を回避するには、容量予約に50を超える容量構成を追加しないようにします。

詳細

<shape>-core-reserved-countサービス制限数が正しくありません。「サービス制限」列の数値に1,000,000,000またはN/Aが表示されている可能性があります。「使用可能」列の数値に、「使用」列の数値より1,000,000,000小さい値、またはN/Aが表示されている可能性があります。1,000,000,000の値は最大値を示し、また異なる場合もあります。

回避策

正しいサービス制限については、容量予約のコンピュートを参照してください。

詳細

サービス制限の引上げをリクエストした場合、「サービス・カテゴリ」メニューには容量予約のカテゴリが含まれません。

回避策

「サービス制限更新のリクエスト」フォームで:

• 「サービス・カテゴリ」で、「その他」を選択します。
• 「リソース」で、「その他の制限」を選択します。
• 「リクエストの理由」フィールドに、引き上げる特定の制限を入力します。

詳細

インスタンス・プールを作成しようとすると、「認可に失敗したか、リクエストされたリソースが見つかりません」というエラーが発生して、インスタンス・プールの作成に失敗します。これは、インスタンス・プールで使用されるリソースにデフォルト・タグが含まれ、ユーザーがタグ・ネームスペースに対する権限を持たないために発生します。

回避策

インスタンス・プールのユーザー・グループに、タグ・ネームスペースOracle-Tagsに対する権限を付与するポリシー・ステートメントを追加します:

Allow group InstancePoolUsers to use tag-namespaces in tenancy where target.tag-namespace.name = 'oracle-tags'

ポリシーの詳細は、ユーザーによるコンピュート・インスタンスの構成、インスタンス・プールおよびクラスタ・ネットワークの管理を参照してください。デフォルト・タグの詳細は、自動タグのデフォルトの理解を参照してください。

詳細

インスタンスを作成しようとすると、エラー・コードInternalErrorおよびホスト容量不足のようなメッセージが表示され、インスタンスの起動に失敗します。これは、リクエストされたフォルト・ドメインおよび可用性ドメイン内のシェイプに対する物理インフラストラクチャ容量が不足しているために発生します。

回避策

容量は通常、ほとんどのシェイプですぐに使用可能になります。この問題を回避するには、次のことを実行します:

• インスタンスを作成する前に、特定のシェイプで容量を使用できるかどうかを判断するには、CreateComputeCapacityReport操作を使用します。
• 前世代のシェイプを使用している場合は、かわりに現在の世代のシェイプを使用してインスタンスを作成します。前世代のシェイプの容量は制限されています。
• 別の可用性ドメイン内にインスタンスを作成します。
• フォルト・ドメインを指定せずにインスタンスを作成します。
• より小さいシェイプまたは別のシリーズのシェイプを使用してインスタンスを作成します。
• 数分待ってから再試行します。

詳細

イメージの転送中暗号化の値がnullの場合、イメージから作成されたインスタンスの転送中暗号化の値をnull以外の値に設定できます。

回避策

解決に向けて取り組んでいます。

詳細

Windows Serverインスタンスをドメイン・コントローラとして使用する場合は、モニタリング・サービスやOS管理サービスなどのOracle Cloud Agentに依存する機能を使用できません。この状況は、Oracle Cloud AgentによってWindowsにインストールされたサービスが仮想アカウントで実行されるが、仮想アカウントがドメイン・コントローラ・スコープでサポートされていないために発生します。

回避策

1. 管理者として次のPowerShellコマンドを実行して、Oracle Cloud Agentアップデータを無効にします:

   net stop OCAU

   ノート
   
   Oracle Cloud Agentアップデータを無効にすると、それ以降、インスタンスはOracle Cloud Agentの自動更新を受信できなくなります。Oracle Cloud Agentは手動で更新できますが、更新した後にこの回避策を繰り返す必要があります。

2. 使用するOracle Cloud Agent機能ごとに、該当するNTサービスでサービスの実行ユーザーを更新し、ドメイン・ユーザー・アカウントが使用されるよう更新します。

   次の表に従って、ドメイン・アカウントがパフォーマンス・モニターのユーザーまたは管理者グループのメンバーであることを確認します。「Active Directoryユーザーとコンピュータ」を使用して、ドメインから適切なユーザー・アカウントを見つけ、次の表に示すように、ユーザーがターゲット・ドメインのローカル・グループのメンバーであることを確認します。

   Oracle Cloud Agent機能	ターゲット・アカウント・タイプ	ターゲット・ドメイン・ローカル・グループ
   Oracle Cloud Agent NTサービス(コンピュート・インスタンスのモニタリング・プラグインを含む)	ドメイン・サービス・アカウントまたはユーザー・アカウント	パフォーマンス・モニター・ユーザー
   コンピュート・インスタンスの実行コマンド・プラグイン	ドメイン・サービス・アカウント、またはローカル管理権限を持つドメイン・ユーザー・アカウント	管理者グループ
   Oracle Cloud Unified Monitoringインストーラ・サービス(カスタム・ログのモニタリング・プラグイン)	ドメイン・サービス・アカウント、またはローカル管理権限を持つドメイン・ユーザー・アカウント	管理者グループ
   OS管理サービス・エージェント・プラグイン	ドメイン・サービス・アカウント、またはローカル管理権限を持つドメイン・ユーザー・アカウント	管理者グループ
   Oracle Cloud Agentアップデータ	ドメイン・サービス・アカウント、またはローカル管理権限を持つドメイン・ユーザー・アカウント	管理者グループ

3. services.mscを使用して、サービスの実行ユーザーを、適切なドメイン・グループのドメイン・ユーザー・アカウントに更新します。

詳細

コンピュート・サービスでのイメージの処理方法が変わったため、ブート・ボリューム・バックアップを作成すると、バックアップが予想より大きくなります。ブート・ボリューム・バックアップが、ブート・ボリューム・サイズより大きくなる場合もあります。

回避策

解決に向けて取り組んでいます。

詳細

コンピュート・インスタンスで、次のいずれかのタスクに関するエラーが断続的に発生することがあります:

• SSHを使用したインスタンスへの接続。
• DNS参照の実行
• http://169.254.169.254/*でのメタデータ・サービスへのアクセス。

回避策

この問題を一時的に回避するには、インスタンスで次のコマンドを実行します:

sudo ethtool -G ens3 tx 513 && sudo ethtool -G ens3 tx 512

詳細

2019年3月22日から2019年4月9日の間に、Oracle Linux 7 yumリポジトリを使用してインスタンスでyum更新を実行した場合、インスタンスの再起動後にiSCSIにアタッチされたブロック・ボリュームを使用できないという問題が発生する可能性があります。

回避策

この問題は、再起動時にインスタンスがiSCSIノードに自動的にログインするよう構成されていない場合に発生します。自動ログインを構成するには、次のコマンドを実行してiscsi-initiator-utilsパッケージのバージョンを更新します:

sudo yum update -y iscsi-initiator-utils-6.2.0.874-10.0.7.el7

詳細

Oracle Cloud Infrastructureでは、コンピュート・インスタンスにiSCSIでアタッチされたリモートのブート・ボリュームとブロック・ボリュームがサポートされます。これらのiSCSIにアタッチされたボリュームは、iscsidサービスによって管理されます。サービスがクラッシュしたり、システム管理者が誤ってサービスを停止したりするなど、なんらかの理由でこのサービスが停止した場合に備え、インフラストラクチャの安定性を高めるためにiscsidサービスを自動的に再起動することが重要です。

回避策

iscsidサービスが自動的に再起動するように構成するステップについては、「自動的に再起動するためのLinux iSCSIサービスの更新」を参照してください。

詳細

想マシン(VM)インスタンス用のインスタンスのipxeScript属性に値を指定すると、インスタンスは準仮想化アタッチメントではなく、ブート・ボリュームのiSCSIアタッチメントで起動します。

回避策

解決に向けて取り組んでいます。

詳細

次のコマンドを実行してファイアウォールをリロードした後に、コンピュート・インスタンスでシステム・ハングが発生することがあります:

firewall-cmd --reload

実行中のインスタンスでこのコマンドを使用してファイアウォールをリロードすると、ファイアウォール・ルールがリロードされる順序に基づいて、インスタンスのブート・ボリュームがiSCSI接続を失ってクラッシュする可能性があります。

回避策

これを回避するには、firewall-cmdにreloadパラメータを指定しないようにします。かわりに、iSCSI接続を失わないように、最初にコールするときにpermanentパラメータを使用してfirewall-cmdコマンドを2回実行してください。

例:

firewall-cmd --permanent
firewall-cmd

詳細

Windows 2016を実行しているインスタンスで、インスタンスのネットワーク接続に問題がない場合でも、タスクバーのネットワーク接続アイコンに赤色の「x」が表示されます。

回避策

explorer.exeプロセスをリサイクルすると、アイコンに正しいステータスが表示されます。ただし、これは永続的な修正ではありません。インスタンスを再起動すると、赤色の「x」が再表示されます。

詳細

Ubuntu 18.04プラットフォーム・イメージの2018年10月リリースでは、iSCSIdがデフォルトで無効になっているため、このオペレーティング・システムを使用しているインスタンスでは、iSCSI通信が瞬間的に中断した場合、システム・ハングが発生することがあります。

回避策

次のコマンドを実行して、インスタンスでiSCSIdを有効にします:

sudo systemctl enable iscsid && sudo systemctl start iscsid

詳細

GetInstance操作またはListInstances操作をコールすると、InstanceSourceViaImageDetailsのkmsKeyId属性がnullになっています。

回避策

GetBootVolume操作をコールし、BootVolumeのkmsKeyId属性から値を取得します。

詳細

Ubuntuを実行しているコンピュート・インスタンスでUFWを有効にすると、インスタンスが正常に再起動されません。

回避策

ファイアウォール・ルールの編集にUFWを使用しないでください。プラットフォーム・イメージは、インスタンスがそのブート・ボリュームとブロック・ボリュームに発信接続できるように、ファイアウォール・ルールで事前構成されています。詳細は、「必須のファイアウォール・ルール」を参照してください。UFWがこれらのルールを削除すると、再起動中にインスタンスがブート・ボリュームとブロック・ボリュームに接続できなくなります。

新しいファイアウォール・ルールを変更または追加するには、かわりに/etc/iptables/rules.v4ファイルを更新します。ここでファイアウォール・ルールを変更すると、再起動後に有効になります。ルールを即座に有効にするには、次を実行します:

$ sudo su -
# iptables-restore < /etc/iptables/rules.v4

詳細

新しく作成されたカスタムWindowsイメージから起動されたインスタンスにログインできません。この問題が発生するのは、WMF 5.0へのアップグレード後にSysprepに問題が発生し、イメージの一般化プロセスが失敗するためです。

回避策

「WMF 5.0のインストール後にSysprepが失敗する」に記載されているステップを実行します。

詳細

Ubuntu 16 LTSおよび新しいリリースのUbuntuをインポートする場合、DHCPはゲートウェイ構成を取得できないため、VNICのゲートウェイへのデフォルト・ルートの設定に失敗します。

回避策

インポート後に、デフォルト・ルートを静的に構成します。手順は、次のとおりです:

1. 次のスクリプトを作成します:

   #! /bin/bash -e
   								ROUTER_IP=$(/usr/bin/curl --silent http://169.254.169.254/opc/v1/vnics/ | grep "virtualRouterIp" | grep -oP "\d+\.\d+\.\d+\.\d+" | head -n 1)
   								echo "Found Router IP $ROUTER_IP"
   
   							ip route add default via $ROUTER_IP

   これを/usr/local/bin/configure_default_route.shに保存します

2. 次のコマンドを実行して、スクリプトを実行可能にします:

   sudo chmod +x /usr/local/bin/configure_default_route.sh

3. システムが起動するたびに起動されるように、次を/etc/network/interfacesに追加します:

   # OCI Emulated boot network interface
   								auto ens3
   								iface ens3 inet dhcp
   							post-up /usr/local/bin/configure_default_route.sh

詳細

インポートされたカスタム・イメージから起動されたインスタンスからセカンダリVNICをデタッチすると、操作がタイムアウトする場合があります。

回避策

ホット・プラグ・モジュールのacpiphpをロードして、セカンダリVNICをLinuxで正しくデタッチする必要があります。VNICのデタッチに失敗した場合、lsmodコマンドを実行してロード済モジュールのリストを表示し、acpiphpのリストを確認します。リストに表示されない場合は、次のコマンドを実行してモジュールをロードします:

modprobe acpiphp

セカンダリVNICのデタッチ操作を再試行してください。操作を正常に完了するために、システムを再起動することが必要な場合があります。

詳細

カーネルのバグのため、次のオペレーティング・システムでは、セカンダリVNIC機能はサポートされていません:

• CentOS 4、5
• Oracle Linux 4、5
• RHEL 4、5

再起動後、セカンダリVNICは動作しなくなります。

回避策

解決に向けて取り組んでいます。

詳細

イメージをエクスポートしようとすると、エクスポートが失敗し、イメージが無効であることを示すエラーが表示されます。このエラーは、US West (Phoenix)リージョンでのみ発生します。

回避策

この問題を回避するには:

1. エクスポートしようとしているイメージに基づいて新規インスタンスを起動し、イメージに次のシェイプのいずれかを指定します:

   • BM.Standard1.36

   • BM.DenseIO1.36

   • VM.DenseIO1.4

   • VM.DenseIO1.8

   • VM.DenseIO1.16

2. 「カスタム・イメージを作成するには」で説明しているステップを使用して、カスタム・イメージを作成します。

カスタム・イメージを作成した後、この新規イメージをエクスポートできます。

詳細

ベア・メタル・インスタンスへのSSH接続を初めて確立する際、SSHクライアントは正しいキーを送信する必要があります。~/.sshまたは~/.ssh/configファイルに複数のSSHキーが構成されている場合、初めて認可を試行するときにクライアントが正しいキーを送信できないことがあり、次のエラー・メッセージが表示される可能性があります:

Received disconnect from UNKNOWN port 65535:2: Too many authentication failures.

回避策

次の例に示すように、SSHコマンドの接続文字列を変更し、構成ファイル・フラグの-Fを使用してデフォルトの構成ファイルをオーバーライドし、-o IdentitiesOnly=yesオプションを指定してSSHクライアントが指定のキーを使用するよう強制し、アイデンティティ・ファイル・フラグの-iで使用するSSHキーを指定します:

ssh -F /dev/null -o IdentitiesOnly=yes -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443...

詳細

VMインスタンス: 2017年8月26日以降に起動された仮想マシン(VM)インスタンスに対するシリアル・コンソール接続のみを作成できます。

ベア・メタル・インスタンス: 2017年10月21日以降に起動されたベア・メタル・インスタンスに対するシリアル・コンソール接続のみを作成できます。

回避策

VMインスタンスとベア・メタル・インスタンスに指定された日付より前に起動されたインスタンスへのシリアル・コンソール・アクセスが必要な場合、インスタンスのカスタム・イメージを作成することで、この問題を回避できます。カスタム・イメージに基づいて新規インスタンスを起動すると、新規インスタンスからシリアル・コンソールにアクセスできるようになります。カスタム・イメージの作成の詳細は、「カスタム・イメージの管理」を参照してください。

詳細

ListImages API操作には、operatingSystemおよびoperatingSystemVersionに対するサーバー側のフィルタリング用パラメータが含まれます。ただし、これらのパラメータは現在非アクティブです。また、Imageレスポンス・オブジェクトのドキュメントにはoperatingSystemおよびoperatingSystemVersion属性が含まれますが、現在、オブジェクトはこれらのフィールドを戻しません。

回避策

プラットフォーム・イメージの表示名を参照してください。プラットフォーム・イメージの表示名には、オペレーティング・システムとオペレーティング・システムのバージョンが含まれます。たとえば、プラットフォーム・イメージがOracle-Linux-7.2-2016.09.18-0の場合、Oracle Linuxはオペレーティング・システムであり、バージョンは7.2です。

欠落は認識されており、これらのパラメータと属性をサポートすることが予定されています。

詳細

ネットワーク・マネージャ・サービスがインストールされている場合、インスタンスの再起動が失敗する可能性があります。

回避策

ネットワーク・マネージャ・サービスが必要ない場合は、アンインストールできます。ネットワーク・マネージャ・サービスが必要な場合は、インスタンスを再起動する前にネットワーク・インタフェース構成ファイルを変更します。NM_CONTROLLED構成キーをnoに設定します:

NM_CONTROLLED="no"

通常、ネットワーク・インタフェース構成ファイルは、次の場所にあります:

/etc/sysconfig/network-scripts/ifcfg-<interface_name>

詳細

一部のFastConnectネットワーキング設定では、Oracle Kspliceなどのユーティリティの自動パッチ更新ができません。

回避策

/etc/uptrack/uptrack.confファイルで、次のすべてのインスタンスを置き換えます:

oraclecloud-updates-ksplice.oracle.com

置換後:

updates.ksplice.<region>.oci.oraclecloud.com 

たとえば、ホーム・リージョンが米国西部(フェニックス)、置換します:

oraclecloud-updates-ksplice.oracle.com

置換後:

updates.ksplice.us-phoenix-1.oci.oracle.com

この回避策は、サービス・ゲートウェイに適用されます。プライベート・エンドポイントには適用されません。

詳細

2019年9月より前に作成されたOracle LinuxインスタンスでOS管理サービスを使用している場合、OS管理サービスが有効になっていないときに、「インスタンスの詳細」ページに、サービスが有効になっている(Oracle Cloud Management Agent: 有効)と誤って表示されることがあります。

この問題は、コンピュート・インスタンスのメタデータでisManagementDisabledフラグが定義される前に作成されたインスタンスに影響します。このフラグが存在しないため、これらのインスタンスのメタデータはOS管理サービスに対して正しく設定されません。

回避策

この問題を解決するには、isManagementDisabledフラグをfalseに設定します:

1. インスタンスのエージェント構成で、isManagementDisabledオプションをfalseに設定します:

   oci compute instance update --instance-id <instance_OCID> --agent-config '{"isManagementDisabled": false, "isMonitoringDisabled": false}'

2. CLIを使用して、フラグが更新されていることを確認します:

   oci compute instance get --instance-id <instance_OCID>

   出力では、更新されたフラグは"is-management-disabled": falseとして表示されます。

   {
     "data":
       "agent-config": {
         "is-management-disabled": false,
         "is-monitoring-disabled": false
       },
   ...
   }

3. SSHを使用してインスタンスに接続し、cURLを使用してインスタンス・メタデータ・サービスをコールし、コンピュート・インスタンス内でフラグが更新されていることを確認します:

   curl http://169.254.169.254/opc/v1/instance/

   出力では、更新されたフラグは"managementDisabled" : falseとして表示されます。

   {
     ...
     "agentConfig" : {
       "monitoringDisabled" : false,
       "managementDisabled" : false
     }
   }

現在、コンピュートで解決された既知の問題はありません。