已知問題

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

本頁說明您在使用 Compute Engine 時可能會遇到的問題。如要瞭解會特別影響機密 VM 的問題，請參閱機密 VM 限制。

一般問題

以下問題提供疑難排解指南或一般資訊。

使用 gcloud compute disks update 指令修改非同步複製作業主要磁碟的 IOPS 或傳輸量會導致錯誤

使用 gcloud compute disks update 指令修改非同步複製主磁碟的 IOPS 和傳輸量時，即使更新成功，Google Cloud CLI 仍會顯示錯誤訊息。

如要準確確認更新是否成功，請使用 Google Cloud CLI 或 Google Cloud 控制台，查看磁碟屬性是否顯示新的 IOPS 和傳輸量值。詳情請參閱「查看 Hyperdisk 的已佈建效能設定」。

中繼資料伺服器可能會顯示舊版 physicalHost VM 中繼資料

發生主機錯誤 (將執行個體移至新主機) 後，當您查詢中繼資料伺服器時，可能會顯示執行個體先前主機的 physicalHost 中繼資料。

如要解決這個問題，請採取下列任一做法：

• 請使用 instances.get 方法或 gcloud compute instances describe 指令來擷取正確的 physicalHost 資訊。
• 停止再啟動執行個體。這項程序會更新中繼資料伺服器中的 physicalHost 資訊。
• 請等待 24 小時，讓受影響的執行個體的 physicalHost 資訊更新。

即時遷移期間無法存取僅限 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 機器類型保留資源，請改為執行下列任一操作：

• 直接指定屬性，建立新的單一專案或共用預留項目。

• 如要建立新的未來預留項目要求，請按照下列步驟操作：

  1. 如果您想停止讓現有未來預留項目要求限制未來預留項目要求的屬性，您可以在目前專案中建立未來預留項目要求，或是在未來預留項目要求共用專案中建立未來預留項目要求，然後刪除未來預留項目要求。

  2. 直接指定屬性，建立單一專案或共用未來預留項目要求，然後提交審查。

在 Google Kubernetes Engine 中使用 c3-standard-*-lssd 和 c3d-standard-*-lssd 機器類型的限制

使用 Google Kubernetes Engine API 時，您佈建的節點集區如果已連接本機 SSD，則必須與所選 C3 和 C3D 機器類型的 SSD 磁碟數量相同。舉例來說，如果您打算建立使用 c3-standard-8-lssd 的 VM，則必須有 2 個 SSD 磁碟，而如果是 c3d-standard-8-lssd，則只需要 1 個 SSD 磁碟。如果磁碟編號不相符，您會收到 Compute Engine 控制平面顯示的本機 SSD 設定錯誤。請參閱一般用途機器系列文件，根據 C3 或 C3D lssd 機器類型選取正確的本機 SSD 磁碟數量。

使用 Google Kubernetes Engine Google Cloud 控制台建立含有 c3-standard-*-lssd 和 c3d-standard-*-lssd VM 的叢集或節點集區，會導致節點建立失敗，或無法偵測本機 SSD 做為暫時性儲存空間。

C3D VM 上的單一流量 TCP 處理量變異

超過 30 個 vCPU 的 C3D VM 可能會出現單一流量 TCP 傳輸量變化，偶爾會限制為 20-25 Gbps。如要提高傳輸速率，請使用多個 TCP 流量。

如果 VM 每個核心使用一個執行緒，CPU 使用率觀察指標會顯示不正確

如果 VM 的 CPU 使用每個核心一個執行緒，則 Compute Engine >「VM 執行個體」>「可觀察性」分頁中的 CPU 使用率 Cloud Monitoring 可觀察性指標僅會縮放至 50%。除了 Tau T2D，所有機器類型的預設值都是每個核心有兩個執行緒。詳情請參閱「設定每個核心的執行緒數量」。

如要查看已歸一化為 100% 的 VM CPU 使用率，請改為在 Metrics Explorer 中查看 CPU 使用率。詳情請參閱「使用 Metrics Explorer 建立圖表」。

如果您使用自訂防火牆規則，Google Cloud 控制台的透過瀏覽器建立 SSH 連線功能可能會失敗

如果您使用自訂防火牆規則來控管 VM 執行個體的 SSH 存取權，可能無法使用瀏覽器中的 SSH 功能。

如要解決這個問題，請執行下列任一操作：

• 啟用 適用於 TCP 的 Identity-Aware Proxy，繼續使用瀏覽器中的 SSH Google Cloud 主控台功能連線至 VM。

• 重新建立 default-allow-ssh 防火牆規則，繼續使用瀏覽器中的 SSH 連線至 VM。

• 使用 Google Cloud CLI 連線至 VM，而非瀏覽器中的 SSH。

已解決使用 n2d-standard-64 機器類型的 VM 連接磁碟無法持續達到效能上限

下列問題已在 2023 年 10 月解決。

連接至 n2d-standard-64 機器類型 VM 的永久磁碟，未能持續達到 100,000 IOPS 的效能上限。讀取和寫入 IOPS 皆是如此。

磁碟的臨時名稱

在使用 gcloud compute instances update 指令或 instances.update API 方法啟動虛擬機器 (VM) 執行個體更新作業時，Compute Engine 可能會暫時變更 VM 磁碟的名稱，方法是將下列其中一個後置字串加入原始名稱：

• -temp
• -old
• -new

更新完成後，Compute Engine 會移除後置字串，並還原原始磁碟名稱。

磁碟大小調整導致部分永久磁碟的延遲時間增加

在某些情況下，調整大型永久磁碟 (約 3 TB 以上) 的大小，可能會影響磁碟的 I/O 效能。如果您受到這項問題的影響，永久磁碟在調整大小的過程中，可能會出現延遲時間增加的情形。這個問題可能會影響任何類型的 Persistent Disk。

如果自動化程序使用以資源為基礎的承諾配額相關的 API 回應資料，可能會失敗

以下情況可能會導致您用於使用 Compute Engine 資源型承諾配額 API 回應資料的自動化程序失敗：自動化程序可包含任何使用或儲存 API 回應的程式碼片段、商業邏輯或資料庫欄位。

1. 回應資料來自下列任何 Compute Engine API 方法：

   • compute.regions.list 方法
   • compute.regions.get 方法
   • compute.projects.get 方法

2. 您可以使用 int 而非 number，在 API 回應主體中定義資源配額限制的欄位。您可以透過下列方式，在每個方法中找到該欄位：

   • items[].quotas[].limit 為 compute.regions.list 方法。
   • quotas[].limit 為 compute.regions.get 方法。
   • quotas[].limit 為 compute.projects.get 方法。

3. 您可以為任何 Compute Engine 承諾 SKU 使用無上限的預設配額。

   如要進一步瞭解承諾和已承諾 SKU 的配額，請參閱「承諾和已承諾資源的配額」。

根本原因

如果配額有限，當您將 items[].quotas[].limit 或 quotas[].limit 欄位定義為 int 類型時，配額限制的 API 回應資料可能仍會落在 int 類型的範圍內，自動化程序可能不會中斷。不過，如果預設配額限制為無限制，Compute Engine API 會針對 limit 欄位傳回的值，超出 int 類型定義的範圍。自動化程序無法使用 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 中加入特定模組。如果系統的 initramfs 缺少這些 NVMe 模組，並且已遷移至 C3 執行個體，則開機程序會失敗。這個問題也可能會影響其他具有特殊硬體需求的執行個體類型。

解決方法

變更機器類型前，請使用所有驅動程式重新產生 initramfs：

dracut --force --no-hostonly

如果系統已受到問題影響，請建立臨時救援 VM。使用 chroot 指令存取受影響的 VM 開機磁碟，然後使用下列指令重新產生 initramfs：

dracut -f --no-hostonly

在 Z3 上使用 SUSE 12 映像檔時，本機 SSD 的 IOPS 效能較低

在 SUSE Linux Enterprise Server (SLES) 12 映像檔上，Z3 VM 在本機 SSD 磁碟上的 IOPS 效能遠低於預期。

根本原因

這是 SLES 12 程式碼集的問題。

解決方法

SUSE 尚未提供或規劃修補程式來修正這個問題。請改用 SLES 15 作業系統。

RHEL 7 和 CentOS VM 在重新啟動後會失去網路存取權

如果您的 CentOS 或 RHEL 7 VM 有多個網路介面卡 (NIC)，且其中一個 NIC 未使用 VirtIO 介面，則重新啟動時可能會失去網路存取權。這是因為如果至少一個網路介面卡未使用 VirtIO 介面，RHEL 就不會支援停用可預測的網路介面名稱。

解決方法

您可以停止及啟動 VM，直到問題解決為止，即可恢復網路連線。如要避免網路連線中斷問題再度發生，請採取下列步驟：編輯 /etc/default/grub 檔案，然後移除核心參數 net.ifnames=0 和 biosdevname=0。2. 重新產生 GRUB 設定。3. 重新啟動 VM。

在執行 SUSE Linux 的 C3 和 C3D VM 上，本機 SSD 裝置缺少符號連結

公開 Google Cloud SUSE 映像檔不包含建立 C3 和 C3D 本機 SSD 裝置符號連結所需的 udev 設定。

解決方法

如要為 SUSE 和自訂映像檔新增 udev 規則，請參閱「Symlinks 未使用本機 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

解決方法

如要修正這個問題，請設定 repo_gpgcheck=0，在 yum 存放區設定中停用存放區 GPG 金鑰檢查功能。在支援的 Compute Engine 基本映像檔中，您可以在 /etc/yum.repos.d/google-cloud.repo 檔案中找到這項設定。不過，VM 可以在不同的存放區設定檔或自動化工具中設定此值。

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 Login 的執行個體會在連線後傳回登入訊息

對於某些使用 OS Login 的執行個體，您可能會在建立連線後收到以下錯誤訊息：

/usr/bin/id: cannot find name for group ID 123456789

解決方法

請忽略這則錯誤訊息。

Windows VM 執行個體的已知問題

• 使用社群 NVMe 驅動程式時，Windows 上的 NVMe 支援功能仍處於Beta 版，效能可能不如 Linux 執行個體。 Google Cloud 公開映像檔中的社群 NVMe 驅動程式已由 Microsoft StorNVMe 驅動程式取代。建議您在 2022 年 5 月前建立的 VM 上取代 NVME 驅動程式，並改用 Microsoft StorNVMe 驅動程式。
• 在建立執行個體後，您無法立即連線至該執行個體。全新的 Windows 執行個體會使用系統準備 (sysprep) 工具來設定執行個體，這可能需要 5 至 10 分鐘才能完成。
• 如果沒有連到 kms.windows.googlecloud.com 的網路連線，就無法啟用 Windows Server 映像檔，且要是未在 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 時間漂移時發生錯誤

針對在 Compute Engine 上執行 VirtIO NIC 的 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 不會發生這個問題。

為避免這個問題，Google 建議使用其他 NTP 漂移量測工具，例如 Meinberg 時間伺服器監控器。

將 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 變更回原始機器類型，以便 VM 再次執行。應該會順利啟動。請詳閱遷移規定，確認您符合相關規定。然後重試指示。

在 Windows VM 上使用 gVNIC 時，頻寬受限

Compute Engine 提供的 Windows 映像檔中封裝的 gVNIC 驅動程式，可在 Windows 執行個體上達到最高 50 Gbps 的網路頻寬，同時支援標準網路效能和各 VM Tier_1 網路效能。更新版的 gVNIC 驅動程式可提供線路速率效能 (最高 200 Gbps)，並支援巨型封包。

更新版驅動程式僅適用於第三代及後續機器系列 (不含 N4)。詳情請參閱「在 Windows OS 上更新 gVNIC 版本」。

新版 VM 機器系列的磁碟數量附加限制

在 Microsoft Windows 上以 NVMe 磁碟介面執行的 VM (包括 T2A、所有第三代及更新版本的 VM，以及使用機密運算的 VM)，磁碟連結數量上限為 16 個。為避免發生錯誤，請將 Persistent Disk 和 Hyperdisk 儲存空間整合，每個 VM 最多可使用 16 個磁碟。本機 SSD 儲存空間不受此問題影響。

在 2022 年 5 月前建立的 VM 上，替換 NVME 驅動程式

如果您想在使用 Microsoft Windows 的 VM 上使用 NVMe，且該 VM 是在 2022 年 5 月 1 日前建立，則必須更新 Guest OS 中現有的 NVMe 驅動程式，才能使用 Microsoft StorNVMe 驅動程式。

您必須先更新 VM 上的 NVMe 驅動程式，才能將機器類型變更為第三代機器系列，或建立用於建立使用第三代機器系列的新 VM 的開機磁碟快照。

使用下列指令安裝 StorNVME 驅動程式套件，並移除客體作業系統中的社群驅動程式 (如果有)。

googet update
googet install google-compute-engine-driver-nvme

在 Microsoft Windows 上使用 C3 和 C3D VM 時，本機 SSD 的效能較低

執行 Microsoft Windows 的 C3 和 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. 在管理員 Command Prompt 或 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 上發生一般磁碟錯誤

目前在特定 Windows 訪客環境中，無法如預期在執行中的 M3、C3 或 C3D VM 上新增或調整 Hyperdisk 或持久性磁碟的大小。Windows Server 2012 R2 和 Windows Server 2016，以及相應的非伺服器 Windows 變體，無法正確回應磁碟連結和磁碟大小調整指令。

舉例來說，從執行中的 M3 VM 移除磁碟會將磁碟與 Windows Server 執行個體中斷連線，但 Windows 作業系統不會辨識磁碟已消失。後續寫入磁碟的動作會傳回一般錯誤。

解決方法

修改 Hyperdisk 或永久磁碟後，您必須重新啟動在 Windows 上執行的 M3、C3 或 C3D VM，才能讓這些來賓辨識磁碟修改內容。