既知の問題

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

一般的な問題

カスタム ファイアウォール ルールを使用すると、Cloud Console のブラウザ内の SSH 接続が失敗することがあります

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

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

解決済み: 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 を削除します。

  • 問題を解決するには:

    1. 削除した特定の予約と同じ名前とプロパティで新しい特定の予約を再作成します。

    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 パフォーマンスが低下することがあります。この問題の影響を受けると、サイズ変更オペレーションの実行中に永続ディスクでレイテンシが増加する可能性があります。この問題は、すべての種類の永続ディスクに影響する可能性があります。

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 エンドポイントが信頼されています。

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

  1. /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

  2. repo_gpgcheck=1 と記述されている行をすべて repo_gpgcheck=0 に変更します。

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

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

    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 ツールの最新のアップデートを取得できなくなります。

このエラーを解決するには、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 インスタンスを構成して、有効な状態に保持してください。
  • エミュレートされていないモデル固有レジスタにアクセスするカーネル ソフトウェアは、一般保護違反を引き起こし、ゲスト オペレーティング システムによってはシステム障害の原因となります。