既知の問題

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

一般的な問題

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

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

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

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

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

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

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

問題: VMware Engine は、VMware vSphere バージョン 8.0 アップデート 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 のアウトバウンド通信もオンプレミス接続を介してルーティングされる可能性があります。 この構成は、 servicenetworking.googleapis.com ピアリングで VPC Service Controls を有効にすると、 ワークロード VM のインターネット アクセスを構成するで説明されているように発生します。

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