このページでは、Compute Engine の使用中に発生する可能性のある既知の問題について説明します。
一般的な問題
カスタム ファイアウォール ルールを使用すると、Cloud Console のブラウザ内の SSH 接続が失敗することがあります
カスタム ファイアウォール ルールを使用して VM インスタンスへの SSH アクセスを制御すると、SSH ブラウザ内機能を使用できなくなる可能性があります。
この問題を回避するには、次のいずれかを行います。
有効化 TCP 用 Identity-Aware Proxy SSH ブラウザでの Cloud Console 機能を使用して VM への接続を続けます。
default-allow-ssh
ファイアウォール ルールを再作成し、ブラウザ内で SSH を使用して VM への接続を続行します。SSH ブラウザ内ではなく、Google Cloud CLI を使用して VM に接続します。
解決済み: Google Cloud Console に重複した Compute Engine API の割り当てが表示される
以下の問題は 2022 年 3 月 14 日に解決されました。
2022 年 2 月 3 日、Compute Engine では Compute Engine API のレート上限(API 割り当て)の更新を発表しました。これには、適用する 1 秒あたりの上限を 100 秒間隔から 1 分(60 秒)間隔に移行することが含まれます。この移行の一環として、Cloud Console の Compute Engine API 割り当てページには、新しい 1 分間の API 割り当てグループと、これまで使用されてきた 100 秒あたりの API 割り当てグループの両方が表示されます。1 分あたりの API 割り当てグループは、100 秒あたりの API 割り当てグループの前に一覧表示されます。
1 分あたりの割り当てグループを使用して割り当ての使用状況をモニタリングし、新しい割り当てをリクエストします。100 秒あたりの割り当てグループを引き続き表示するのは、意図的かつ一時的なものです。100 秒ごとの割り当てグループを参照して、移行前の使用量を確認できます。
詳細は、API レート制限をご覧ください。
403 rateLimitExceeded
エラーが増える場合がある
2022 年 2 月 3 日、Compute Engine では Compute Engine API のレート上限の更新を発表しました。これには、適用する 1 秒あたりの上限を 100 秒間隔から 1 分(60 秒)間隔に移行することが含まれます。1 秒あたりのレート上限はわずかに増加しましたが、適用間隔が短くなるため、各更新間隔でバーストできる最大リクエスト数はわずかに少なくなります。しかし、この最大値はより短い間隔で更新されます。rateLimitExceeded
エラー メッセージを含む 403 エラーの発生が増加した場合は、リクエストを調整して、再試行の間隔を短くすることで新しい 1 分間の適用間隔に対応することをおすすめします。
詳細は、API レート制限をご覧ください。
特定の予約を削除すると、VM が他の予約を消費しなくなる
1 つ以上の VM が使用した特定の予約を削除すると、それらの VM は他の予約を消費できません。
(オプション)この問題を回避するために、特定の予約を削除する前に、特定の予約を消費している VM を削除します。
問題を解決するには:
削除した特定の予約と同じ名前とプロパティで新しい特定の予約を再作成します。
影響を受ける 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 パフォーマンスが低下することがあります。この問題の影響を受けると、サイズ変更オペレーションの実行中に永続ディスクでレイテンシが増加する可能性があります。この問題は、すべての種類の永続ディスクに影響する可能性があります。
Linux VM インスタンスの既知の問題
reposmd.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
パッケージ更新時の GPG エラー: EXPKEYSIG 3746C208A7317B0F
Debian システムと Ubuntu システムで Google Cloud CLI を手動でインストールした場合(ローカル ワークステーションを含む)、次の例のようなエラーが発生する場合があります。
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease: The following signatures were invalid: EXPKEYSIG 3746C208A7317B0F Google Cloud Packages Automatic Signing Key <gc-team@google.com>
このエラーにより、次のようないくつかの Google Cloud ツールの最新のアップデートを取得できなくなります。
- Compute Engine ゲスト環境
- Google Cloud CLI と Google Cloud CLI
- Cloud Logging エージェント
このエラーを解決するには、https://packages.cloud.google.com
から最新の有効な apt-key.gpg
キーファイルを取得します。
Debian システム
次のコマンドを実行します。
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
Ubuntu システム
次のコマンドを実行します。
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
あるいは、Debian または Ubuntu イメージを実行している Compute Engine VM インスタンスで、次のイメージ バージョンを使用してインスタンスを再作成すると最新の鍵を取得できます。
- イメージ プロジェクト
debian-cloud
:debian-9-stretch-v20180401
またはイメージ ファミリーdebian-9
debian-8-jessie-v20180401
またはイメージ ファミリーdebian-8
- イメージ プロジェクト
ubuntu-os-cloud
:ubuntu-1710-artful-v20180315
またはイメージ ファミリーubuntu-1710
ubuntu-1604-xenial-v20180323
またはイメージ ファミリーubuntu-1604-lts
ubuntu-1404-trusty-v20180308
またはイメージ ファミリーubuntu-1404-lts
OS Login を使用するインスタンスが接続後にログイン メッセージを返す
OS ログインを使用する一部のインスタンスで、接続確立後に次のエラー メッセージが返されることがあります。
/usr/bin/id: cannot find name for group ID 123456789
このエラー メッセージは無視してください。
Windows VM インスタンスの既知の問題
- Windows インスタンスはローカル SSD で NVMe インターフェースを使用できますが、Windows 上での NVMe のサポートはベータ版であり、また Linux インスタンスと同じ性能を保証するものではありません。
- インスタンスの作成後すぐに接続することはできません。すべての新しい Windows インスタンスがシステム準備(sysprep)ツールを使用してインスタンスを設定します。これには完了までに 5~10 分かかります。
- Windows Server イメージは
kms.windows.googlecloud.com
へのネットワーク接続がなければアクティブ化できません。また、30 日以内に初回の認証が行われなければ機能が停止します。KMS によってアクティブ化されたソフトウェアは 180 日ごとに再アクティブ化する必要がありますが、KMS は 7 日ごとに再アクティブ化を試みます。必ず、Windows インスタンスを構成して、有効な状態に保持してください。 - エミュレートされていないモデル固有レジスタにアクセスするカーネル ソフトウェアは、一般保護違反を引き起こし、ゲスト オペレーティング システムによってはシステム障害の原因となります。