このページでは、Compute Engine の使用中に発生する可能性のある既知の問題について説明します。Confidential VMs に特に影響する問題については、Confidential VMs の制限事項をご覧ください。
一般的な問題
以下の問題では、トラブルシューティングのガイダンスや一般情報が提供されます。
解決済み: gcloud compute disks update コマンドを使用して非同期レプリケーションのプライマリ ディスクの IOPS またはスループットを変更すると、誤ったエラーが発生する
以下の問題は 2025 年 6 月 1 日に解決されました。
gcloud compute disks update コマンドを使用して非同期レプリケーションのプライマリ ディスクの IOPS とスループットを変更すると、更新が成功しても、gcloud CLI にエラー メッセージが表示されます。
更新が正常に完了したことを正確に確認するには、gcloud CLI または Google Cloud コンソールを使用して、ディスクのプロパティに新しい IOPS 値とスループット値が表示されているかどうかを確認します。詳細については、Hyperdisk にプロビジョニングされたパフォーマンス設定を表示するをご覧ください。
メタデータ サーバーに古い physicalHost VM メタデータが表示される
インスタンスを新しいホストに移動するホストエラーが発生した後、メタデータ サーバーをクエリすると、インスタンスの以前のホストの physicalHost メタデータが表示されることがあります。
この問題を回避するには、次のいずれかを行います。
instances.getメソッドまたはgcloud compute instances describeコマンドを使用して、正しいphysicalHost情報を取得します。- インスタンスを停止してから起動します。このプロセスにより、メタデータ サーバーの
physicalHost情報が更新されます。 - 影響を受けるインスタンスの
physicalHost情報が更新されるまで 24 時間待ちます。
マネージド インスタンス グループ（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 で -lssd マシンタイプを使用する場合の制限事項
Google Kubernetes Engine API を使用する場合、プロビジョニングするローカル SSD がアタッチされたノードプールは、選択した C4、C3 および C3D マシンタイプと同じ数の SSD ディスクを持つ必要があります。たとえば、c3-standard-8-lssd を使用する VM を作成する場合は、SSD ディスクが 2 つ必要ですが、c3d-standard-8-lssd に必要な SSD ディスクは 1 つだけです。ディスクの数が一致しない場合は、Compute Engine コントロール プレーンでローカル SSD の構成ミスエラーが発生します。lssd マシンタイプに基づいて適切な数のローカル SSD ディスクを選択するには、ローカル SSD ディスクを自動的にアタッチするマシンタイプをご覧ください。
Google Kubernetes Engine Google Cloud コンソールで c4-standard-*-lssd VM、c4-highmem-*-lssd VM、c3-standard-*-lssd VM、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 に接続します。
ディスクの一時的な名前
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 未満の値に減らします。 すべてのリージョンで、リソースベースのコミットメントがあるプロジェクトすべてに、割り当て上限を設定する必要があります。これは、次のいずれかの方法で行います。
- 割り当て調整をリクエストする場合と同じ手順で、割り当て上限の引き下げをリクエストします。
- 割り当てオーバーライドを作成します。
ベアメタル インスタンスの既知の問題
Compute Engine ベアメタル インスタンスの既知の問題を次に示します。
C4D ベアメタルが SUSE Linux 15 SP6 イメージをサポートしていない
C4D ベアメタル インスタンスでは、SUSE Linux Enterprise Server（SLES）バージョン 15 SP6 OS を実行できません。
回避策
代わりに SLES 15 SP5 を使用してください。
ホスト メンテナンスのシミュレーションは C4 ベアメタル インスタンスでは機能しない
c4-standard-288-metal マシンタイプと c4-highmem-288-metal マシンタイプは、ホスト メンテナンス イベントのシミュレーションをサポートしていません。
回避策
他の C4 マシンタイプを使用して作成された VM インスタンスを使用して、メンテナンス イベントをシミュレートできます。
-metalで終わらない C4 マシンタイプを使用して VM インスタンスを作成します。VM インスタンスを作成するときに、ホスト メンテナンス イベント中にライブ マイグレーションを使用するのではなく、C4 VM を
Terminateに構成します。この VM のホスト メンテナンス イベントをシミュレートします。
シミュレートされたホスト メンテナンス イベント中、終了するように構成された VM の動作は、C4 ベアメタル インスタンスの動作と同じです。
RHEL 8 の Z3 ベアメタル インスタンスでパフォーマンスが想定よりも低い
Z3 ベアメタル インスタンスで Red Hat Enterprise Linux（RHEL）バージョン 8 を使用すると、ネットワーク パフォーマンスが想定よりも低くなります。
根本的な原因
RHEL 8 で使用されている Linux カーネル バージョン（4.18）に、Page Pool 機能がありません。
回避策
Z3 ベアメタル インスタンスを使用する場合は、RHEL の新しいバージョンまたは別のオペレーティング システムを使用します。
Dynamic Network Interface の使用に関する問題
このセクションでは、複数のネットワーク インターフェースと Dynamic Network Interface の使用に関連する既知の問題について説明します。
カスタム MTU サイズでのパケットロス
親 vNIC を使用する Dynamic NIC では、カスタム MTU サイズでパケット損失が発生することがあります。
回避策
パケットロスを回避するには、次のいずれかの MTU サイズを使用します。
- 1,460 バイト（VPC ネットワークのデフォルト値）
- 1,500 バイト（標準イーサネット）
- 8,896 バイト（可能な最大値）
Dynamic NIC で VLAN ID を再利用する際のファイアウォールの相互作用
インスタンスで新しい Dynamic NIC に VLAN ID を再利用すると、ファイアウォール接続のトラッキングに影響します。Dynamic NIC を削除し、同じ VLAN ID を使用する置換用の Dynamic NIC を作成した場合、ファイアウォール接続トラッキング テーブルのエントリは自動的に消去されません。次の例は、関連するセキュリティ上の考慮事項を示しています。
- コンピューティング インスタンスには、VLAN ID
4の Dynamic NIC があり、network-1VPC ネットワークのサブネットに接続されています。 - インスタンスは、192.0.2.7:443 の宛先 IP アドレスと宛先ポートにパケットを送信します。適用可能な下り（外向き）ファイアウォール ルールでアウトバウンド接続が許可されています。
- Cloud NGFW ルールはステートフルであるため、許可されたアウトバウンド接続により、送信元 IP アドレスと送信元ポート（192.0.2.7:443）からのインバウンド パケットを許可するファイアウォール接続トラッキング テーブル エントリが作成されます。
- サンプルの Dynamic NIC を削除し、代替の Dynamic NIC を作成します。置換用の Dynamic NIC も VLAN ID
4を使用しますが、別の VPC ネットワークnetwork-2のサブネットに接続します。 - 元の Dynamic NIC に適用され、期限切れでないファイアウォール接続トラッキング テーブルのエントリはすべて、置換用の Dynamic NIC に適用されます。つまり、
network-2VPC ネットワーク内のリソースは、送信元が 192.0.2.7:443 と一致するパケットを送信できます。コンピューティング インスタンスは、上り（内向き）ファイアウォール ルールを評価することなく、これらのパケットを受け入れます。
接続トラッキングとファイアウォール ルールの詳細については、Cloud Next Generation Firewall のドキュメントの仕様をご覧ください。
解決策
インスタンスごとに、インスタンスから削除された Dynamic NIC と同じ VLAN ID を使用する Dynamic NIC を作成する必要がある場合:
- 元の Dynamic NIC を削除してから置換用の Dynamic NIC を作成するまで、少なくとも 10 分待ちます。
- インスタンスを停止し、元の Dynamic NIC を削除して、置換用の Dynamic NIC を作成してから、インスタンスを起動します。
パケットのインターセプトにより、イーサネット ヘッダーに VLAN タグがないため、パケットがドロップされる可能性がある
Dynamic NIC を使用している場合、パケットのインターセプトによりパケットがドロップされることがあります。パイプラインが途中で終了すると、パケットがドロップされることがあります。この問題は、セッション ベースとセッション ベース以外の両方のモードに影響します。
根本的な原因
パケットのドロップは、パイプラインが早期に終了したときにパケットのインターセプトで発生します（上り（内向き）のインターセプトと下り（外向き）の再挿入）。早期終了により、上り（内向き）パケットのイーサネット ヘッダーに VLAN ID が含まれなくなります。下り（外向き）パケットは、変更された上り（内向き）パケットから派生するため、下り（外向き）パケットにも VLAN ID がありません。これにより、間違ったエンドポイント インデックスが選択され、パケットがドロップされます。
回避策
ファイアウォール エンドポイントなど、パケット インターセプトに依存する Google Cloud 機能を使用しないでください。
Linux VM インスタンスの既知の問題
Linux VM の既知の問題を次に示します。
OS イメージ バージョンが v20250728 より前の Debian 11 VM で apt update が実行されない
2025 年 7 月 22 日に、Debian コミュニティはメインの Debian アップストリームから Debian 11（Bullseye）バックポートを削除しました。このアップデートにより、sudo apt update が次のエラーで失敗します。
The repository 'https://deb.debian.org/debian bullseye-backports Release' does
not have a Release file.
根本的な原因
Debian コミュニティがバックポート リポジトリをメイン アップストリームから削除したため、bullseye-backports Release への参照はなくなりました。
解決策
イメージ バージョン debian-11-bullseye-v20250728 以降を使用します。これらのバージョンには、バックポート リポジトリが含まれていません。または、/etc/apt/sources.list を変更して現在のインスタンスを更新することもできます。
リポジトリ URL を更新して
bullseye-backportsのアーカイブを使用するには:sudo sed -i 's/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/deb https:\/\/archive.debian.org\/debian bullseye-backports main/g; s/^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/deb-src https:\/\/archive.debian.org\/debian bullseye-backports main/g' /etc/apt/sources.listリポジトリ URL を削除して
bullseye-backportsを破棄するには:sudo sed -i '/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/d; /^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/d' /etc/apt/sources.list
ubuntu-desktop パッケージをインストールすると、再起動時に VM ネットワークが切断される
Ubuntu VM に ubuntu-desktop パッケージをインストールした後、VM を再起動する前に次の回避策を実行する必要があります。
echo -e 'network:\n version: 2\n renderer: networkd' | sudo tee /etc/netplan/99-gce-renderer.yaml
そうしないと、再起動時にネットワーク インターフェースが正しく構成されない可能性があります。
根本的な原因
ubuntu-deskop パッケージは ubuntu-settings を依存関係としてプルします。これにより、NetworkManager が netplan のデフォルトの「レンダラ」として設定されます。具体的には、/usr/lib/netplan/00-network-manager-all.yaml に netplan の新しい YAML 構成を挿入します。この構成には次のものが含まれます。
network:
version: 2
renderer: NetworkManager
この構成は、cloud-init を使用した networkd ベースの早期プロビジョニングと競合します。
再設定
VM が再起動されてアクセスできない場合は、次の操作を行います。
- VM を復元する手順に沿って操作します。
アクセスできない VM の Linux ファイル システム パーティションをマウントしたら、次のコマンドを実行します（
/rescueはマウント ポイントに置き換えます）。echo -e 'network:\n version: 2\n renderer: networkd' | sudo tee /rescue/etc/netplan/99-gce-renderer.yamlアクセスできない VM を再び起動する手順に進みます。
OS イメージ バージョン v20250530 を使用する Ubuntu VM で FQDN が正しく表示されない
次のいずれかを行うと、.local 接尾辞が追加された間違った完全修飾ドメイン名（FQDN）が表示されることがあります。
google-compute-engineパッケージのバージョン20250328.00に更新する。- バージョン接尾辞
v20250530を含む Canonical 提供の Ubuntu イメージからインスタンスを起動する。例:projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530
この問題が発生すると、次のような FQDN が表示されることがあります。
[root@ubuntu2204 ~]# apt list --installed | grep google
...
google-compute-engine/noble-updates,now 20250328.00-0ubuntu2~24.04.0 all [installed]
...
[root@ubuntu2204 ~]# curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"
projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530
[root@ubuntu2204 ~]# hostname -f
ubuntu2204.local
根本的な原因
新しい構成ファイル（https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf）の導入により、バージョン v20250530 のすべての Ubuntu イメージで、guest-config パッケージ バージョン 20250328.00 は検索パスに local を追加します。
[root@ubuntu2204 ~]# cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
...
nameserver 127.0.0.53
options edns0 trust-ad
search local ... google.internal
/etc/resolv.conf ファイルの検索パスに local エントリが存在すると、FQDN がリクエストされたときに .local 要素がホスト名に追加されます。
guest-configs のバージョン 20250501 ではすでに問題が修正されていますが、Canonical はまだこの修正をイメージに組み込んでいません。
回避策
Domains=localをDomains=~localに変更して、ネットワーク名解決構成ファイル/etc/systemd/resolved.conf.d/gce-resolved.confを変更します。systemctl restart systemd-resolvedコマンドを実行して、systemd-resolved サービスを再起動します。localが/etc/resolv.confの検索パスから削除されていることを確認します。hostname -fコマンドを使用して FQDN を確認します。[root@ubuntu2204 ~]# hostname -f ubuntu2204.us-central1-a.c.my-project.internal
openSUSE イメージに mkfs.ext4 がない
2025 年 8 月以降の openSUSE イメージの最新の v20250724 リリース（opensuse-leap-15-6-v20250724-x86-64 以降）には、ファイル システムを管理するためのユーティリティを提供する e2fsprogs パッケージが含まれていません。この問題の一般的な症状は、mkfs.ext4 コマンドを使用しようとすると、command not found などのエラー メッセージが表示されることです。
回避策
この問題が発生した場合は、openSUSE パッケージ マネージャー zypper を使用して、不足しているパッケージを手動でインストールします。
# Update the package index
user@opensuse:~> sudo zypper refresh
# Install the e2fsprogs package
user@opensuse:~> sudo zypper install e2fsprogs
# Verify the installation
user@opensuse:~> which mkfs.ext4
インスタンス タイプを変更した後に 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 を停止して起動することで、ネットワーク接続を回復できます。ネットワーク接続の喪失を回避するには、次の手順で操作します。
/etc/default/grubファイルを編集して、カーネル パラメータnet.ifnames=0とbiosdevname=0を削除します。grub 構成を再生成します。
VM を再起動します。
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 を再実行するために元のマシンタイプに戻します。正常に起動します。移行要件を確認して、要件を満たしていることを確認します。その後、手順を再試行します。
新しい VM マシンシリーズでアタッチされるディスク数が制限されている
NVMe ディスク インターフェースを使用して Microsoft Windows で実行される VM（T2A と第 3 世代のすべての VM を含む）では、アタッチされるディスク数は 16 個までです。この制限は第 4 世代の VM（C4、M4）には適用されません。エラーを回避するため、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 のパフォーマンスは限定されています。
現在、パフォーマンスの改善を進めています。
Microsoft Windows を実行する n2-standard-80 インスタンスにアタッチされた Hyperdisk Extreme ボリュームのパフォーマンスが低下する
n2-standard-80 マシンタイプで実行されている Microsoft Windows インスタンスは、インスタンスにアタッチされているすべての Hyperdisk Extreme ボリュームで最大 80,000 IOPS に達する可能性があります。
解決策
Windows を実行している N2 インスタンスで最大 160,000 IOPS を実現するには、次のいずれかのマシンタイプを選択します。
n2-highmem-80n2-highcpu-80n2-standard-96n2-highmem-96n2-highcpu-96n2-highmem-128n2-standard-128
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
大規模な C4、C4D、C3D vCPU マシンタイプが Windows OS イメージをサポートしていない
144 個を超える vCPU を備えた C4 マシンタイプと、180 個を超える vCPU を備えた C4D マシンタイプと C3D マシンタイプは、Windows Server 2012 と 2016 の OS イメージをサポートしていません。Windows Server 2012 および 2016 OS イメージを使用する大規模な C4、C4D と C3D マシンタイプは起動に失敗します。この問題を回避するには、より小さいマシンタイプを選択するか、別の OS イメージを使用してください。
360 vCPU と Windows OS イメージで作成された C3D VM は起動できません。この問題を回避するには、より小さいマシンタイプを選択するか、別の OS イメージを使用してください。
255 個を超える vCPU と Windows 2025 で作成された C4D VM は起動に失敗します。この問題を回避するには、より小さいマシンタイプを選択するか、別の OS イメージを使用してください。
M3、C3、C3D、C4D VM に対する Windows Server 2016 および 2012 R2 の汎用ディスクエラー
実行中の M3、C3、C3D、C4D 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、または C4D VM を再起動させる必要があります。