既知の問題

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

一般的な問題

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

C4A の確約利用割引（CUD）を作成できない

Google Cloud コンソール、gcloud CLI、または REST を使用して C4A インスタンスの CUD を作成することはできません。

C4A の CUD は、一部の地域ではご利用いただけません。サポートはすべての地域に段階的に追加されています。

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-*-lssdVM を含むクラスタまたはノードプールを作成すると、ノードの作成に失敗するか、ローカル 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 アクセスを制御すると、bラウザのSSH 機能を使用できなくなる可能性があります。

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

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

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

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

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

  1. レスポンス データは、次のいずれかの Compute Engine API メソッドからのものです。

  2. API レスポンスの本文でリソース割り当て上限のフィールドを定義するには、number ではなく int を使用します。このフィールドは、各メソッドで次の方法でアクセスできます。

  3. 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 を使用してシステムにアクセスし、次のコマンドを使用して initramfs を再生成することを検討してください。

dracut -f --no-hostonly -v /boot/initramfs-$(uname -r).img $(uname -r)

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 を再起動します。

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

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

  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

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 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
  1. VM を停止します。
  2. VM を新しい VM マシンタイプに変更します。
  3. VM を起動します。

新しい VM が正しく起動しない場合は、VM を再実行するために元のマシンタイプに戻します。正常に起動します。移行要件を確認して要件を満たしていることを確認します。その後、手順を再試行します。

Windows VM の gVNIC で帯域幅が制限される

Compute Engine が提供する Windows イメージにパッケージ化された gVNIC ドライバは、Windows インスタンスで、標準のネットワーク パフォーマンスと VM ごとの Tier_1 ネットワーク パフォーマンスの両方について、最大 50 Gbps のネットワーク帯域幅を実現できます。更新されたバージョンの gVNIC ドライバは、ラインレートのパフォーマンス（最大 200 Gbps）を提供し、ジャンボ フレームをサポートできます。

更新されたドライバは、第 3 世代以降のマシンシリーズ（N4 を除く）でのみ使用できます。詳細については、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 以降に更新します。その手順は以下のとおりです。

  1. 管理者のコマンド プロンプトまたは Powershell セッションから次のコマンドを実行して、VM にインストールされているドライバのバージョンを確認します。

    googet installed

    出力は次のようになります。

    Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...

  2. 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 を再起動させる必要があります。