本頁面由 Cloud Translation API 翻譯而成。

已知問題

Linux Windows

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

一般問題

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

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

您無法使用 Google Cloud 控制台建立使用 A4 或 A3 Ultra 系列機器的 Spot VM。具體來說，在「建立執行個體」頁面中，您在「機器設定」窗格中為這些機器系列選取 GPU 類型後，「進階」窗格會顯示「需要預訂」，且不允許您在「VM 佈建模型」清單中選取「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 資訊就會更新。

代管執行個體群組 (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 使用 `-lssd` 機型時的限制

使用 Google Kubernetes Engine API 時，您佈建的節點集區 (已連結本機 SSD) 必須與所選 C4、C3 或 C3D 機型具有相同數量的 SSD 磁碟。舉例來說，如果您打算建立使用 c3-standard-8-lssd 的 VM，則必須有 2 個 SSD 磁碟，而 c3d-standard-8-lssd 只需要 1 個 SSD 磁碟。如果磁碟數量不符，Compute Engine 控制平面會顯示本機 SSD 設定錯誤。請參閱「會自動連結本機 SSD 磁碟的機器類型」，根據 lssd 機器類型選取正確數量的本機 SSD 磁碟。

使用 Google Kubernetes Engine Google Cloud 控制台建立叢集或節點集區時，如果使用 c4-standard-*-lssd、c4-highmem-*-lssd、c3-standard-*-lssd 和 c3d-standard-*-lssd VM，節點建立作業會失敗，或無法偵測到本機 SSD 做為暫時性儲存空間。

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

如果 C3D VM 的 vCPU 超過 30 個，單一封包流的 TCP 處理量可能會有所差異，有時會限制在 20 到 25 Gbps。如要提高速率，請使用多個 TCP 流程。

如果 VM 每個核心使用一個執行緒，CPU 使用率可觀測性指標就會不正確

如果 VM 的 CPU 每個核心使用一個執行緒，則「Compute Engine」>「VM 執行個體」>「可觀測性」分頁中的 CPU 使用率 Cloud Monitoring 可觀測性指標只會擴充至 50%。除了 Tau T2D 以外，所有機型預設每個核心有兩個執行緒。詳情請參閱「設定每個核心的執行緒數量」。

如要查看 VM 的 CPU 使用率 (已正規化為 100%)，請改用 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 回應資料，可能會失敗

如果發生下列情況，您使用 API 回應資料的自動程序可能會失敗，這些資料與 Compute Engine 資源型承諾配額有關。自動化程序可包含使用或儲存 API 回應的任何程式碼片段、商業邏輯或資料庫欄位。

回應資料來自下列任一 Compute Engine API 方法：
您可以使用 int，而非 number，在 API 回應主體中定義資源配額限制的欄位。您可以透過下列方式，在每種方法中找到該欄位：
- items[].quotas[].limit，適用於 compute.regions.list 方法。
- quotas[].limit，適用於 compute.regions.get 方法。
- quotas[].limit，適用於 compute.projects.get 方法。
您可為任何 Compute Engine 承諾使用 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 大小的封包遺失率

如果 Dynamic NIC 具有上層 vNIC，且 MTU 大小為自訂值，可能會發生封包遺失情形。

解決方法

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

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

使用動態 NIC 重複使用 VLAN ID 時的防火牆互動

在執行個體上，為新的動態 NIC 重複使用 VLAN ID 會影響防火牆連線追蹤。如果刪除動態 NIC，並建立使用相同 VLAN ID 的替代動態 NIC，防火牆連線追蹤資料表項目不會自動清除。以下範例顯示相關安全性考量：

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

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

解決方案

如要為每個執行個體建立與從執行個體移除的 Dynamic NIC 使用相同 VLAN ID 的 Dynamic NIC，請按照下列步驟操作：

刪除原始動態 NIC 後，請等待至少 10 分鐘，再建立替代的動態 NIC。
停止執行個體、刪除原始動態 NIC 並建立替代動態 NIC，然後啟動執行個體。

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

使用動態 NIC 時，封包攔截可能會導致封包遭到捨棄。如果管道提早終止，可能會發生封包遭捨棄的情況。這項問題會影響以工作階段為基礎和非以工作階段為基礎的模式。

根本原因

在封包攔截期間，如果管道提早終止 (進入攔截和輸出重新注入)，就會發生封包遺失情形。提早終止會導致進入封包的乙太網路標頭缺少 VLAN ID。由於輸出封包是從修改後的輸入封包衍生而來，因此輸出封包也會缺少 VLAN ID。這會導致端點索引選取錯誤，並造成後續封包捨棄。

解決方法

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

Linux VM 執行個體的已知問題

以下是 Linux VM 的已知問題。

使用 OS 映像檔版本 v20250530 的 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 會因導入新的設定檔 (https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf)，將 local 新增至搜尋路徑。

   [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-configs20250501 版已修正這個問題，但 Canonical 尚未將修正內容納入映像檔。

解決方法

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

使用 hostname -f 指令確認 FQDN

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

變更執行個體類型後，SUSE Enterprise VM 無法啟動

變更 SUSE Linux Enterprise VM 的執行個體類型後，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。使用 chroot 指令存取受影響 VM 的開機磁碟，然後使用下列指令重新產生 initramfs：

dracut -f --no-hostonly

使用 SUSE 12 映像檔時，Z3 上的本機 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 介面，則重新啟動後可能會失去網路存取權。這是因為如果至少有一個 NIC 未使用 VirtIO 介面，RHEL 就不支援停用可預測的網路介面名稱。

解決方法

如要還原網路連線，請停止並啟動 VM，直到問題解決為止。如要避免網路連線中斷問題再次發生，請採取下列措施：

編輯 /etc/default/grub 檔案，然後移除核心參數 net.ifnames=0 和 biosdevname=0。
重新產生 grub 設定。
重新啟動 VM。

已解決：在執行 SUSE Linux 的 C3 和 C3D VM 上，本機 SSD 裝置的符號連結遺失

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

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

解決方法

如要為 SUSE 和自訂映像檔新增 udev 規則，請參閱「Symlinks not created C3 and C3D with Local SSD」。

無法驗證 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 存放區設定中停用存放區 GPG 金鑰檢查，方法是設定 repo_gpgcheck=0。在支援的 Compute Engine 基本映像檔中，這項設定可能位於 /etc/yum.repos.d/google-cloud.repo 檔案。不過，您的 VM 可以在不同的存放區設定檔或自動化工具中設定這個值。

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

使用 OS Login 的執行個體會在連線後傳回登入訊息

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

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

解決方法

請忽略這則錯誤訊息。

Windows VM 執行個體的已知問題

使用 Community 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 上的 Windows VM 執行 VirtIO NIC，使用下列指令測量 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 Time Server Monitor。

將 VM 從第 1 代或第 2 代更新為第 3 代以上的 VM 後，無法存取開機裝置

Windows Server 會在首次啟動時，將開機磁碟繫結至初始磁碟介面類型。如要將現有 VM 從使用 SCSI 磁碟介面的舊型機器系列，變更為使用 NVMe 磁碟介面的新型機器系列，請先執行 Windows PnP 驅動程式系統準備程序，再關閉 VM。這個系統準備程序只會準備裝置驅動程式，並驗證所有磁碟介面類型是否已掃描下一次啟動時的開機磁碟機。

如要更新 VM 的機器系列，請按照下列步驟操作：

在 PowerShell 提示中，以 Administrator 執行：

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait

停止 VM。
將 VM 變更為新的 VM 機器類型。
啟動 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 上執行的 VM (包括 T2A 和所有第三代 VM) 採用 NVMe 磁碟介面，因此磁碟附加數量上限為 16 個。這項限制不適用於第四代 VM (c4、m4)。為避免發生錯誤，請將 Persistent Disk 和 Hyperdisk 儲存空間合併，每個 VM 最多可有 16 個磁碟。本機 SSD 儲存空間不在此問題範圍內。

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

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

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

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

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

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

執行 Microsoft Windows 的 C3 和 C3D VM，本機 SSD 效能會受到限制。

我們正在努力提升效能。

使用 gVNIC 時網路處理量不佳

如果 Windows Server 2022 和 Windows 11 VM 使用 GooGet 套件 1.0.0@44 版或更早版本的 gVNIC 驅動程式，則使用 Google Virtual NIC (gVNIC) 時，網路輸送量可能會不佳。

如要解決這個問題，請按照下列步驟，將 gVNIC 驅動程式 GooGet 套件更新至 1.0.0@45 以上版本：

在管理員命令提示字元或 Powershell 工作階段中執行下列指令，檢查 VM 上安裝的驅動程式版本：
```
googet installed
```
輸出看起來類似以下內容：
```
Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...
```
如果 google-compute-engine-driver-gvnic.x86_64 驅動程式版本為 1.0.0@44 或更早版本，請從管理員命令提示字元或 Powershell 工作階段執行下列指令，更新 GooGet 套件存放區：
```
googet update
```

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

搭載超過 144 個 vCPU 的 C4 機器類型，以及搭載超過 180 個 vCPU 的 C4D 和 C3D 機器類型，不支援 Windows Server 2012 和 2016 OS 映像檔。使用 Windows Server 2012 和 2016 OS 映像檔的較大 C4、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，這些客體才能辨識磁碟修改內容。

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

一般問題

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

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

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

代管執行個體群組 (MIG) 中的 baseInstanceName 值過長，可能會導致磁碟名稱衝突

使用指定 A2、C3 或 G2 機型的執行個體範本建立預留項目或未來預留項目要求時，會發生問題

搭配 Google Kubernetes Engine 使用 -lssd 機型時的限制

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

如果 VM 每個核心使用一個執行緒，CPU 使用率可觀測性指標就會不正確

如果您使用自訂防火牆規則，Google Cloud 主控台瀏覽器中的 SSH 連線可能會失敗

磁碟的暫時名稱

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

如果自動化程序使用資源型承諾配額的 API 回應資料，可能會失敗

根本原因

如何解決這個問題

Bare Metal 執行個體的已知問題

使用 Dynamic Network Interface 時發生的問題

自訂 MTU 大小的封包遺失率

解決方法

使用動態 NIC 重複使用 VLAN ID 時的防火牆互動

解決方案

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

根本原因

解決方法

Linux VM 執行個體的已知問題

使用 OS 映像檔版本 v20250530 的 Ubuntu VM 顯示的 FQDN 不正確

根本原因

解決方法

變更執行個體類型後，SUSE Enterprise VM 無法啟動

根本原因

解決方法

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

根本原因

解決方法

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

已解決：在執行 SUSE Linux 的 C3 和 C3D VM 上，本機 SSD 裝置的符號連結遺失

無法驗證 repomd.xml 簽章

使用 OS Login 的執行個體會在連線後傳回登入訊息

Windows VM 執行個體的已知問題

Windows Server 2025 和 Windows 11 24h2 - 支援暫停及繼續

使用 Windows VM 上的 w32tm 測量 NTP 時間偏移時發生錯誤

將 VM 從第 1 代或第 2 代更新為第 3 代以上的 VM 後，無法存取開機裝置

Windows VM 上的 gVNIC 頻寬有限

較新的 VM 機型系列可附加的磁碟數量有限

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

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

使用 gVNIC 時網路處理量不佳

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

M3、C3、C3D 和 C4D VM 的 Windows Server 2016 和 2012 R2 發生一般磁碟錯誤

已知問題

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

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

代管執行個體群組 (MIG) 中的 `baseInstanceName` 值過長，可能會導致磁碟名稱衝突

搭配 Google Kubernetes Engine 使用 `-lssd` 機型時的限制