既知の問題

Linux Windows

このページでは、Compute Engine の使用中に発生する可能性のある既知の問題について説明します。Confidential VMs に特に影響する問題については、Confidential VMs の既知の問題をご覧ください。

Z3 VM の作成時に料金の見積もりを利用できない

Z3 のプレビュー期間中は、Google Cloud コンソールで料金の見積もりをご利用いただけません。Z3 VM に関連する料金については、Google Cloud SKU をご覧ください。

一般的な問題

以下の問題では、トラブルシューティングのガイダンスや一般情報が提供されます。

A2、C3、または G2 マシンタイプを指定するインスタンステンプレートを使用して予約または将来の予約リクエストを作成すると、問題が発生する

A2、C3、または G2 マシンタイプを指定するインスタンステンプレートを使用して予約を作成する場合や、審査のために将来の予約リクエストを作成して送信する場合、問題が発生します。具体的には次のとおりです。

予約の作成が失敗する可能性があります。成功した場合は、次のいずれかが該当します。
- 自動的に消費される予約（デフォルト）を作成した場合、一致するプロパティを持つ VM を作成しても、予約は消費されません。
- 特定の予約を作成した場合、その予約を特定して対象とする VM の作成は失敗します。
将来の予約リクエストの作成は成功します。ただし、審査のために提出すると、Google Cloud はリクエストを拒否します。

予約の作成または将来の予約リクエストの作成に使用されるインスタンステンプレートを置き換えることや、テンプレートの VM プロパティをオーバーライドすることはできません。A2、C3、または G2 マシンタイプのリソースを予約する場合は、代わりに次のいずれかを行います。

プロパティを直接指定して、新しい単一プロジェクトまたは共有予約を作成します。
次の手順に沿って、新しい将来の予約リクエストを作成します。
1. 既存の将来の予約リクエストによって、現在のプロジェクトで作成する（または将来の予約リクエストが共有されるプロジェクトで作成する）見込みがある将来の予約リクエストのプロパティが制限されないようにするには、将来の予約リクエストを削除します。
2. プロパティを直接指定して単一プロジェクトまたは共有の将来の予約リクエストを作成し、審査のために送信します。

Google Kubernetes Engine で `c3-standard--lssd` マシンタイプと `c3d-standard--lssd` マシンタイプを使用する場合の制限事項

Google Kubernetes Engine API を使用する場合、プロビジョニングするローカル SSD がアタッチされたノードプールは、選択した C3 および C3D マシンタイプと同じ数の SSD ディスクを持つ必要があります。たとえば、c3-standard-8-lssd を使用する VM を作成する場合は、SSD ディスクが 2 つ必要ですが、c3d-standard-8-lssd に必要な SSD ディスクは 1 つだけです。ディスクの数が一致しない場合は、Compute Engine コントロールプレーンでローカル SSD の構成ミスエラーが発生します。C3 または C3D の lssd マシンタイプに基づいて適切なローカル SSD ディスクの数を選択するには、汎用マシンファミリーのドキュメントをご覧ください。

Google Cloud コンソールで Google Kubernetes Engine を使用して c3-standard-*-lssd および c3d-standard-*-lssd VM を含むクラスタまたはノードプールを作成すると、ノードの作成に失敗するか、ローカル SSD をエフェメラルストレージとして検出できません。

C3D VM で単一フロー TCP スループットのばらつきがある

C3D VM が 30 vCPUを超える場合は、単一フローの TCP スループットの変動が生じる可能性があり、場合によっては 20～25 Gbps に制限されます。より高いレートを実現するには、複数の TCP フローを使用します。

T2D マシンシリーズを持つマネージドインスタンスグループで期待どおりに自動スケーリングしない

2023 年 6 月 18 日より前に作成されたプロジェクトで T2D マシンシリーズ VM があるマネージドインスタンスグループ（MIG）は、MIG 内の VM の CPU 負荷を正しく検出しません。このようなプロジェクトでは、T2D マシンシリーズ VM を持つ MIG の CPU 使用率に基づく自動スケーリングが正しくない可能性があります。

プロジェクトに修正を適用するには、Cloud カスタマーケアにお問い合わせください。

コアごとに 1 つのスレッドを使用する VM で、CPU 使用率のオブザーバビリティ指標が正しくない

VM の CPU がコアごとに 1 つのスレッドを使用している場合、CPU 使用率の Cloud Monitoring オブザーバビリティ指標（[Compute Engine] > [VM インスタンス] > [オブザーバビリティ]）は 50% まで縮小されます Tau T2D を除くすべてのマシンタイプで、デフォルトではコアあたり 2 スレッドです。詳細については、コアあたりのスレッド数を設定するをご覧ください。

100% に正規化された VM の CPU 使用率を表示するには、代わりに Metrics Explorer で CPU 使用率を表示します。詳細については、Metrics Explorer でグラフを作成するをご覧ください。

カスタムファイアウォールルールを使用すると、Google Cloud コンソールのブラウザでの SSH 接続が失敗することがある

カスタムファイアウォールルールを使用して VM インスタンスへの SSH アクセスを制御すると、ブラウザの SSH 機能を使用できなくなる可能性があります。

この問題を回避するには、次のいずれかを行います。

Google Cloud コンソールのブラウザの SSH 機能を使用して VM への接続を続行するには、TCP 用の Identity-Aware Proxy を有効にします。
default-allow-ssh ファイアウォールルールを再作成し、ブラウザの SSH を使用して VM への接続を続行します。
ブラウザの SSH ではなく、Google Cloud CLI を使用して VM に接続します。

特定の予約のサイズを縮小または削除すると、VM が他の予約を消費しなくなる

1 つ以上の VM によって消費された特定の予約を縮小または削除すると、孤立した VM は予約を消費できません。

（省略可）この問題を回避するために、特定の予約を対象とする VM の数が特定の予約を予定している VM の数と一致するまで VM を削除するか、VM の reservationAffinity プロパティを更新します。その後、特定の予約を縮小または削除できます。
問題を解決するには:
1. VM の削除、VM の reservationAffinity プロパティの更新、縮小された予約のサイズの変更、削除された特定の予約の再作成のいずれかまたは複数を行うことで、特定の予約内の VM の数を、その予約を対象としている VM の数と等しくします。
2. 残存している VM を停止して起動します。

詳細については、予約の削除と予約のサイズ変更をご覧ください。

`moveInstance` API または gcloud CLI を使用して VM またはディスクを移行すると、予期しない動作が発生する

gcloud compute instances move コマンドまたは project.moveInstance メソッドを使用して仮想マシン（VM）インスタンスを移行すると、予期しない動作（データが失われる、VM が削除されるなど）が発生することがあります。

VM を移行する場合は、ゾーンまたはリージョン間での VM インスタンスの移動の手順に沿って行うことをおすすめします。

`n2d-standard-64` マシンタイプを使用する VM にアタッチされたディスクが、パフォーマンスの上限に一貫して到達しない

n2d-standard-64 マシンタイプを使用する VM にアタッチされた永続ディスクが、100,000 IOPS の最大パフォーマンス上限に一貫して到達しません。これは読み取り IOPS と書き込み IOPS の両方のケースに該当します。

ディスクの一時的な名前

gcloud compute instances update コマンドまたは instances.update API メソッドで起動した仮想マシン（VM）インスタンスの更新中に、Compute Engine は、元の名前に以下の接尾辞を追加することで、VM のディスクの名前を一時的に変更することがあります。

-temp
-old
-new

更新が完了すると、Compute Engine によって接尾辞が削除され、元のディスク名が復元されます。

ディスクのサイズ変更によって一部の永続ディスクのレイテンシが増加

大きな永続ディスク（3 TB 以上）のサイズを変更すると、ディスクの I/O パフォーマンスが低下することがあります。この問題の影響を受けると、サイズ変更オペレーションの実行中に永続ディスクでレイテンシが増加する可能性があります。この問題は、すべての種類の永続ディスクに影響する可能性があります。

ローカル SSD で C3 VM を含む MBR イメージを使用する

c3-standard-44-lssd とそれより大きいマシンタイプを使用して作成された C3 VM は、MBR イメージで正常に起動しません。

サポートされていない PD-Standard ディスクと PD-Extreme ディスクを C3 VM と M3 VM にアタッチできる

Google Cloud CLI または Compute Engine API を使用する場合、デフォルトのブートディスクの種類は標準永続ディスク（pd-standard）です。ただし、pd-standard ディスクは C3 と M3 VM ではサポートされていません。また、C3 VM は pd-extreme ディスクをサポートしていません。

Google Cloud CLI または Compute Engine API を使用すると、次の問題が発生することがあります。

pd-standard はデフォルトのブートディスクタイプとして構成され、サポートされている別のブートディスクタイプ（pd-balanced や pd-ssd など）を指定しない限り、ディスクが作成されます。
C3 の一般提供（GA）以前は、pd-extreme ディスクを C3 VM にアタッチし、pd-standard ディスクを C3 および M3 VM にアタッチできました。

サポートされていないディスクタイプで C3 または M3 VM を作成した場合は、永続ディスクの種類の変更の説明に沿って、サポートされている新しいディスクタイプにデータを移動します。ディスクタイプを変更しない場合、VM は引き続き機能しますが、ディスクのアタッチ解除や再アタッチなど一部のオペレーションは失敗します。

回避策

この問題を回避するには、次のいずれかを行います。

Google Cloud コンソールを使用して、C3 または M3 VM を作成し、ディスクをアタッチします。コンソールでは、pd-balanced ブートディスクを使用して C3 VM と M3 VM が作成されます。サポートされていないディスクタイプを VM にアタッチすることはできません。
Google Cloud CLI または Compute Engine API を使用する場合は、VM の作成時に pd-balanced または pd-ssd タイプのブートディスクを明示的に構成します。

リソースベースのコミットメント割り当てに関する API レスポンスデータを使用している場合、自動プロセスが失敗することがある

次のそれぞれが発生すると、Compute Engine リソースベースのコミットメントの割り当てに関する API レスポンスデータを消費して使用する自動プロセスが失敗する可能性があります。自動化されたプロセスには、API レスポンスを使用または保存するコード、ビジネスロジック、データベースフィールドのスニペットを含めることができます。

レスポンスデータは、次のいずれかの Compute Engine API メソッドからのものです。
API レスポンスの本文でリソース割り当て上限のフィールドを定義するには、number ではなく int を使用します。このフィールドは、各メソッドで次の方法でアクセスできます。
- compute.regions.list メソッドの items[].quotas[].limit。
- compute.regions.get メソッドの quotas[].limit。
- compute.projects.get メソッドの quotas[].limit。
Compute Engine が　commit　した SKU には、デフォルトで無制限の割り当てがあります。

コミットメントと commit された SKU の割り当ての詳細については、コミットメントと commit 済みリソースの割り当てをご覧ください。

根本原因

割り当ての上限があるときに、items[].quotas[].limit フィールドまたは quotas[].limit フィールドを int タイプとして定義している場合、割り当て上限の API レスポンスデータが int タイプの範囲内に収まり、自動化プロセスは中断されない可能性があります。ただし、デフォルトの割り当て上限が無制限の場合、Compute Engine API は、int タイプで定義された範囲外にある limit フィールドの値を返します。自動プロセスは API メソッドから返された値を使用できず、結果として失敗します。

この問題を回避する方法

次の方法でこの問題を回避し、自動レポートの生成を続行できます。

推奨: Compute Engine API リファレンスドキュメントに従い、API メソッドの定義に正しいデータ型を使用します。具体的には、number タイプを使用して、API メソッドの items[].quotas[].limit フィールドと quotas[].limit フィールドを定義します。
割り当て上限を 9,223,372,036,854,775,807 未満の値に減らします。すべてのリージョンで、リソースベースのコミットメントがあるプロジェクトすべてに、割り当て上限を設定する必要があります。これは、次のいずれかの方法で行います。
- 割り当ての増加リクエストと同じ手順で行います。割り当て上限の引き下げについてもリクエストします。
- コンシューマ割り当てのオーバーライドを設定します。

Linux VM インスタンスの既知の問題

Linux VM の既知の問題を次に示します。

RHEL 7 VM と CentOS VM が再起動後にネットワークアクセスを失う

Google が提供する CentOS と Red Hat Enterprise Linux（RHEL）7 の OS イメージでは、予測可能なネットワークインターフェース名がデフォルトで無効になっています。

ただし、CentOS VM または RHEL 7 VM に複数のネットワークインターフェースカード（NIC）があり、これらの NIC の 1 つが VirtIO インターフェースを使用しない場合、再起動時にネットワークアクセスが失われる可能性があります。これは、少なくとも 1 つの NIC が VirtIO インターフェースを使用しない場合、予測可能なネットワークインターフェース名の無効化を RHEL がサポートしていないためです。

解決策

問題が解決するまで、VM を停止して起動することで、ネットワーク接続を回復できます。ネットワーク接続の喪失を回避するには、次の手順を行います。1. /etc/default/grub ファイルを編集して、カーネルパラメータ net.ifnames=0 と biosdevname=0 を削除します。2. GRUB 構成を再生成します。3. VM を再起動します。

SUSE Linux を実行している C3 VM と C3D VM でローカル SSD デバイスのシンボリックリンクがない

一般公開の Google Cloud SUSE イメージには、C3 および C3D ローカル SSD デバイスのシンボリックリンクを作成するために必要な udev 構成が含まれていません。

解決策

SUSE の udev ルールとカスタムイメージを追加するには、シンボリックリンクがローカル SSD を持つ C3 とC3D で作成されないをご覧ください。

repomd.xml の署名を確認できない

Red Hat Enterprise Linux（RHEL）または CentOS 7 ベースのシステムで、yum を使用してソフトウェアをインストールまたは更新しようとすると、次のエラーが発生することがあります。このエラーは、リポジトリの GPG 鍵が期限切れになっているか、正しくないことを示しています。

サンプルログ:

[root@centos7 ~]# yum update


...

google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.

...

failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk

解決策

この問題を解決するには、yum リポジトリの構成で repo_gpgcheck=0 を設定し、リポジトリ GPG 鍵チェックを無効にします。サポートされている Compute Engine ベースイメージの場合、この設定が /etc/yum.repos.d/google-cloud.repo ファイルにある場合があります。ただし、別のリポジトリ構成ファイルや自動化ツールであれば、この設定を使用できます。

通常、yum リポジトリではリポジトリ検証に GPG 鍵は使用されません。代わりに、https エンドポイントが信頼されています。

この設定を見つけて更新するには、次の手順を行います。

/etc/yum.repos.d/google-cloud.repo ファイルで設定を探します。

cat /etc/yum.repos.d/google-cloud.repo


[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

repo_gpgcheck=1 と記述されている行をすべて repo_gpgcheck=0 に変更します。
```
sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo
```

設定が更新されたことを確認します。

cat /etc/yum.repos.d/google-cloud.repo

[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

OS ログインを使用するインスタンスが接続後にログインメッセージを返す

OS ログインを使用する一部のインスタンスで、接続確立後に次のエラーメッセージが返されることがあります。

/usr/bin/id: cannot find name for group ID 123456789

解決策

このエラーメッセージは無視してください。

Windows VM インスタンスの既知の問題

Windows 11 バージョン 22H2 を実行しているインスタンスが起動に失敗する。この問題が解決するまで、Windows 11 バージョン 21H2 を使用してください。
コミュニティ NVMe ドライバを使用した Windows での NVMe のサポートはベータ版であり、そのパフォーマンスは Linux インスタンスのパフォーマンスと一致しない場合があります。コミュニティ NVMe ドライバは、Google Cloud の公開イメージで Microsoft StorNVMe ドライバに置き換えられました。2022 年 5 月より前に作成された VM の NVMe ドライバを置き換え、代わりに Microsoft StorNVMe ドライバを使用することをおすすめします。
インスタンスの作成後すぐに接続することはできません。すべての新しい Windows インスタンスがシステム準備（sysprep）ツールを使用してインスタンスを設定します。これには完了までに 5～10 分かかります。
Windows Server イメージは kms.windows.googlecloud.com へのネットワーク接続がなければアクティブ化できません。また、30 日以内に初回の認証が行われなければ機能が停止します。KMS によってアクティブ化されたソフトウェアは 180 日ごとに再アクティブ化する必要がありますが、KMS は 7 日ごとに再アクティブ化を試みます。Windows インスタンスを構成して、アクティブ化が維持されるようにしてください。
エミュレートされていないモデル固有レジスタにアクセスするカーネルソフトウェアは、一般保護違反を引き起こし、ゲストオペレーティングシステムによってはシステム障害が発生する可能性があります。

Windows VM で w32tm を使用して NTP の時刻のずれを測定する際のエラー

VirtIO NIC を実行している Compute Engine 上の Windows VM で、次のコマンドを使用して NTP のずれを測定するとエラーが発生するという既知のバグがあります。

w32tm /stripchart /computer:metadata.google.internal

エラーは次のように表示されます。

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

このバグは、VirtIO NIC を使用する Compute Engine VM にのみ影響します。gVNIC を使用する VM では、この問題は発生しません。

この問題を回避するには、Meinberg Time Server Monitor などの他の NTP ずれ測定ツールを使用することをおすすめします。

Windows VM を第 3 世代のマシンシリーズに移行すると起動の問題が発生する

第 1 世代または第 2 世代のマシンシリーズ（N1 または N2 など）から Windows VM を第 3 世代のマシンシリーズ（C3 や H3 など）に移行する場合、VM を再起動すると起動に失敗します。

この問題を回避するには、次のようにします。

gcloud compute disks describe コマンドを実行して、アップグレードする VM のブートディスクが第 3 世代のマシンタイプと互換性があることを確認します。
```
gcloud compute disks describe DISK_NAME --zone=ZONE
```
次のように置き換えます。
- DISK_NAME: ブートディスクの名前
- ZONE: ディスクのゾーン
第 3 世代のマシンシリーズでブートディスクを使用するには、出力に以下が含まれている必要があります。
```
guestOsFeatures:
...
- type: GVNIC
- type: WINDOWS
```
アップグレードする VM を停止します。
VM のブートディスクを切断します。
Google Cloud コンソールを使用して、次のプロパティを持つ Windows VM を作成します。
- ゾーン: 元の VM と同じゾーン
- ブートディスク: 元の VM のブートディスク
- マシンシリーズ: 第 3 世代のマシンシリーズ

gVNIC 使用時のネットワークスループットが低下する

gVNIC ドライバの GooGet パッケージバージョン 1.0.0@44 以前を使用する Windows Server 2022 と Windows 11 の VM では、Google Virtual NIC（gVNIC）を使用している場合、ネットワークスループットが低下する可能性があります。

この問題を解決するには、gVNIC ドライバの GooGet パッケージをバージョン 1.0.0@45 以降に更新します。その手順は次のとおりです。

管理者のコマンドプロンプトまたは Powershell セッションから次のコマンドを実行して、VM にインストールされているドライバのバージョンを確認します。
```
googet installed
```
出力は次のようになります。
```
Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...
```
google-compute-engine-driver-gvnic.x86_64 ドライバのバージョンが 1.0.0@44 以前の場合は、管理者のコマンドプロンプトまたは Powershell セッションから次のコマンドを実行して、GooGet パッケージリポジトリを更新します。
```
googet update
```

C3 VM および C3D VM を使用する Microsoft Windows の gVNIC で帯域幅が制限される

Windows オペレーティングシステムでは、gVNIC ドライバは記載された帯域幅の上限に達しません。gVNIC ドライバは、Microsoft Windows を実行している C3 VM と C3D VM で、デフォルトネットワークと VM ごとの Tier_1 のネットワークパフォーマンスの両方について、最大 85 Gbps のネットワーク帯域幅を達成できます。

2022 年 5 月より前に作成された VM の NVME ドライバを置き換える

Microsoft Windows を使用する VM で NVMe を使用し、2022 年 5 月 1 日より前に VM を作成した場合は、ゲスト OS の既存の NVMe ドライバを更新して、Microsoft StorNVMe ドライバを使用します。

マシンタイプを第 3 世代のマシンシリーズに変更する前、または第 3 世代のマシンを使用する新しい VM の作成に使用するブートディスクスナップショットを作成する前に、VM の NVMe ドライバを更新する必要があります。

StorNVME ドライバパッケージをインストールして、コミュニティドライバを削除する（ゲスト OS に存在する場合）ためには、次のコマンドを使用します。

googet update
googet install google-compute-engine-driver-nvme

C3 VM と C3D VM を使用する Microsoft Windows 上のローカル SSD のパフォーマンスが低下する

Microsoft Windows を実行している C3 VM と C3D VM では、ローカル SSD のパフォーマンスは限定されています。

現在、パフォーマンスの改善を進めています。

C3 VM と M3 VM を使用する Microsoft Windows 上の Hyperdisk Extreme の IOPS パフォーマンスが低下する

Microsoft Windows VM では、Hyperdisk Extreme のパフォーマンスは限定されています。

現在、パフォーマンスの改善を進めています。

C3D 180 および 360 vCPU マシンタイプが、Windows OS イメージをサポートしていない

C3D 180 vCPU マシンタイプは、Windows Server 2012 と 2016 OS イメージをサポートしていません。 180 個の vCPU と Windows Server 2012 および 2016 OS イメージで作成された C3D VM は起動に失敗します。この問題を回避するには、より小さいマシンタイプを選択するか、別の OS イメージを使用します。

360 vCPU と Windows OS イメージで作成された C3D VM は起動できません。この問題を回避するには、より小さいマシンタイプを選択するか、別の OS イメージを使用してください。

M3、C3、C3D VM に対する Windows Server 2016 および 2012 R2 の汎用ディスクエラー

実行中の M3、C3、C3D VM 用の Hyperdisk または Persistent Disk の追加やサイズ変更は、現時点では特定の Windows ゲストで想定どおりに機能しません。Windows Server 2012 R2 と Windows Server 2016、および対応するサーバー以外の Windows バリアントは、ディスク接続コマンドとディスクサイズ変更コマンドに正しく応答しません。

たとえば、実行中の M3 VM からディスクを削除すると、Windows オペレーティングシステムがディスクの削除を認識せずに、ディスクが Windows Server インスタンスから切断されます。それ以降のディスクへの書き込みでは、一般的なエラーが返されます。

解決策

ディスクの変更をこれらのゲストが認識できるようにするには、Hyperdisk または Persistent Disk を変更した後、Windows 上で実行されている M3、C3、または C3D VM を再起動させる必要があります。

既知の問題

Z3 VM の作成時に料金の見積もりを利用できない

一般的な問題

A2、C3、または G2 マシンタイプを指定するインスタンス テンプレートを使用して予約または将来の予約リクエストを作成すると、問題が発生する

Google Kubernetes Engine で c3-standard-*-lssd マシンタイプと c3d-standard-*-lssd マシンタイプを使用する場合の制限事項

C3D VM で単一フロー TCP スループットのばらつきがある

T2D マシンシリーズを持つマネージド インスタンス グループで期待どおりに自動スケーリングしない

コアごとに 1 つのスレッドを使用する VM で、CPU 使用率のオブザーバビリティ指標が正しくない

カスタム ファイアウォール ルールを使用すると、Google Cloud コンソールのブラウザでの SSH 接続が失敗することがある

特定の予約のサイズを縮小または削除すると、VM が他の予約を消費しなくなる

moveInstance API または gcloud CLI を使用して VM またはディスクを移行すると、予期しない動作が発生する

n2d-standard-64 マシンタイプを使用する VM にアタッチされたディスクが、パフォーマンスの上限に一貫して到達しない

ディスクの一時的な名前

ディスクのサイズ変更によって一部の永続ディスクのレイテンシが増加

ローカル SSD で C3 VM を含む MBR イメージを使用する

サポートされていない PD-Standard ディスクと PD-Extreme ディスクを C3 VM と M3 VM にアタッチできる

リソースベースのコミットメント割り当てに関する API レスポンス データを使用している場合、自動プロセスが失敗することがある

根本原因

この問題を回避する方法

Linux VM インスタンスの既知の問題

RHEL 7 VM と CentOS VM が再起動後にネットワーク アクセスを失う

SUSE Linux を実行している C3 VM と C3D VM でローカル SSD デバイスのシンボリック リンクがない

repomd.xml の署名を確認できない

OS ログインを使用するインスタンスが接続後にログイン メッセージを返す

Windows VM インスタンスの既知の問題

Windows VM で w32tm を使用して NTP の時刻のずれを測定する際のエラー

Windows VM を第 3 世代のマシンシリーズに移行すると起動の問題が発生する

gVNIC 使用時のネットワーク スループットが低下する

C3 VM および C3D VM を使用する Microsoft Windows の gVNIC で帯域幅が制限される

2022 年 5 月より前に作成された VM の NVME ドライバを置き換える

C3 VM と C3D VM を使用する Microsoft Windows 上のローカル SSD のパフォーマンスが低下する

C3 VM と M3 VM を使用する Microsoft Windows 上の Hyperdisk Extreme の IOPS パフォーマンスが低下する

C3D 180 および 360 vCPU マシンタイプが、Windows OS イメージをサポートしていない

M3、C3、C3D VM に対する Windows Server 2016 および 2012 R2 の汎用ディスクエラー

A2、C3、または G2 マシンタイプを指定するインスタンステンプレートを使用して予約または将来の予約リクエストを作成すると、問題が発生する

Google Kubernetes Engine で `c3-standard--lssd` マシンタイプと `c3d-standard--lssd` マシンタイプを使用する場合の制限事項

T2D マシンシリーズを持つマネージドインスタンスグループで期待どおりに自動スケーリングしない

カスタムファイアウォールルールを使用すると、Google Cloud コンソールのブラウザでの SSH 接続が失敗することがある

`moveInstance` API または gcloud CLI を使用して VM またはディスクを移行すると、予期しない動作が発生する

`n2d-standard-64` マシンタイプを使用する VM にアタッチされたディスクが、パフォーマンスの上限に一貫して到達しない

リソースベースのコミットメント割り当てに関する API レスポンスデータを使用している場合、自動プロセスが失敗することがある

RHEL 7 VM と CentOS VM が再起動後にネットワークアクセスを失う

SUSE Linux を実行している C3 VM と C3D VM でローカル SSD デバイスのシンボリックリンクがない

OS ログインを使用するインスタンスが接続後にログインメッセージを返す

gVNIC 使用時のネットワークスループットが低下する