このページでは、Compute Engine の使用中に発生する可能性のある既知の問題について説明します。Confidential VMs に特に影響する問題については、Confidential VMs の制限事項をご覧ください。
一般的な問題
以下の問題では、トラブルシューティングのガイダンスや一般情報が提供されます。
メタデータ サーバーに古い physicalHost VM メタデータが表示される
インスタンスを新しいホストに移動するホストエラーが発生した後、メタデータ サーバーをクエリすると、インスタンスの以前のホストの physicalHost メタデータが表示されることがあります。
この問題を回避するには、次のいずれかを行います。
instances.getメソッドまたはgcloud compute instances describeコマンドを使用して、正しいphysicalHost情報を取得します。- インスタンスを停止してから起動します。このプロセスにより、メタデータ サーバーの
physicalHost情報が更新されます。 - 影響を受けるインスタンスの
physicalHost情報が更新されるまで 24 時間待ちます。
ライブ マイグレーション中に IPv6 専用の C3 VM に到達できない
C3 マシンタイプを使用する IPv6 専用 VM は、ライブ マイグレーション中に到達不能になる可能性があります。
回避策:
この問題が発生する可能性を低減するには、インスタンスのメンテナンス ポリシーを更新し、メンテナンス動作を TERMINATE に、自動再起動を TRUE に設定します。
VM でライブ マイグレーションが行われているときにこの問題が発生した場合は、VM を再起動してインスタンスへのアクセスを再開します。
マネージド インスタンス グループ（MIG）の baseInstanceName 値が長いと、ディスク名の競合が発生する可能性がある
MIG では、インスタンス テンプレートで VM の作成時に作成されるディスクが指定され、baseInstanceName の値が 54 文字を超えると、ディスク名の競合が発生する可能性があります。これは、Compute Engine がインスタンス名を接頭辞として使用してディスク名を生成するためです。
ディスク名の生成時に、生成された名前がリソース名の上限である 63 文字を超えると、Compute Engine はインスタンス名の末尾から余分な文字を切り捨てます。この切り捨てにより、命名パターンが類似するインスタンスに同じディスク名が作成される可能性があります。この場合、新しいインスタンスは既存のディスクのアタッチを試みます。ディスクがすでに別のインスタンスに接続されている場合、新しいインスタンスの作成は失敗します。ディスクがアタッチされていない場合やマルチライター モードの場合、新しいインスタンスがディスクをアタッチし、データの破損につながる可能性があります。
ディスク名の競合を回避するため、baseInstanceName 値の最大長は 54 文字にしてください。
A2、C3、または G2 マシンタイプを指定するインスタンス テンプレートを使用して予約または将来の予約リクエストを作成すると、問題が発生する
A2、C3、または G2 マシンタイプを指定するインスタンス テンプレートを使用して予約を作成する場合や、審査のために将来の予約リクエストを作成して送信する場合、問題が発生します。具体的には次のとおりです。
予約の作成が失敗する可能性があります。成功した場合は、次のいずれかが該当します。
自動的に消費される予約（デフォルト）を作成した場合、一致するプロパティを持つ VM を作成しても、予約は消費されません。
特定の予約を作成した場合、その予約を特定して対象とする VM の作成は失敗します。
将来の予約リクエストの作成は成功します。ただし、審査のために提出すると、 Google Cloud はリクエストを拒否します。
予約の作成または将来の予約リクエストの作成に使用されるインスタンス テンプレートを置き換えることや、テンプレートの VM プロパティをオーバーライドすることはできません。A2、C3、または G2 マシンタイプのリソースを予約する場合は、代わりに次のいずれかを行います。
次の手順に沿って、新しい将来の予約リクエストを作成します。
既存の将来の予約リクエストによって、現在のプロジェクトで作成する（または将来の予約リクエストが共有されるプロジェクトで作成する）見込みがある将来の予約リクエストのプロパティが制限されないようにするには、将来の予約リクエストを削除します。
プロパティを直接指定して単一プロジェクトまたは共有の将来の予約リクエストを作成し、審査のために送信します。
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 フローを使用します。
コアごとに 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 に接続します。
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 パフォーマンスが低下することがあります。この問題の影響を受けると、サイズ変更オペレーションの実行中に永続ディスクでレイテンシが増加する可能性があります。この問題は、すべての種類の永続ディスクに影響する可能性があります。
リソースベースのコミットメント割り当てに関する 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 の既知の問題を次に示します。
インスタンス タイプを変更した後に SUSE Enterprise VM が起動しない
SUSE Linux Enterprise VM のインスタンス タイプを変更した後、起動に失敗し、シリアル コンソールに次のエラーが繰り返し表示されることがあります。
Starting [0;1;39mdracut initqueue hook[0m...
[ 136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
[ 136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
[ 136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
[ 136.220738] dracut-initqueue[377]: [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
[ 136.240713] dracut-initqueue[377]: fi"
根本原因
SUSE は、さまざまなインスタンス タイプをサポートする汎用的な initramfs（初期 RAM ファイルシステム）を使用してクラウド イメージを作成します。これは、初期イメージの作成時に --no-hostonly --no-hostonly-cmdline -o multipath フラグを使用することによって実現されます。ただし、新しいカーネルがインストールされた場合や initramfs が再生成された場合（システム アップデート中に発生します）、これらのフラグはデフォルトで省略されます。これにより、現在のシステムのハードウェアに合わせて小さめの initramfs が作成され、他のインスタンス タイプに必要なドライバが除外される可能性があります。
たとえば、C3 インスタンスは NVMe ドライブを使用します。この場合、initramfs に特定のモジュールを含める必要があります。これらの NVMe モジュールがない initramfs のシステムが C3 インスタンスに移行されると、起動プロセスが失敗します。この問題は、独自のハードウェア要件を持つ他のインスタンス タイプにも影響する可能性があります。
回避策
マシンタイプを変更する前に、すべてのドライバが含まれた initramfs を再生成します。
dracut --force --no-hostonly
システムがすでに問題の影響を受けている場合は、一時的なレスキュー VM を作成します。chroot コマンドを使用して影響を受ける VM のブートディスクにアクセスし、次のコマンドを使用して initramfs を再生成します。
dracut -f --no-hostonly
SUSE 12 イメージを使用する Z3 のローカル SSD の IOPS パフォーマンスが低下する
SUSE Linux Enterprise Server（SLES）12 イメージの Z3 VM では、ローカル SSD ディスクの IOPS のパフォーマンスが想定よりも大幅に低下します。
根本原因
これは SLES 12 コードベース内の問題です。
回避策
この問題を修正する SUSE のパッチは提供されていません。また、提供される予定もありません。代わりに、SLES 15 オペレーティング システムを使用する必要があります。
RHEL 7 VM と CentOS VM が再起動後にネットワーク アクセスを失う
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.gpgrepo_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 インスタンスの既知の問題
- コミュニティ 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 Server 2025 と Windows 11 24h2 - 一時停止と再開のサポート
Windows Server 2025 と Windows 11 24h2 は、一時停止したときに再開できません。この問題が解決するまで、Windows Server 2025 と Windows 11 24h2 では、一時停止と再開機能はサポートされません。
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 ずれ測定ツールを使用することをおすすめします。
VM を第 1 世代または第 2 世代から第 3 世代以降の VM に更新した後に起動デバイスにアクセスできない
Windows Server は、初回起動時にブートドライブを初期ディスク インターフェース タイプにバインドします。既存の VM を、SCSI ディスク インターフェースを使用する古いマシンシリーズから NVMe ディスク インターフェースを使用する新しいマシンシリーズに変更するには、VM をシャットダウンする前に Windows PnP ドライバの sysprep を実行します。この sysprep は、デバイス ドライバを準備するだけで、次回の起動時にすべてのディスク インターフェース タイプがブートドライブ用にスキャンされるようにします。
VM のマシンシリーズを更新するには、次の操作を行います。
PowerShell プロンプトから Administrator として、次のように実行します。
PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
- VM を停止します。
- VM を新しい VM マシンタイプに変更します。
- VM を起動します。
新しい VM が正しく起動しない場合は、VM を再実行するために元のマシンタイプに戻します。正常に起動します。移行要件を確認して要件を満たしていることを確認します。その後、手順を再試行します。
Windows VM の gVNIC で帯域幅が制限される
Compute Engine が提供する Windows イメージにパッケージ化された gVNIC ドライバは、Windows インスタンスで、標準のネットワーク パフォーマンスと VM ごとの Tier_1 ネットワーキング パフォーマンスの両方について、最大 50 Gbps のネットワーク帯域幅を実現できます。更新されたバージョンの gVNIC ドライバは、ラインレートのパフォーマンス（最大 200 Gbps）を実現でき、ジャンボ フレームもサポートできます。
更新されたドライバは、N4 を除く第 3 世代以降のマシンシリーズでのみ使用できます。詳細については、Windows OS で gVNIC のバージョンを更新するをご覧ください。
新しい VM マシンシリーズでアタッチされるディスク数が制限されている
NVMe ディスク インターフェースを使用して Microsoft Windows で実行される VM（T2A、第 3 世代以降のすべての VM、Confidential Computing を使用する VM を含む）では、アタッチされるディスク数は 16 個までです。エラーを回避するため、Persistent Disk と Hyperdisk のストレージを VM あたり最大 16 個のディスクに統合します。ローカル SSD ストレージは、この問題の対象外です。
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 のパフォーマンスは限定されています。
現在、パフォーマンスの改善を進めています。
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
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 を再起動させる必要があります。