已知問題

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

一般問題

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

您無法使用 Google Cloud 控制台為 A4 和 A3 Ultra 建立 Spot VM

您無法使用 Google Cloud 控制台建立使用 A4 或 A3 Ultra 機器系列的 Spot VM。具體來說，在「Create an instance」頁面中，您在「Machine configuration」窗格中為這些機器系列選取 GPU 類型後，「Advanced」窗格會指出「A reservation is required」，並禁止您在「VM provisioning model」清單中選取「Spot」。

如要解決這個問題，請使用 gcloud CLI 或 REST 為 A4 和 A3 Ultra 建立 Spot VM。或者，您也可以使用 Google Cloud 主控台建立使用預留空間綁定佈建模式的 A4 和 A3 Ultra 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，即可繼續使用瀏覽器中的 SSHGoogle Cloud 主控台功能連線至 VM。

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

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

磁碟的臨時名稱

在使用 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 以下。您必須為所有區域中具有資源承諾的專案設定配額上限。您可以透過下列任一方式執行此操作：

  • 請按照申請配額調整的步驟，要求降低配額上限。
  • 建立配額覆寫值。

Bare Metal 執行個體的已知問題

C4D 裸機執行個體無法執行 SUSE Linux Enterprise Server (SLES) 15 SP6 作業系統。

解決方法

請改用 SLES 15 SP5。

使用 Dynamic Network Interface 相關的問題

本節說明使用多個網路介面和動態網路介面時的已知問題。

使用自訂 MTU 大小時的封包遺失

具有上層 vNIC 的 Dynamic NIC 可能會在自訂 MTU 大小下發生封包遺失的情形。

解決方法

為避免封包遺失，請使用下列任一 MTU 大小：

• 1,460 個位元組 (虛擬私有雲網路的預設值)
• 1,500 個位元組 (標準乙太網路)
• 8,896 位元組 (可能的最大值)

使用動態網路介面卡重複使用 VLAN ID 時的防火牆互動

在執行個體中，如果為新的動態 NIC 重複使用 VLAN ID，就會影響防火牆連線追蹤。如果您刪除動態網路介面卡，並建立使用相同 VLAN ID 的替換動態網路介面卡，防火牆連線追蹤表項目不會自動清除。以下範例說明相關的安全性考量：

1. 某個運算執行個體具有具體的動態 NIC，其 VLAN ID 4 已連線至 network-1 虛擬私有雲網路中的子網路。
2. 執行個體會將封包傳送至 192.0.2.7:443 目的地 IP 位址和目的地通訊埠。適用的輸出防火牆規則允許傳出連線。
3. 由於 Cloud NGFW 規則具有狀態，因此允許的輸出連線會建立防火牆連線追蹤表項目，允許來自來源 IP 位址和來源通訊埠 192.0.2.7:443 的傳入封包。
4. 您刪除範例動態網路介面卡，並建立替換的動態網路介面卡。替換的 Dynamic NIC 也會使用 VLAN ID 4，但會連線至不同 VPC 網路 network-2 中的子網路。
5. 所有未過期的防火牆連線追蹤表項目 (適用於原始動態 NIC)，都適用於替換的動態 NIC。這表示 network-2 虛擬私人雲端網路中的資源可以傳送來源符合 192.0.2.7:443 的封包，而運算執行個體會接受這些封包，而不需要評估 ingress 防火牆規則。

如要進一步瞭解連線追蹤和防火牆規則，請參閱 Cloud Next Generation Firewall 說明文件中的「規格」。

解決方案

針對個別執行個體，如果您需要建立的 Dynamic NIC 使用與從執行個體移除的 Dynamic NIC 相同的 VLAN ID：

• 請在刪除原始動態網路介面卡和建立替換動態網路介面卡之間等待至少 10 分鐘。
• 停止執行個體、刪除原始動態網路介面卡，然後建立替換的動態網路介面卡，再啟動執行個體。

封包攔截可能會導致封包遭到捨棄，因為乙太網路標頭中缺少 VLAN 標記

使用動態 NIC 時，封包攔截作業可能會導致封包遺失。管道提前終止時，可能會發生封包遺漏的情況。這個問題會影響以工作階段為基礎和非以工作階段為基礎的模式。

根本原因

當管道提早終止 (入站攔截和出站重新注入) 時，就會在封包攔截期間發生封包遺失。提早終止會導致入站封包的乙太網路標頭缺少 VLAN ID。由於傳出封包是從修改過的傳入封包衍生而來，因此傳出封包也缺少 VLAN ID。這會導致選取錯誤的端點索引，並隨後導致封包遺失。

解決方法

請勿使用 Google Cloud 依賴封包攔截的功能，例如防火牆端點。

Linux VM 執行個體的已知問題

以下是 Linux VM 的已知問題。

使用 OS 映像檔 20250530 的 Ubuntu VM 顯示錯誤的 FQDN

執行下列任一操作時，您可能會看到不正確的完整網域名稱 (FQDN)，並附加 .local 後置字串：

• 更新至 google-compute-engine 套件的 20250328.00 版。
• 從任何 Canonical 提供的 Ubuntu 映像檔 (版本後綴為 v20250530) 啟動執行個體。例如：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

根本原因

在所有版本為 v20250530 的 Ubuntu 映像檔中，guest-config 套件版本 20250328.00 會在搜尋路徑中新增 local，這是因為新設定檔的推出：https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf

   [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 尚未將修正項目納入其映像檔。

解決方法

1. 將 Domains=local 變更為 Domains=~local，修改網路名稱解析設定檔 /etc/systemd/resolved.conf.d/gce-resolved.conf
2. 執行下列指令，重新啟動 systemd-resolved 服務：systemctl restart systemd-resolved
3. 確認 local 已從 /etc/resolv.conf 的搜尋路徑中移除

4. 使用 hostname -f 指令確認 FQDN

   [root@ubuntu2204 ~]# hostname -f
   ubuntu2204.us-central1-a.c.my-project.internal
   

變更執行個體類型後，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 裝置缺少符號連結

以下問題已於 2025 年 1 月 13 日解決。

公開 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)，磁碟連結上限為 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
   

大型 C4D 和 C3D vCPU 機器類型不支援 Windows OS 映像檔

搭載超過 180 個 vCPU 的 C4D 和 C3D 機器類型不支援 Windows Server 2012 和 2016 OS 映像檔。使用 Windows Server 2012 和 2016 OS 映像檔的大型 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 上發生一般磁碟錯誤

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

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

解決方法

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