Oracle Private Cloud Applianceはアプライアンスとして配布されます: 選択したハードウェアおよびソフトウェア・コンポーネントで構成される、完全で管理されたシステム。 事前構成されたアプライアンス・コンポーネントに追加のソフトウェア・パッケージをインストールする場合、それはコンピュート・ノード、管理ノード、またはストレージ・コンポーネントであるため、アプライアンスの操作を全体として混乱させる可能性のある新しい変数を導入することになります。 他の指示がないかぎり、Oracleは、サード・パーティから、またはOracle Linux YUMリポジトリなどのOracle独自のソフトウェア・チャネルから追加パッケージをインストールまたはアップグレードするように指示します。

回避方法: 内部のOracle Private Cloud Applianceシステム・コンポーネントには追加のソフトウェアをインストールしません。 内部プロセスで特定の追加ツールが必要な場合は、Oracleの担当者に連絡してこれらの要件を話し合ってください。

ノード・マネージャ・データベースのロールは、プロビジョニング時にコンピュート・ノードが経由する様々な状態を追跡することです。 プロビジョニングが成功した後、データベースは停止しても「実行」としてノードをリストし続けます。 完全に機能しているノードでは、サーバー・ステータスがOracle VM Managerによって追跡されます。 ただし、Oracle Private Cloud Applianceダッシュボードには、ノード・マネージャのステータス情報が表示されます。 これによって、ダッシュボードとOracle VM Manager間で情報に一貫性がなくなる可能性がありますが、バグとはみなされません。

回避方法: 操作コンピュート・ノードのステータスを検証するには、Oracle VM Managerユーザー・インタフェースを使用します。

バグ17456373

provisioningまたはall_provisioningタイプのロックの目的は、すべてのコンピュート・ノードがプロビジョニング・プロセスの開始または継続を回避することです。 ただし、アクティブなロックが設定されているときに、実行中のコンピュート・ノードをOracle Private Cloud Appliance CLIから再プロビジョニングしようとすると、コンピュート・ノードの状態はreprovision_onlyに変更され、"DEAD"にマークされます。 プロビジョニング・ロックが非アクティブ化されている場合、コンピュート・ノードのプロビジョニングは通常どおり続行されます。

バグ22151616

コンピュート・ノードのプロビジョニングは完了までに数時間かかる場合があります。 ただし、これらのノードはプロセスの初期にOracle VMサーバー・プールに追加されますが、メンテナンス・モードにはなりません。 理論上は、検出されたサーバーをOracle VM Managerで使用できますが、Oracle Private Cloud Applianceダッシュボードでプロビジョニングが完了したことが示されるまで、どんな方法でも構成を変更しないでください。

回避方法: コンピュート・ノードのプロビジョニングの完了を待機します。 Oracle VM Managerでは、コンピュート・ノードやサーバー・プールは変更しないでください。

バグ22159111

コンピュート・ノードのプロビジョニング中に、Fabric Interconnect管理ソフトウェアは必要なInfiniBand接続を設定します。 プロビジョニング・プロセスは、この構成タスクが完了するまで待機しますが、特定の高負荷状況では、Fabric Interconnectはすべてのコンピュート・ノードの詳細に十分な速さで移入できず、問合せ時に部分情報を返します。 このタイミングの問題の結果、プロビジョニング・プロセスが停止され、コンピュート・ノードにdeadのマークが付けられます。

回避方法:コンピュート・ノードのプロビジョニングが失敗し、state=deadが表示された場合、最初のアクションはノードを再プロビジョニングすることです。 Fabric InterconnectのInfiniBand構成が完了したら、コンピュート・ノードを正しくプロビジョニングする必要があります。

バグ28679751

Oracle Private Cloud Appliance CLIを使用すると、実行中の仮想マシンをホストしている場合でも、コンピュート・ノードの再プロビジョニングを強制的に実行できます。 コンピュート・ノードはメンテナンス・モードになっていません。 したがって、アクティブな仮想マシンが停止したり、別のコンピュート・ノードに移行されることはありません。 かわりに、これらのVMは「実行」ステータスのままで、Oracle VM Managerはホスト・コンピュート・ノードをn/aとして報告します。

回避方法: この特定の状況では、VMは移行できなくなります。 これらは強制終了し、再起動する必要があります。 再起動が成功すると、サーバー・プールに定義された起動ポリシーに従って、別のホスト・コンピュート・ノードの通常動作に戻ります。

バグ22018046

ネットワーク・インタフェース・ボンディングのドライバがロードされると、デフォルトのbond0インタフェースが自動的に生成されます。 ただし、このインタフェースは、Ethernetベースのネットワーク・アーキテクチャを使用して、Oracle Private Cloud Applianceの管理ノードでアクティブ化または使用されません。

回避方法: bond0インタフェースは、使用可能な方法で構成されていないため、Ethernetベースのシステムで無視できます。 InfiniBandベースのシステムでは、bond0インタフェースは機能的で構成されています。

バグ29559810

Oracle Private Cloud ApplianceのすべてのEthernetネットワーク・ファブリックの設計は、VxLANのカプセル化と分散に重点的に依存しています。 このようにプロトコル・レイヤーを追加するにはCPUサイクルが追加され、その結果、通常のタグ付けまたはタグ付けされていないトラフィックと比較したネットワーク・パフォーマンスが低下します。 特に、VMとの接続を影響することがあります。 VxLAN処理のCPU負荷を補うために、VMネットワーク上のMTU (Maximum Transmission Unit)を9000バイトに増やすことができます。これは、標準アプライアンス・ネットワーク全体の設定です。 ただし、最終ポイント間でさらに大きなMTU設定がサポートされるように、ネットワーク・パスを慎重に分析する必要があります: 中間ネットワーク・デバイスが1500バイトのMTUのみをサポートしている場合、9000バイトのパケットの断片化によりパフォーマンスが低下します。

回避方法: VMトラフィックのデフォルトのMTUが1500バイトで必要なネットワーク・パフォーマンスを取得できない場合は、VMネットワークおよびVM自体でMTUを9000バイトまで増やすことを検討する必要があります。

バグ29664090

カスタム・ネットワークを作成すると、技術的には作成可能です。 - サポートされない - Oracle VM ManagerのVLANタグを変更します。 ただし、コンピュート・ノードを追加しようとすると、システムはサーバー上にネットワーク・インタフェースを作成しますが、変更されたVLAN構成の有効化に失敗します。 この時点で、カスタム・ネットワークは失敗状態でスタックしています: ネットワークやインタフェースを削除することはできません。また、VLANの構成を元のタグに戻すことはできません。

回避方法: Oracle VM Managerでは、アプライアンス・レベルのネットワークは変更しないでください。 回避策については説明されていません。また、リカバリ操作には、Oracle Private Cloud Appliance環境の停止時間が大幅に必要なものもあります。

バグ23250544

ブレークアウト・ケーブルを使用してカスタム・ネットワーク構成のアップリンク・ポートを分割し、その後、Oracle Private Cloud Appliance CLIを使用してポート・ペアの構成を開始すると、4つのすべてのブレークアウト・ポートが構成データベースに同時に格納されます。 これは、4つのブレークアウト・ポートの最初の2つをポート・グループに追加したときに、同じケーブルの残りの2つのブレークアウト・ポートが自動的になしという名前の別のポート・グループに追加され、これは無効のままになります。 内訳ポートの2番目のペアをポート・グループに追加すると、なしが選択したポート・グループ名で置換され、ポート・グループが有効になります。 例のコマンドのシーケンスでは、ステップごとの構成変更のステップを示しています。

PCA> create uplink-port-group custom_ext_1 '1:1 1:2' 10g-4x
Status: Success

PCA> list uplink-port-group
Port_Group_Name    Ports      Mode    Speed    Breakout_Mode    Enabled   State
---------------    -----      ----    -----    -------------    -------   -----
default_5_1        5:1 5:2    LAG     10g      10g-4x           True      (up)* Not all ports are up
default_5_2        5:3 5:4    LAG     10g      10g-4x           False     down
custom_ext_1       1:1 1:2    LAG     10g      10g-4x           True      up
None               1:3 1:4    LAG     10g      10g-4x           False     up
----------------
4 rows displayed
Status: Success

PCA> create uplink-port-group custom_ext_2 '1:3 1:4' 10g-4x
Status: Success

PCA> list uplink-port-group
Port_Group_Name    Ports      Mode    Speed    Breakout_Mode    Enabled   State
---------------    -----      ----    -----    -------------    -------   -----
default_5_1        5:1 5:2    LAG     10g      10g-4x           True      (up)* Not all ports are up
default_5_2        5:3 5:4    LAG     10g      10g-4x           False     down
custom_ext_1       1:1 1:2    LAG     10g      10g-4x           True      up
custom_ext_2       1:3 1:4    LAG     10g      10g-4x           True      up
----------------
4 rows displayed
Status: Success

回避方法: 4つすべてのブレークアウト・ポートを同時にネットワーク構成に追加する必要があるため、この動作は設計によるものです。 ポート・グループになしという名前が付けられ、それが4方向のブレークアウト・ケーブルで構成されている場合、それ以外(一時的に)構成されていても、これは無視できます。

バグ30426198

Oracle Private Cloud Appliance内のテナント・グループはOracle VMサーバー・プールに基づいており、テナント・グループに含まれるサーバー全体にわたるネットワークとストレージの追加構成が使用されます。 コンピュート・ノードがテナント・グループに追加されると、そのネットワークおよびストレージ構成は、テナント・グループにすでに存在する他のサーバーと同期されます。 このプロセスには数分かかるため、分散型電源管理(DPM)ポリシーがOracle VMサーバー・プールに対してアクティブな場合は中断されることがあります。 DPMポリシーでは、コンピュート・ノードのテナント・グループ構成プロセスがまだ進行中である間に、新規コンピュート・ノードが実行中の仮想マシンが含まれないため強制的に停止される場合があります。 不完全な構成では、コンピュート・ノードのレベルまたはテナント・グループで操作の問題が発生します。

回避方法: サーバー・プール・ポリシーが要件な場合、テナント・グループを変更する際、または拡張コンピュート・ノードのインストールおよび構成中に、一時的にオフにすることをお薦めします。

バグ30478940

ホスト・ネットワークを定義する場合、プレフィクス、ネットマスクおよびRoute_Destinationパラメータに対して無効な値または矛盾する値を入力できます。 たとえば、最初のオクテットとして0が付いたプレフィクスを入力した場合、0で始まるコンピュート・ノードのEthernetインタフェースでIPアドレスの構成が試行されます。 また、入力したルート宛先のネットマスク部分が無効の場合でも、例外が発生してもネットワークはまだ作成されています。 このように構成されていないネットワークが無効な状態の場合、標準コマンドで再構成または削除することはできません。

回避方法: Enterを押す前にCLIコマンド・パラメータをダブル・チェックしてください。 無効なネットワーク構成が適用されている場合は、--forceオプションを使用してネットワークを削除します。

バグ25729227

ホスト・ネットワークは、アプライアンス外部のコンピュート・ノードおよびホスト間の接続性を提供します。 外部ストレージを環境に接続するために実装されます。 仮想アプライアンス(以前のリリースのOracle VMおよびOracle Private Cloud Applianceのアセンブリとも呼ばれる)を、ホスト・ネットワーク上のロケーションからインポートしようとすると、Oracle VM Managerでは、アクティブ管理ノードをインポート操作のプロキシとして使用するようにコンピュート・ノードに指示されるため、失敗する可能性があります。

回避方法: 仮想アプライアンスがアクティブ管理ノードからアクセス可能なロケーションに存在することを確認してください。

バグ25801215

multipath.confのZFSスタンザは、Oracle Private Cloud Applianceソフトウェアによって制御されます。 内部ZFS Storage Applianceはアプライアンスの重要なコンポーネントであり、マルチパス構成は内部要件にあわせて調整されます。 アプライアンスのパフォーマンスおよび機能に悪影響を与える可能性があるため、multipath.confでZFSパラメータを変更しないでください。

カスタマイズが(外部)ZFSストレージに適用された場合でも、Oracle Private Cloud Appliance Controllerソフトウェアの更新時に上書きされます。 更新前に、ファイルのバックアップが保存されます。 他のベンダーからのストレージ・デバイスに対するmultipath.confのその他のスタンザでのカスタマイズは、アップグレード中も保持されます。

バグ25821423

Oracle Private Cloud Appliance内部ZFS Storage ApplianceにLUNを追加するときは、OVMターゲット・グループの下にLUNを追加する必要があります。 このデフォルト・ターゲット・グループのみがサポートされます。追加のターゲット・グループは使用できません。 ただし、イニシエータ側ではデフォルトの構成を使用しないでください。使用しない場合は、すべてのLUNが"All Initiators"グループにマップされ、システム内のすべてのノードがアクセス可能になります。 このような構成は、アプライアンス内でいくつかの問題を発生させる可能性があります。

かわりに、内部ストレージ上の追加のカスタムLUNを1つ以上のカスタム・イニシエータ・グループにマップする必要があります。 これにより、LUNは目的のイニシエータにマップされ、アプライアンス・ソフトウェアによってデフォルトの"All Initiators"グループに再マップされません。

回避方法: 内部ZFS Storage Applianceに追加のカスタムLUNを作成するときは、常にデフォルトのターゲット・グループを使用しますが、LUNが1つ以上のカスタム・イニシエータ・グループにマップされていることを確認してください。

Oracle Bug#22309236およびOracle Bug#18155778

ZFS Storage Applianceのストレージ・ヘッド間でフェイルオーバーが発生すると、仮想マシン操作がディスク・アクセスの一時的な損失によって中断する可能性があります。 ゲスト・オペレーティング・システム、およびゲストとOracle VMの構成によっては、VMがハング、電源切断、またはリブートする場合があります。 この動作は、ストレージ・フェイルオーバーが完了するのに十分なリカバリ時間を許容しないiSCSI構成パラメータが原因です。

回避方法: /etc/iscsi/iscsid.confファイルのnode.session.timeo.replacement _timeoutの値を増やしてください。 詳細は、「ドキュメントID 2189806.1」のサポート・ノートを参照してください。

バグ24439070

Oracle Private Cloud Appliance Dashboardを使用して様々なアプライアンス・コンポーネントに複数の異なるパスワードを設定すると、Oracle VM Managerからロックされたり、Oracle VM Managerと他のコンポーネント間の通信が失敗する場合があります。これは、認証が失敗したためです。 この問題は、部分的に失敗したパスワード更新が原因で発生します。この場合、コンポーネントは新規パスワードを受け入れましたが、別のコンポーネントは引き続き古いパスワードを使用して接続します。

Oracle VM Managerおよび直接関連するコンポーネントOracle WebLogic ServerおよびOracle MySQLデータベースが関与する場合、認証の問題のリスクはかなり高くなります。 これらのコンポーネントのパスワードを変更するには、ovmmサービスを再起動する必要があります。 別のパスワード変更が数分以内に発生した場合、ovmmサービスがアクティブでなかったためにOracle VM Managerを更新する操作は失敗する可能性があります。 認証エラーにより、ovmmサービスが再起動できなくなります。

回避方法: Oracle Private Cloud Applianceダッシュボードを使用してアプライアンス・コンポーネントに異なるパスワードを設定する場合は、10分間隔で1つずつ変更してください。 パスワード変更の結果、ovmmサービスが停止した場合は、再起動してからさらに変更を加えるようにしてください。 認証の問題によりovmmサービスが再起動しない場合は、ファイル/nfs/shared_storage/wls1/servers/AdminServer/security/boot.propertiesを以前のバージョンのファイル(boot.properties.old)に置き換える必要があります。

バグ26007398

ラック・コンポーネントをカスタム・パスワードで構成した後は、新しくインストールされた拡張コンピュート・ノードのコンピュート・ノードILOMは、Walletでユーザーが設定したパスワードを自動的に引き継ぎません。 コンピュート・ノードは、正しくプロビジョニングし、ファクトリ出荷時のデフォルト・パスワードを使用していても、WalletはそのILOMへのアクセス権を維持します。 ただし、カスタム・パスワードがすべてのコンポーネントにわたり正しく同期されるようにすることをお薦めします。

回避方法: Oracle Private Cloud Appliance DashboardまたはCLIを使用してコンピュート・ノードILOMパスワードを設定または更新します。 これにより、Walletとコンピュート・ノードILOMの両方で新しいパスワードが設定されます。

バグ26143197

SSHを使用してアクティブ管理ノードにログインする場合、通常は、両方の管理ノード間で共有されている仮想IPアドレスを使用します。 ただし、これらは個別の物理ホストであるため、異なるホスト・キーを持ちます。 ホスト鍵がSSHクライアントに格納されていて、セカンダリ管理ノードへのフェイルオーバーが発生した場合、次に仮想IPアドレス経由でSSH接続を作成しようとするとホスト鍵検証が失敗します。

回避方法: SSHクライアントにホスト・キーを格納しないでください。 キーが格納されている場合は、通常は.ssh/known_hostsのユーザー・ディレクトリ内にあるクライアント・ファイル・システムから削除します。

バグ22915408

デフォルトのコンピュート・ノード構成では、データ・センター・ネットワークの追加ストレージ・リソースへの接続は許可されません。 コンピュート・ノードは、ホストする仮想マシンに対してパブリック接続を有効にするために、データ・センター・サブネットに接続されていますが、コンピュート・ノードのネットワーク・インタフェースには、そのサブネットのIPアドレスがありません。 そのため、SANまたはファイル・サーバーの検出は失敗します。

バグ17508885

Oracle Private Cloud ApplianceダッシュボードとOracle VM Managerユーザー・インタフェースはどちらも、Oracle WebLogic Server、Oracle Application Development Framework (ADF)およびOracle JDK 6に基づくアーキテクチャで稼働します。 このアーキテクチャでサポートされている暗号化プロトコルは、SSLv3およびTLSv1.0です。 Mozilla Firefox版の38.2.0以降では、自己署名証明書を使用したSSLv3接続をサポートしていません。 結果として、ユーザー・インタフェースのログイン・ページを開こうとすると、エラー・メッセージが表示されることがあります。

回避方法: デフォルトのMozilla Firefoxセキュリティ・プロトコルを次のようにオーバーライドします。

Oracle Bug#21622475およびOracle Bug#21803485

Oracle Private Cloud Appliance内のコンピュート・ノードは、プロビジョニング中、すべて単一のクラスタ化サーバー・プールに配置されます。 クラスタ化サーバー・プールは、プロビジョニング・プロセスの一部として作成されます。 構成パラメータの1つにクラスタ・タイムアウトがあります: サーバーがフェイルオーバー・イベントがトリガーされるまで使用できない時間。 誤検出を回避し、このような不要なフェイルオーバーを回避するために、Oracle Private Cloud Applianceサーバー・プールのタイムアウトは300秒に設定されています。 結果として、高可用性(HA VM)で構成された仮想マシンは、そのホストに障害が発生しても5分間使用できなくなります。 クラスタ・タイムアウトを過ぎると、HA VMはサーバー・プール内の別のコンピュート・ノードで自動的に再起動されます。

この動作は、バグではなく設計されたものです。 サーバー・プール・クラスタ構成は、フェイルオーバーの発生後にVMの再起動に遅延が発生します。

Oracle Private Cloud Applianceコマンドライン・インタフェースには、2.3.4がコントローラ・ソフトウェア・イメージを解凍し、新しいソフトウェア・スタックでアプライアンスを更新する前のリリースで使用されるupdate applianceコマンドが含まれています。 この機能は現在アップグレーダ・ツールの一部です。このためCLIコマンドは非推奨であり、次のリリースで削除されます。

回避方法: 将来の更新およびアップグレーダは、Oracle Private Cloud Appliance Upgraderを通じて実行されます。

バグ29913246

Oracle Private Cloud Applianceコマンドライン・インタフェースは、クローズされたシェル環境を使用して、またはシングル・コマンド・モードで対話モードで使用できます。 シングル・コマンド・モードを使用する場合、コマンドと引数はOracle Linuxコマンド・プロンプトで1行として入力します。 そのような1つのコマンドに引用符などの特殊文字が含まれている場合、それらを取り除いて正しく解釈できません。

回避方法: コマンド引数から特殊文字を削除しないように、対話型モードでCLIを使用します。 シングル・コマンド・モードを使用する必要がある場合は、必要に応じて引数を一重引用符および二重引用符で囲み、外部引用符のみが削除されるようにします。 たとえば、このコマンドを次のように変更します。

# pca-admin create uplink-port-group myPortGroup '2:1 2:2' 10g-4x

変更後

# pca-admin create uplink-port-group myPortGroup "'2:1 2:2'" 10g-4x

同じ引用符を二重に使用しないでください。

バグ30421250

Oracle Private Cloud Applianceアップグレーダ・テストの実行方法が変更されたため、テストを実行するたびにチェックの出力が異なる順序で表示される可能性があります。

この動作はバグではありません。 回避策は必要ありません。

バグ30078487

Oracle Private Cloud Applianceが最大限度に構成され、高負荷が実行されている場合、一般的なDHCP/IP帯域幅の制限を超えるという状況が発生する可能性があります。 この場合、DHCPクライアントは、最終的にタイムアウトになって仮想マシンIPアドレスが失われるため、0.0.0.0にリセットされます。 これは、完全な帯域幅の容量でシステムが動作している場合の正常な動作です。

回避方法: 十分な帯域幅が使用可能な場合は、仮想マシンからdhclientコマンドを発行して新しいIPアドレスをリクエストして、この状況からリカバリしてください。

バグ301 43723

Oracle Private Cloud Appliance上のOracle VM Mangerのストレージ・ネットワークに仮想マシン・ロールを追加しようとすると、クラスタでハートビート・ネットワーキングが失われ、実行中の仮想マシンとそのワークロードに影響を与える可能性があります。 この操作はOracle Private Cloud Applianceではサポートされていません。

回避方法: VMロールをstorage-intネットワークに追加しないでください。

バグ30936974

Oracle Private Cloud ApplianceでOracle VM Mangerの管理ネットワークに仮想マシン・ロールを追加しようとすると、コンピュート・ノードとの接続が失われます。 コンピュート・ノードはまだ起動していますが、マネージャはコンピュート・ノードと通信できないため、ラックは機能低下状態のままになります。 この操作はOracle Private Cloud Applianceではサポートされていません。

回避方法: VMロールをmgmt-intネットワークに追加しないでください。

バグ30937049

リリース2.3.4または2.4.xのいずれかのリリースからOracle Private Cloud Appliance Controller Softwareリリース2.4.3にアップグレードする場合は、最初に元のスタンバイ管理ノードをアップグレードする必要があります。 このアップグレードの一部は、アップグレード・プロセス中に自動的に行われるこのノードの再起動です。 この再起動後、元のスタンバイ管理ノードが新しいマスター・ノードになります。 次のステップでは、元のマスター管理ノードをアップグレードします。 ただし、かわりに元のスタンバイ・ノード(現在は新しいマスターであるノード)を誤って再起動すると、新しいマスター・ノードのOracle Private Cloud Applianceサービスが失敗するため、アップグレードを続行できなくなります。

回避方法:元のマスター・ノードを再起動します。 これにより、新しいマスター・ノードでOracle Private Cloud Applianceサービスが再起動され、元のマスター・ノードのアップグレードに進むことができます。

バグ30968544

ethernetベースのシステムでOracle Private Cloud Appliance Controller Softwareリリース2.4.3にアップグレードする場合、ストレージ・ネットワーク・アップグレードの完了前にスパイン・スイッチ構成を手動で変更しようとしないでください。 これを行うと、管理ノードがストレージ・ネットワークへのアクセスを失う可能性があります。 管理ノードが再起動される場合もあります。

また、Ethernetベースのシステムでコントローラ・ソフトウェア・リリース2.4.3へのアップグレードが完了したら、以前のソフトウェア・リリースからスパイン・スイッチ・バックアップをリロードしないでください。 これにより、管理ノードがストレージ・ネットワークへのアクセスを失う可能性があります。 管理ノードが再起動される場合もあります。 たとえば、次のエラー・メッセージが表示される場合があります:

192.0.2.1 is unreachable
[root@ovcamn05r1 data]# ping 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
 
 
Mount points under shared storage are gone.
[root@ovcamn05r1 ~]# ls /nfs/shared_storage/
logs NO_STORAGE_MOUNTED
 
 
No master management node any more. o2cb service is offline. Both management nodes are slave now.
[root@ovcamn05r1 ~]# pca-check-master
o2cb service is offline.
NODE: 192.0.2.2 MASTER: False

回避方法:スパイン・スイッチ構成で行われた変更を手動でロールバックし、両方の管理ノードを再起動します。

バグ31407007

ZFSストレージ・アプライアンスへの接続が中断されると、Oracle Cloud Infrastructureプロセスは操作を終了し、タスク・データベースで失敗とマークします。 管理ノードの再起動など、状態を更新するメカニズムがない場合があります。

回避方法:タスクが状態を変更できない場合は、タスク・データベースからタスクを削除し、oci_backupロック・ファイルを削除して、新しいバックアップ操作を実行します。 「クラウド・バックアップの削除」および「クラウド・バックアップ・サービスの構成」を参照してください。

バグ31028898

アクティブな管理ノードの再起動またはクラッシュ時にVMのOracle Cloud Infrastructureへのエクスポート・ジョブが実行されている場合、そのジョブ・ステータスはOracle VM Manager上のAbortedに変更されます。 場合によっては、Abortメッセージにかかわらず、エクスポータ・アプライアンスでエクスポート・ジョブが続行されます。

回避方法: Oracle Cloud InfrastructureへのVMのエクスポート・ジョブを再起動します。 ジョブがバックグラウンドでまだ実行されている場合は、ポップアップ・メッセージに「VMのエクスポート操作はすでに進行中です」が表示されます。 管理ノードのフェイルオーバーによりエクスポート・ジョブが正常に中断された場合、エクスポート・ジョブは再起動されます。

バグ31687516

Oracle Private Cloud Applianceソフトウェア・コントローラ・バージョン2.4.3リリースでは、pca-admin diagnose softwareコマンドは機能しなくなりました。

回避方法:別のヘルス・チェック・ツールを使用して診断機能を使用できるようになりました。 詳細は、「ヘルス・モニタリング」を参照してください。

バグ31705580