既知の問題

このページでは、Google Cloud VMware Engine の使用中に発生する可能性のある既知の問題について説明します。

一般的な問題

VMware Engine に影響する一般的な既知の問題は次のとおりです。

一時的なネットワーク イベントで組み込みの vCenter pNIC エラーアラームがトリガーされる

問題: 一時的な局所パケット異常により、vSphere Client コンソールで「高い pNIC エラー率が検出されました」などの組み込みの vCenter インフラストラクチャ アラームが断続的にトリガーされることがあります。

詳細: 組み込みの VMware アラート フレームワークは、短い固定のサンプリング ウィンドウで、基盤となる物理ネットワーク インターフェース カード（pNIC）カウンタを評価します。この設計により、ネットワーク層が正常な場合でも、vCenter は、一時的なノイズやスタンバイ vSAN アップリンクでの想定されるパケット ドロップ動作など、影響のない日常的なイベントに対して即座にアラートをトリガーできます。組み込みのパス冗長性により、これらのアラートは環境の可用性やデータの完全性に影響しません。

回避策: お客様による対応や回避策は必要ありません。組み込みの vCenter アラーム サンプリング感度の更新は短期的には予定されていないため、Google は、これらの誤検出を管理してフィルタリングするために、基盤となるプラットフォーム インテリジェンスをデプロイしました。対象となる本番環境では、Google はこれらの組み込みのお客様向けコンソール アラートを抑制します。代わりに、Google アナリティクス エンジンがインフラストラクチャ データをモニタリングし、30 分間の移動平均を使用して物理層を継続的に評価します。Google の分析エンジンが、ケーブルや光ファイバーの不具合など、物理的な劣化が継続していることを特定すると、プラットフォームは自動的に Google サポートにアラートを送信して問題を調査、解決し、自動通知を体系的に送信します。

ステータス: これは、組み込みの vCenter アラーム評価ロジックの既知の制限事項です。Google は、統合された基盤となるプラットフォーム インテリジェンスを通じてこの動作を管理します。VMware はこの問題を認識しており、回避策をアドバイスしています。

HCX Manager のアップグレードが vSphere バージョンのアップグレードとして誤ってラベル付けされる

問題: HCX Manager のアップグレードが、 Google Cloud コンソールで「vSphere バージョンのアップグレード」として誤ってラベル付けされています。

詳細: HCX アップグレードを特定する特定のメール通知は、イベントの少なくとも 14 日前と 24 時間前に送信されますが、自動化された「プライベート クラウドの更新が開始されました」と「プライベート クラウドの更新が完了しました」という通知は、一般的なプライベート クラウドの更新を反映しています。さらに、Google Cloud コンソール インターフェースでは、オペレーションに vSphere バージョンのアップグレードとして明示的にラベルが付けられます。この不一致は、特に最近フルスタック アップグレード（vSphere 7.x から 8.x など）を完了したお客様に混乱を招く可能性があります。これは、環境が別のメジャー プラットフォーム アップデートを受けているように見えるためです。

回避策: メンテナンスの時間枠の前に送信された HCX 固有の通知メールを確認して、作業範囲を確認します。スケジュールが一致する場合、 Google Cloud コンソールの「vSphere バージョンのアップグレード」ステータスは、HCX Manager の更新のみを指します。このため、ご対応は不要です。

ステータス: これは、現在の通知システムの設計における既知の制限事項です。

vSphere 8.0 Update 3 プライベート クラウドのプロビジョニング時間

問題: VMware Engine は、VMware vSphere バージョン 8.0 Update 3 と NSX-T 4.2.1.2 を使用して新しいプライベート クラウドをデプロイするようになりました。このアップグレード期間中、プライベート クラウドの作成と拡張では、更新されたバージョンを使用するすべての新しいデプロイに標準のプロビジョニング速度が使用されます。

詳細: プライベート クラウドの作成には最大 140 分かかることがあります。

回避策: 回避策は必要ありませんが、新しいプライベート クラウドをデプロイする場合や、既存のクラスタを拡張する場合は、追加の時間を計画してください。

検出: 新しいプライベート クラウドのデプロイや既存のクラスタの拡張に、通常よりも時間がかかることがあります。

ステータス: これは、バージョン アップデートと進行中のアップグレードによる想定された動作です。

セキュアブートが有効になるように構成された Windows Server 2022 KB5022842（OS Build 20348.1547）で仮想マシンが起動しない（90947）

Windows Server 2022 の更新プログラム KB5022842（OS Build 20348.1547）をインストールした後、仮想マシンがセキュアブートを有効にして構成されている場合は、ゲスト OS は起動できません。この問題を回避するには、次のいずれかを行います。

  • KB5022842 をスキップして、KB5023705 を使用する
  • 影響を受けている仮想マシンで、「セキュアブート」を無効にする

プライベート クラウドから VPC ネットワークへのルート アドバタイズで使用できる接頭辞の上限は 100 個まで

ルート アドバタイズがこの上限を超えると、一部の接頭辞が破棄される可能性があります。この上限内に収まるように、NSX-T Edge で集計機能を実装します。

VMware Engine は、Cloud Router を使用して、NSX からサービス プロデューサー VPC ネットワークに IP アドレス範囲（プレフィックスまたは CIDR）をアドバタイズします。これらのプレフィックスは、VPC ネットワークとピアリングされているサービス プロデューサー VPC ネットワーク内のカスタム動的ルートになります。

このピアリング関係でカスタム動的ルートをインポートするように VPC ネットワークを構成すると、NSX プレフィックスにより、VPC ネットワーク内のカスタムルートがピアリングされます。インポートできる NSX プレフィックスの数は次の 2 つの要因によって制限されます。

プライベート クラウドが完全にデプロイされる前に実行されたプライベート クラウド オペレーションが失敗する

権限昇格、プライベート クラウド拡張、ノードの置換などのオペレーションは、まだ完全にプロビジョニングされていない稼働中のプライベート クラウド上の Google Cloud VMware Engine ポータルで使用できます。ただし、プライベート クラウドが完全にデプロイされる前に（NSX-T や HCX を含む）VMware Engine でこれらのオペレーションを試行すると、失敗します。プライベート クラウドを完全にデプロイするまで、これらのオペレーションは試行しないでください。

VMware Engine は VPC Service Controls ではまだ完全にサポートされていない

VPC Service Controls には、VPC Service Controls の境界にあるプロジェクト内から VMware Engine を引き続き利用できるように、暫定的なソリューション（回避策）が実装されています。詳細については、VPC Service Controls をご覧ください。

Apigee とオンプレミスのインターネット ルーティングの相互運用性

VMware Engine と同じ VPC ネットワークで VPC ピアリングを使用して Apigee を使用し、オンプレミス接続を介してインターネット トラフィックをルーティングするように VMware Engine を構成すると、Apigee のアウトバウンド通信もオンプレミス接続を介してルーティングされる可能性があります。この構成は、ワークロード VM のインターネット アクセスを構成するで説明されているように、servicenetworking.googleapis.com ピアリングで VPC Service Controls を有効にすると行われます。

Apigee トラフィックがオンプレミス接続を介してルーティングされる場合、Apigee は外部 API バックエンド サービスへのアウトバウンド通信に構成済みの外部 IP アドレスを使用しなくなります。ファイアウォール構成で Apigee の外部 IP アドレスを使用している場合は、オンプレミス ネットワークからのトラフィックを許可するようにファイアウォール構成を更新する必要があります。

診断情報の収集中に ESXi ホストの接続が一時的に切断される

NVMe PCIe デバイスを使用する環境の ESXi ホストでは、診断情報の収集中に接続が一時的に切断されることがあります。

根本原因

vm-support コマンドまたは vCenter UI を使用して ESXi システムに関する情報を収集すると、ログは一時的に ramdisk /tmp ディレクトリに保存されます。システムに NVMe PCIe デバイスが多数ある場合や、ログファイルが大きい場合、ramdisk /tmp ディレクトリはすぐに一杯になります。その際、vm-support の収集が完了するまで ESXi ホストの接続が一時的に切断される可能性があります。

回避策:

ログバンドルの作成ページの [ログの選択] セクションから NVME マニフェストを除外すると、ramdisk /tmp ディレクトリが一杯になることを回避できるため、ESXi ホストのネットワーク接続が切断されなくなります。NVMe マニフェストを除外するには、次の操作を行います。

  1. cloudowner のユーザー名とパスワードを使用して vCenter にログインします。
  2. インベントリで、除外する vCenter Server インスタンスを右クリックします。
  3. [システムログをエクスポート...] をクリックします。
  4. ログバンドルを除外する ESXi ホストを選択します。
  5. [Select Logs] で [Storage] までスクロールし、[NVMe] オプションをオフにして、[Exported logs] をクリックします。これで NVMe マニフェストが除外されます。

この修正の詳細については、VMware ESXi 7.0 Update 3q をご覧ください。

プライベート クラウドのリソース名の変換エラー

Google Cloud VMware Engine で VMware Engine Horizon（VDI）を実行している場合、Google Cloud CLI と VMware Engine API の基準を満たすようにプライベート クラウド リソースの名前を変更した後にエラーが発生することがあります。

Horizon デスクトップ プールを適切なプロビジョニングで編集せずにプライベート クラウドのリソース名を変更すると、次のようなエラーが発生します。

Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No resource pool available for the pool: ic-pool-1

Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No datastores available for the pool: {}ic-pool-1

この問題を解決するには、スケジュール設定した名前の変換日までに次の手順を完了します。

  1. VMware Horizon ダッシュボードにアクセスします。
  2. フルクローン プールとインスタント クローン プールのすべての Horizon デスクトップ プールを編集し、[プロビジョニングを無効にする] に設定します。

プライベート クラウドのリソース名の変更が完了したら、次の手順を完了します。

  1. 各デスクトップ プールを編集して、フルクローン プールとインスタント クローン プールの両方に対して [vCenter 設定] タブで次の設定を再構成します。

    • リソースプール
    • Datastore

  2. 各プールのステータスを [Enable Provisioning] に戻します。

  3. プールからデスクトップを追加または削除して各プールをテストし、プロビジョニングが正しく機能していることを確認します。

VMware Engine チームでは、できるだけ早く相互運用性ソリューションを提供するよう努めています。機能の最新情報については、アカウント チームにお問い合わせください。