本頁說明您在使用 Compute Engine 執行個體時可能會遇到的問題。如要瞭解會影響機密 VM 的問題，請參閱「機密 VM 限制」。
一般問題
下列問題提供疑難排解指引或一般資訊。
啟用安全啟動功能的 Compute 執行個體可能無法啟動
在極少數情況下，於 2025 年 11 月 7 日前建立的 Shielded VM 執行個體 (已啟用安全啟動)，或使用全磁碟加密軟體或機密密封至 vTPM PCR 的執行個體，可能會無法啟動。2026 年下半年 Microsoft 安全啟動憑證到期後，如果更新順序有誤 (例如更新墊片，但沒有適當的憑證)，就可能發生這種情況。
解決方法
如要解決這個問題，請使用新憑證更新運算執行個體。詳情請參閱「Microsoft 安全啟動憑證到期指南」。
如果 C4A、C4D、C4 和 H4D 執行個體連接的本機 SSD 磁碟發生斷電，可能無法擷取所有寫入作業
主機伺服器斷電後，如果 Compute Engine 可以復原本機 SSD 磁碟上的資料，則在該主機伺服器上執行的運算執行個體會重新啟動，並連接所有磁碟，資料則包含主機錯誤發生前完成的所有寫入作業。
如果是 C4A、C4D、C4 和 H4D 執行個體，還原的本機 SSD 磁碟可能不包含電源中斷事件發生前立即完成的寫入作業。運算執行個體重新啟動時，從受影響的邏輯區塊位址 (LBA) 讀取資料會傳回錯誤，指出 LBA 無法讀取。如果運算執行個體發生非預期的重新啟動，請在運算執行個體重新啟動後，檢查 OS 錯誤記錄中是否有讀取或寫入失敗的情形。
Hyperdisk Throughput 和 Hyperdisk Extreme 容量會同時消耗 Persistent Disk 配額
建立 Hyperdisk Throughput 或 Hyperdisk Extreme 磁碟時，磁碟容量會同時計入兩項配額：特定 Hyperdisk 配額和對應的 Persistent Disk 配額。
Hyperdisk Throughput Capacity (GB)(HDT-TOTAL-GB) 也會計入Persistent disk standard (GB)(DISKS-TOTAL-GB) 配額。Hyperdisk Extreme Capacity (GB)(HDX-TOTAL-GB) 也會計入Persistent disk SSD (GB)(SSD-TOTAL-GB) 配額。
如果永久磁碟配額低於 Hyperdisk 配額，就會發生 QUOTA_EXCEEDED 錯誤。達到 Persistent Disk 上限後，即使還有 Hyperdisk 配額，也無法建立其他磁碟。
如要解決這個問題，要求提高配額時，請一併調整這兩項配額。調整 HDT-TOTAL-GB 或 HDX-TOTAL-GB 配額時，也必須分別調整 DISKS-TOTAL-GB 或 SSD-TOTAL-GB 配額。
NVIDIA B200 GPU 的韌體問題導致 A4 執行個體上的工作負載中斷
NVIDIA 發現 B200 GPU (A4 執行個體使用) 有兩項韌體問題，會導致工作負載中斷。具體來說，如果您發現 A4 執行個體的工作負載中斷，請檢查下列任一情況是否屬實：
- 運算執行個體的正常運作時間 (
lastStartTimestamp欄位) 超過 65 天。 - 記錄會顯示提及
0x02a的Xid 149訊息。
如要解決這個問題，請重設 GPU。為避免發生問題，請每隔 60 天至少重設一次 A4 執行個體上的 GPU。
在單一用戶群節點上建立 C4 執行個體時，可能發生的主機錯誤
在單一租戶節點上執行的 C4 機型執行個體，可能會因主機錯誤或執行個體建立失敗，而發生執行個體意外終止的情況。
為解決這個問題，Google 已將每個單一租戶節點允許的 C4 執行個體數量上限設為 26。
序列埠主控台僅供 C4 和 C4D 裸機執行個體讀取
您無法為 C4 或 C4D 裸機執行個體啟用序列主控台的互動存取權，因為序列主控台為唯讀。
解決方法
如要以互動方式執行指令，您可以在執行個體啟動後，使用 SSH 連線至執行個體。如要瞭解如何搭配使用 SSH 與 Compute Engine 執行個體，請參閱「關於 SSH 連線」一文。
在 32 個節點以上的 HPC 叢集上取消工作時，會超過逾時時間
如果叢集有 32 個以上的節點，且工作量很大，取消工作所需的時間可能會超過預設的 UnkillableStepTimeout 值 (300 秒)。如果超過這個值，受影響的節點就會無法用於日後的作業。
如要解決這個問題，請採取下列任一做法：
將 Cluster Toolkit 更新至 1.65.0 以上版本。然後使用下列指令重新部署叢集：
gcluster deploy -w --force BLUEPRINT_NAME.yaml如果無法更新 Cluster Toolkit 或重新部署叢集，可以完成下列步驟，手動修改
UnkillableStepTimeout參數：使用 SSH 連線至叢集的主要控制器節點。
gcloud compute ssh --project PROJECT_ID --zone ZONE DEPLOYMENT_NAME-controller如要查看主要控制器節點的確切名稱和 IP 位址，請使用 Google Cloud 控制台並前往「VM 執行個體」頁面。
建立目前
cloud.conf檔案的備份。這個檔案通常位於/etc/slurm/。sudo cp /etc/slurm/cloud.conf /etc/slurm/cloud.conf.backup-$(date +%Y%m%d)使用
sudo權限，以文字編輯器開啟/etc/slurm/cloud.conf檔案。新增或修改包含
UnkillableStepTimeout的行。舉例來說，如要將逾時時間設為 900 秒 (15 分鐘)，請按照下列步驟操作：UnkillableStepTimeout=900儲存檔案。
使用
sudo scontrol reconfigure指令，在叢集中套用新設定，不必完全重新啟動。
驗證修正結果
執行下列指令，即可確認設定是否已變更：
scontrol show config | grep UnkillableStepTimeout
輸出內容應反映您設定的新值，例如：UnkillableStepTimeout = 900。
已解決：使用 gcloud compute disks update 指令修改非同步複製主要磁碟的 IOPS 或輸送量時，會導致錯誤
以下問題已於 2025 年 6 月 1 日解決。
使用 gcloud compute disks update 指令修改非同步複製主要磁碟的 IOPS 和處理量時，即使更新成功，gcloud CLI 仍會顯示錯誤訊息。
如要準確驗證更新是否成功，請使用 gcloud CLI 或 Google Cloud 控制台檢查磁碟屬性，查看新的 IOPS 和處理量值。詳情請參閱「查看 Hyperdisk 的佈建效能設定」。
中繼資料伺服器可能會顯示舊的 physicalHost 運算執行個體中繼資料
發生主機錯誤後，系統會將運算執行個體移至新主機。此時，如果您查詢中繼資料伺服器，可能會看到執行個體先前主機的 physicalHost 中繼資料。
如要解決這個問題，請採取下列任一做法：
- 使用
instances.get方法或gcloud compute instances describe指令，擷取正確的physicalHost資訊。 - 停止並啟動執行個體。這項程序會更新中繼資料伺服器中的
physicalHost資訊。 - 等待 24 小時，受影響執行個體的
physicalHost資訊就會更新。
代管執行個體群組 (MIG) 中的 baseInstanceName 值過長，可能會導致磁碟名稱衝突
在 MIG 中，如果執行個體範本指定要在建立運算執行個體時建立磁碟，且 baseInstanceName 值超過 54 個字元，就可能發生磁碟名稱衝突。這是因為 Compute Engine 會使用執行個體名稱做為前置碼，產生磁碟名稱。
產生磁碟名稱時，如果名稱超過 63 個字元的資源名稱限制，Compute Engine 會從執行個體名稱結尾截斷多餘字元。如果執行個體的命名模式相似，這種截斷方式可能會導致建立相同的磁碟名稱。在這種情況下，新執行個體會嘗試連結現有磁碟。如果磁碟已連結至其他運算執行個體，則新執行個體建立作業會失敗。如果磁碟未附加或處於多重寫入模式，新執行個體就會附加磁碟，可能導致資料損毀。
為避免磁碟名稱衝突，請將 baseInstanceName 值設為長度上限 54 個字元。
使用指定 A2、C3 或 G2 機型的執行個體範本建立預留項目或未來預留項目要求時，會發生問題
如果您使用指定 A2、C3 或 G2 機型的執行個體範本建立預留項目，或是建立並提交未來預留要求以供審查，就會遇到問題。具體來說，可能會發生下列情況：
建立預留項目可能會失敗。如果成功，則適用下列其中一種情況：
如果您建立的是自動使用的保留項目 (預設)，則建立屬性相符的運算執行個體時，不會使用保留項目。
如果您建立了特定預留項目，則建立明確指定該預留項目的運算執行個體會失敗。
未來預留項目要求建立作業成功。不過，如果將要求送交審查， Google Cloud 通常會拒絕。
您無法取代用於建立預留項目或未來預留項目要求的執行個體範本，也無法覆寫範本的執行個體屬性。如要預留 A2、C3 或 G2 機型資源，請改用下列任一方法：
如要建立新的未來預留項目要求，請按照下列步驟操作：
如要停止現有的未來預留項目要求，避免限制您在目前專案中建立的未來預留項目要求屬性，或是限制與未來預留項目要求共用的專案，請刪除未來預留項目要求。
直接指定屬性，建立單一專案或共用未來預留項目要求，然後提交審查。
搭配 Google Kubernetes Engine 使用 -lssd 機型時的限制
使用 Google Kubernetes Engine API 時，您透過本機 SSD 磁碟佈建的節點集區必須與所選 C4、C3 或 C3D 機型具有相同數量的本機 SSD 磁碟。舉例來說，如果您打算建立使用 c3-standard-8-lssd 機型的運算執行個體，則必須有兩個本機 SSD 磁碟；如果您使用 c3d-standard-8-lssd 機型，則只需要一個磁碟。如果磁碟編號不符，Compute Engine 控制層就會顯示本機 SSD 設定錯誤。請參閱「會自動連結本機 SSD 磁碟的機型」，根據 lssd 機型選取正確數量的本機 SSD 磁碟。
如果您使用 Google Kubernetes Engine Google Cloud 控制台建立叢集或節點集區，則節點建立作業會失敗，或使用下列任一機器類型時，系統不會將本機 SSD 磁碟偵測為暫時性儲存空間：
c4-standard-*-lssdc4-highmem-*-lssdc3-standard-*-lssdc3d-standard-*-lssd
C3D 執行個體上的單一流量 TCP 處理量變異性
如果 C3D 執行個體的 vCPU 超過 30 個，單一封包流的 TCP 處理量可能會有所變動，有時會限制在 20 到 25 Gbps 之間。如要提高速率，請使用多個 TCP 流程。
如果運算執行個體每個核心使用一個執行緒，CPU 使用率可觀測性指標會不正確
如果運算執行個體的 CPU 每個核心使用一個執行緒，則 Compute Engine Google Cloud 主控台「VM 執行個體」頁面的「可觀測性」* 分頁中，CPU 使用率 Cloud Monitoring 指標只會擴充至 50%。大多數機型預設為每個核心兩個執行緒。詳情請參閱「設定每個核心的執行緒數量」。
如要查看 CPU 使用率 (已正規化為 100%)，請改用 Metrics Explorer 查看 CPU 使用率。詳情請參閱「使用 Metrics Explorer 建立圖表」一文。
如果您使用自訂防火牆規則，Google Cloud 主控台瀏覽器中的 SSH 連線可能會失敗
如果您使用自訂防火牆規則控管運算執行個體的 SSH 存取權，可能就無法使用透過瀏覽器建立 SSH 連線功能。
如要解決這個問題，請採取下列任一做法：
啟用 Identity-Aware Proxy for TCP，繼續使用瀏覽器中的 SSHGoogle Cloud 控制台功能連線至 Compute 執行個體。
重新建立
default-allow-ssh防火牆規則，即可繼續使用瀏覽器中的 SSH 連線至運算執行個體。使用 Google Cloud CLI 連線至運算執行個體，而非透過瀏覽器建立 SSH 連線。
磁碟的暫時名稱
使用 gcloud compute instances update 指令或 instances.update API 方法啟動運算執行個體更新時，Compute Engine 可能會暫時變更運算執行個體磁碟的名稱，在原始名稱中加入下列任一後置字元：
-temp-old-new
更新完成後，Compute Engine 會移除後置字元，並還原原始磁碟名稱。
磁碟大小調整作業導致部分永久磁碟的延遲時間增加
在某些情況下，調整大型永久磁碟 (約 3 TB 以上) 的大小可能會影響磁碟的 I/O 效能。如果受到這個問題影響，永久磁碟在調整大小期間可能會出現延遲時間增加的情況。這個問題可能會影響任何類型的 Persistent Disk。
如果自動化程序使用資源型承諾配額的 API 回應資料，可能會失敗
如果發生下列情況，您使用 Compute Engine 資源配額相關 API 回應資料的自動化程序可能會失敗。自動化程序可以包含使用或儲存 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 以下。 您必須為所有具有資源型承諾的專案，在所有區域中設定配額上限。你可以透過下列任一方式執行此操作：
GPU 執行個體的已知問題
以下章節說明 Compute Engine GPU 執行個體的已知問題。
如果加速器最佳化機型自動連結本機 SSD 磁碟，可能需要數小時才能終止及重新啟動
加速器最佳化機型會自動附加 GPU。除了 A2 Standard 以外，大多數 A 系列加速器最佳化機型都會自動連接本機 SSD 磁碟。
經過加速器最佳化的機器類型不支援即時遷移，您必須將主機維護政策設為 TERMINATE。發生失敗或主機錯誤後，這些機器類型最多可能需要一小時才能終止。對於自動連接本機 SSD 磁碟的加速器最佳化機型，終止程序可能需要數小時。
使用動態 NIC 和 GPU 執行個體時發生建立錯誤和效能降低
動態 NIC 不支援搭配 GPU 執行個體使用。如果您使用動態 NIC 建立 GPU 執行個體，或將動態 NIC 新增至現有 GPU 執行個體，可能會發生下列問題：
作業失敗，並顯示下列錯誤：
Internal error. Please try again or contact Google Support. (Code: 'CODE')作業成功，但執行個體效能下降，例如網路頻寬大幅降低。
發生這些問題的原因是，當 Compute Engine 嘗試將執行個體的 vNIC 分散到主機伺服器上的實體 NIC 時，Dynamic NIC 設定會導致錯誤。
裸機執行個體的已知問題
以下是 Compute Engine 裸機執行個體的已知問題。
C4D 裸機機型不支援 SUSE Linux 15 SP6 映像檔
C4D 裸機執行個體無法執行 SUSE Linux Enterprise Server (SLES) 15 SP6 版作業系統。
解決方法
請改用 SLES 15 SP5。
模擬主機維護作業不適用於 C4 Bare Metal 執行個體
c4-standard-288-metal 和 c4-highmem-288-metal 機器類型不支援模擬主機維護事件。
解決方法
使用以其他 C4 機型建立的虛擬機器 (VM) 執行個體，模擬維護事件。
使用不以
-metal結尾的 C4 機型建立 VM 執行個體。建立 VM 時，請將 C4 執行個體設定為
Terminate，在主機維護事件期間不要使用即時遷移。模擬這個 VM 的主機維護事件。
在模擬主機維護事件期間，設定為 Terminate 的 VM 行為與 C4 裸機執行個體相同。
在 RHEL 8 上使用 Z3 Bare Metal 執行個體時，效能低於預期
使用 Red Hat Enterprise Linux (RHEL) 第 8 版搭配 Z3 裸機執行個體時，網路效能會低於預期。
根本原因
RHEL 8 使用的 Linux 核心版本 (4.18) 缺少 Page Pool 功能。
解決方法
使用 Z3 裸機執行個體時，請使用較新版本的 RHEL 或其他作業系統。
使用 Dynamic Network Interface 時的問題
本節說明使用多個網路介面和動態網路介面的相關已知問題。
使用動態 NIC 時，封包會因別名 IP 範圍、通訊協定轉送或直通式網路負載平衡器而遭到捨棄
在下列情況下，客體代理程式會自動為 vNIC 新增本機路徑，但不會為動態 NIC 新增：
- 設定別名 IP 範圍時，客層代理程式會為別名 IP 範圍建立本機路由。
- 建立參照通訊協定轉送的運算執行個體的目標執行個體時，客體代理程式會為相關聯的轉送規則 IP 位址建立本機路徑。
- 將後端新增至直通式網路負載平衡器時，客層代理程式會為相關聯的轉送規則 IP 位址建立本機路徑。
由於系統不會為動態 NIC 新增本機路由，動態 NIC 可能會捨棄封包。
如要解決這個問題，請按照下列步驟手動新增 IP 位址：
使用 SSH 連線至執行個體。
如要設定別名 IP 範圍，請按照下列步驟操作。 您也可以略過這個步驟。
- 在
/etc/default/instance_configs.cfg中，確認ip_aliases設定已設為true。 如果 ip_aliases 設定設為
false，請修改檔案將其變更為true，然後重新啟動訪客代理程式：systemctl restart google-guest-agent
- 在
使用下列指令，為別名 IP 範圍或轉送規則 IP 位址設定本機路由：
ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66
更改下列內容：
IP_ADDRESS：您要新增本機路徑的別名 IP 範圍或轉送規則 IP 位址。DYNAMIC_NIC_DEVICE_NAME：要新增本機路由的 Dynamic NIC 裝置名稱。例如：a-gcp.ens4.3。
訪客代理程式版本 20250901.00 至 20251120.01 的動態 NIC 安裝和管理問題
如果您設定自動管理動態 NIC，且執行個體執行的客體代理程式版本介於 20250901.00 至 20251120.01，可能會遇到下列問題：
訪客代理程式無法在執行個體的訪客 OS 中安裝及管理動態 NIC。
在參照動態 NIC 的訪客 OS 中執行指令時，您可能會收到包含
Cannot find device的錯誤訊息。刪除多個動態 NIC 會導致中繼資料伺服器無法存取。
根本原因
自 20250901.00 版起，客體代理程式已遷移至新的外掛程式架構，以提升模組化程度。新架構最初不支援自動安裝及管理動態 NIC。
解析度
如要解決這些問題，請更新執行個體，使用訪客代理程式 20251205.00 以上版本：
- 如要將訪客代理程式更新至最新版本，請參閱「更新訪客環境」一文。
- 如要確認執行個體執行的客體代理程式版本，請參閱「依作業系統版本查看已安裝的套件」。
如有必要，您可以暫時解決執行客體代理程式版本 20250901.00 至 20251120.01 的執行個體問題，方法是按照「向後相容性」一文中的操作說明，還原至先前的客體代理程式架構。
封包攔截可能會導致封包遭到捨棄，因為乙太網路標頭缺少 VLAN 標記
使用動態 NIC 時，封包攔截可能會導致封包遭捨棄。如果管道提前終止，可能會發生封包遭捨棄的情況。這個問題會影響以工作階段為基礎和非以工作階段為基礎的模式。
根本原因
在封包攔截期間，如果管道提早終止 (進入攔截和輸出重新注入)，就會發生封包遺失情形。提早終止會導致進入封包的乙太網路標頭缺少 VLAN ID。由於輸出封包是從修改後的輸入封包衍生而來，因此輸出封包也會缺少 VLAN ID。這會導致端點索引選取錯誤，並造成後續封包遺失。
解決方法
請勿使用依賴封包攔截的 Google Cloud 功能，例如防火牆端點。
Linux 計算執行個體的已知問題
以下是 Linux 計算執行個體的已知問題。
Rocky Linux 9.7 發生套件升級錯誤
由於套件依附元件衝突，dnf update 會在 Rocky Linux Accelerator Optimized 映像檔版本 v20251113 以下 (例如 rocky-linux-9-optimized-gcp-nvidia-latest-v20251113) 失敗。您可能會看到類似下列內容的錯誤：
[root@rockylinux9 ~]# dnf update CIQ SIG/Cloud Next for Rocky Linux 9 37 MB/s | 49 MB 00:01 CIQ SIG/Cloud Next Nonfree for Rocky Linux 9 4.4 MB/s | 1.5 MB 00:00 NVIDIA DOCA 2.10.0 packages for EL 9.5 239 kB/s | 160 kB 00:00 Google Compute Engine 38 kB/s | 8.2 kB 00:00 Google Cloud SDK 59 MB/s | 154 MB 00:02 Rocky Linux 9 - BaseOS 24 MB/s | 6.3 MB 00:00 Rocky Linux 9 - AppStream 36 MB/s | 11 MB 00:00 Rocky Linux 9 - Extras 124 kB/s | 16 kB 00:00 Error: Problem 1: package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1(HNS_1.0)(64bit), but none of the providers can be installed - package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1()(64bit), but none of the providers can be installed - cannot install both libibverbs-51.0-3.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install both libibverbs-51.0-5.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install both libibverbs-54.0-2.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install both libibverbs-54.0-3.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install both libibverbs-54.0-4.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install both libibverbs-54.0-5.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install both libibverbs-57.0-3.el9_7_ciq.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install both libibverbs-57.0-2.el9.x86_64 from baseos and libibverbs-2501mlnx56-1.2501060.x86_64 from @System - cannot install the best update candidate for package perftest-25.01.0-0.70.g759a5c5.2501060.x86_64 - cannot install the best update candidate for package libibverbs-2501mlnx56-1.2501060.x86_64 Problem 2: package ucx-ib-mlx5-1.18.0-1.2501060.x86_64 from @System requires ucx(x86-64) = 1.18.0-1.2501060, but none of the providers can be installed - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from @System - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from doca - cannot install the best update candidate for package ucx-ib-mlx5-1.18.0-1.2501060.x86_64 - cannot install the best update candidate for package ucx-1.18.0-1.2501060.x86_64 ... (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
根本原因
DOCA OFED 3.20 之前的版本與 Rocky Linux 9.7 之間存在使用者空間套件版本衝突。具體來說，Rocky Linux 9.7 包含 ucx 和 perftest 套件，這些套件的版本比 DOCA OFED 存放區中的對應套件更新。版本不符會導致 dnf update 失敗，並發生依附元件解析錯誤。
解析度
執行完整系統升級前，請先更新 DOCA 存放區套件：
sudo dnf update doca-repo sudo dnf update
2025 年 12 月建構的 Rocky Linux Accelerator Optimized 映像檔 (例如 rocky-linux-9-optimized-gcp-nvidia-latest-v20251215) 已包含更新的 doca-repo 套件，因此這些建構版本或後續版本不會發生升級問題。
SLES 16 不支援 OS 登入
SUSE Linux Enterprise Server (SLES) 16 的安全殼層 (SSH) 設定問題，會導致無法使用 Google Cloud 功能 OSLogin。不過，中繼資料管理的 SSH 連線不受影響，仍可正常運作。
開機指令碼支援的網址格式
如果您的運算執行個體使用訪客代理程式 20251115.00 版，當網址使用在 Linux VM 中使用開機指令碼頁面中記錄的 https://storage.googleapis.com/ 格式時，使用 startup-script-url 中繼資料鍵擷取開機指令碼會失敗。
如要解決這個問題，請使用下列其中一種支援的網址格式：
- 已驗證的網址：
https://storage.cloud.google.com/BUCKET/FILE - gcloud CLI 儲存空間 URI：
gs://BUCKET/FILE
使用 v20250728 之前版本的 Debian 11 映像檔的 VM 執行個體無法執行 apt update
2025 年 7 月 22 日，Debian 社群移除了主要 Debian 上游的 Debian 11 (Bullseye) Backports。這項更新會導致 sudo apt update 失敗，並顯示下列錯誤：
The repository 'https://deb.debian.org/debian bullseye-backports Release' does
not have a Release file.
根本原因
由於 Debian 社群已從主要上游移除向後移植存放區，因此不再有任何對 bullseye-backports Release 的參照。
解析度
使用 debian-11-bullseye-v20250728 以上版本的映像檔。這些版本不含 Backports 存放區。或者，您也可以修改 /etc/apt/sources.list，更新目前的執行個體：
如要更新存放區網址並使用
bullseye-backports的封存檔，請執行下列操作：sudo sed -i 's/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/deb https:\/\/archive.debian.org\/debian bullseye-backports main/g; s/^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/deb-src https:\/\/archive.debian.org\/debian bullseye-backports main/g' /etc/apt/sources.list如要刪除存放區網址並捨棄
bullseye-backports：sudo sed -i '/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/d; /^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/d' /etc/apt/sources.list
ubuntu-desktop 套件安裝作業會在執行個體重新啟動時中斷網路連線
安裝 ubuntu-desktop 套件後，重新啟動 Ubuntu 運算執行個體時，網路介面可能無法正確設定。
根本原因
ubuntu-deskop 套件會將 ubuntu-settings 做為依附元件提取，將 NetworkManager 設為 netplan 的預設「renderer」。具體來說，精靈會在 netplan 插入新的 YAML 設定，/usr/lib/netplan/00-network-manager-all.yaml 包含下列項目：
network:
version: 2
renderer: NetworkManager
這項設定與我們以 networkd 為基礎，使用 cloud-init 進行的早期佈建作業衝突。
復原
如果運算執行個體已重新啟動但無法存取，請按照下列步驟操作：
- 按照救援運算執行個體的操作說明進行。
掛接無法存取的 Compute 執行個體 Linux 檔案系統分割區後，請執行下列指令 (將
/rescue替換為掛接點)：echo -e 'network:\n version: 2\n renderer: networkd' | sudo tee /rescue/etc/netplan/99-gce-renderer.yaml
使用 Ubuntu OS 版本 v20250530 的 Compute 執行個體會顯示不正確的 FQDN
執行下列任一操作時，您可能會看到不正確的完整網域名稱 (FQDN)，且該名稱會加上 .local 後置字串：
- 將
google-compute-engine套件更新至20250328.00版。 - 使用版本後置字元
v20250530，從 Canonical 提供的任何 Ubuntu 映像檔啟動運算執行個體。
例如 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 尚未將修正內容納入映像檔。
解決方法
- 修改網路名稱解析設定檔
/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
openSUSE 映像檔缺少 mkfs.ext4
自 2025 年 8 月起，近期發布的 openSUSE 映像檔 (從 opensuse-leap-15-6-v20250724-x86-64 開始) 缺少 e2fsprogs 套件，該套件提供管理檔案系統的公用程式。v20250724這個問題的常見徵兆是，您嘗試使用 mkfs.ext4 指令時，會看到 command not found 等錯誤訊息。
解決方法
如果遇到這個問題，請使用 openSUSE 套件管理工具 zypper 手動安裝缺少的套件。
# Update the package index
user@opensuse:~> sudo zypper refresh
# Install the e2fsprogs package
user@opensuse:~> sudo zypper install e2fsprogs
# Verify the installation
user@opensuse:~> which mkfs.ext4
變更機器類型後，SUSE Enterprise 計算執行個體無法開機
變更執行 SUSE Enterprise Linux 的運算執行個體機型後，執行個體可能無法啟動，序列埠控制台會顯示下列錯誤：
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
如果系統已受到問題影響，請建立臨時救援運算執行個體。使用 chroot 指令存取受影響執行個體的開機磁碟，然後使用下列指令重新產生 initramfs：
dracut -f --no-hostonly
使用 SUSE 12 映像檔時，Z3 上的本機 SSD IOPS 效能較低
使用 SUSE Linux Enterprise Server (SLES) 12 映像檔的 Z3 計算執行個體，本機 SSD 磁碟的 IOPS 效能遠低於預期。
根本原因
這是 SLES 12 程式碼集內的問題。
解決方法
SUSE 尚未提供或規劃修補程式來修正這個問題。請改用 SLES 15 作業系統。
RHEL 7 和 CentOS 計算執行個體在重新啟動後會失去網路存取權
如果 CentOS 或 RHEL 7 計算執行個體有多個網路介面卡 (NIC)，且其中一個 NIC 未使用 VirtIO 介面，則重新啟動後可能會失去網路存取權。這是因為如果至少有一個 NIC 未使用 VirtIO 介面，RHEL 就不支援停用可預測的網路介面名稱。
解決方法
如要還原網路連線，請停止並啟動運算執行個體，直到問題解決為止。如要避免網路連線中斷問題再次發生，請採取下列措施：
編輯
/etc/default/grub檔案，然後移除核心參數net.ifnames=0和biosdevname=0。重新產生 grub 設定。
重新啟動運算執行個體。
無法驗證 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 檔案。不過，您的運算執行個體可以在不同的存放區設定檔案或自動化工具中設定此項目。
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 登入 的執行個體會在連線後傳回登入訊息
對於某些使用 OS 登入 的執行個體，您可能會在建立連線後收到以下錯誤訊息：
/usr/bin/id: cannot find name for group ID 123456789
解決方法
請忽略這則錯誤訊息。
Windows 執行個體的已知問題
- 使用社群 NVMe 驅動程式的 Windows NVMe 支援功能仍為 Beta 版，效能可能不如 Linux 執行個體。在 Google Cloud 公開映像檔中，社群 NVMe 驅動程式已由 Microsoft StorNVMe 驅動程式取代。建議您替換 2022 年 5 月前建立的運算執行個體上的 NVME 驅動程式，改用 Microsoft StorNVMe 驅動程式。
- 在建立執行個體後，您無法立即連線至該執行個體。全新的 Windows 執行個體會使用系統準備 (sysprep) 工具來設定執行個體，這可能需要 5 至 10 分鐘才能完成。
- 如果沒有連到
kms.windows.googlecloud.com的網路連線，就無法啟用 Windows Server 映像檔，且要是未在 30 天內完成初次驗證，映像檔會停止運作。由 KMS 啟用的軟體必須每 180 天重新啟用一次，但 KMS 每 7 天就會嘗試重新啟用一次。請務必設定 Windows Compute 執行個體，讓這些執行個體保持啟用狀態。 - 存取非模擬特定模型暫存器的核心軟體會產生「一般保護錯誤」，根據訪客作業系統的不同，這可能會造成系統當機。
- 用於 SCSI 磁碟的
vioscsi驅動程式會設定removable旗標，導致磁碟被視為可卸除式儲存裝置。這會導致 Windows 對受群組原則物件 (GPO) 限制的磁碟，產生非預期的存取限制，而這些 GPO 的目標是卸除式儲存裝置。
無法啟動客體代理程式
在特定負載條件下，Windows 客戶端代理程式版本 20251011.00 無法啟動。
根本原因
Windows 訪客代理程式的 20251011.00 版封裝作業，在 Windows 服務管理員中，將 Windows 訪客代理程式的啟動模式錯誤設為 auto。
解決方法
如要解決這個問題，請更新執行個體，改用客體代理程式 20251120.01 以上版本。
手動解決方法
如果無法安裝 20251120.01 版，請執行下列指令：
sc.exe config GCEAgent start=delayed-auto
如果 Windows 執行個體使用非英文語言名稱，憑證管理功能可能會失敗
Windows 客戶端代理程式會使用字串比對來識別管理員帳戶和群組。因此，只有在使用者帳戶和群組使用英文名稱時，憑證管理功能才能正常運作，例如 Administrators。如果使用非英文名稱，密碼產生或重設等憑證管理功能可能無法正常運作。
如果 C3D 機器類型搭載 180 個以上的 vCPU，Windows Server 2016 將無法啟動
如果 C3D 機器類型搭載 180 或 360 個 vCPU，Windows Server 2016 將無法開機。如要解決這個問題，請選擇下列其中一種做法：
- 如需使用 Windows Server 2016，請使用 vCPU 少於 180 個的機型。
- 如需使用具有 180 或 360 個 vCPU 的 C3D 機型，請使用較新版本的 Windows Server。
Windows Server 2025 和 Windows 11 24h2/25h2 - 暫停和繼續支援
Windows Server 2025、Windows 11 24h2 和 Windows 11 25h2 無法在暫停後繼續執行。在解決這個問題之前，Windows Server 2025、Windows 11 24h2 和 Windows 11 25h2 不支援暫停及繼續功能。
在 Windows 執行個體上使用 w32tm 測量 NTP 時間偏移時發生錯誤
如果 Compute Engine 上的 Windows 執行個體使用 VirtIO 網路介面，已知使用下列指令測量 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 執行個體。使用 gVNIC 網路介面的 Compute 執行個體不會遇到這個問題。
為避免這個問題，Google 建議使用其他 NTP 漂移測量工具，例如 Meinberg Time Server Monitor。
將運算執行個體從第 1 代或第 2 代更新為第 3 代或更新版本後，無法存取開機裝置
Windows Server 會在首次啟動時，將開機磁碟繫結至初始磁碟介面類型。如要將現有的運算執行個體從使用 SCSI 磁碟介面的舊版機器系列 (第 1 代或第 2 代)，變更為使用 NVMe 磁碟介面的新版機器系列 (第 3 代或更新版本)，請先執行 Windows PnP 驅動程式系統準備程序，再關閉運算執行個體。這個 sysprep 只會準備裝置驅動程式，並確認系統會在下次啟動時掃描所有磁碟介面類型，尋找開機磁碟。
在 PowerShell 提示中，以 Administrator 身分執行：
PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
如要變更運算執行個體的機器系列，請按照下列步驟操作：
- 停止運算執行個體。
- 編輯運算執行個體，改用新的機型。
- 啟動運算執行個體。
如果新的運算執行個體無法正常啟動，請編輯運算執行個體，改用原始的機型，然後重新啟動執行個體。完成這一連串步驟後，運算執行個體應該就能順利執行。詳閱遷移規定，確認您符合相關規定。然後重試指令。
使用 NVMe 磁碟的機器系列可附加的磁碟數量有限
使用 NVMe 磁碟介面和 Microsoft Windows OS 映像檔的運算執行個體，磁碟連結上限為 16 個磁碟。這項限制適用於 T2A 執行個體、所有第三代運算執行個體，以及 N 系列 (N4、N4D、N4A) 第四代運算執行個體。為避免發生錯誤，請將 Persistent Disk 和 Hyperdisk 儲存空間合併，每個運算執行個體最多可有 16 個磁碟。本機 SSD 儲存空間不在此問題範圍內。
更換 2022 年 5 月前建立的運算執行個體 NVME 驅動程式
如要在使用 Microsoft Windows 的運算執行個體上使用 NVMe，且該執行個體是在 2022 年 5 月 1 日前建立，則必須更新客層 OS 中的現有 NVMe 驅動程式，才能使用 Microsoft StorNVMe 驅動程式。
將機型變更為第三代或更新的機器系列，或是建立開機磁碟快照 (用於建立使用第三代或更新機器系列的新運算執行個體) 前，請務必更新運算執行個體上的 NVMe 驅動程式。
使用下列指令安裝 StorNVME 驅動程式套件，並移除客體 OS 中的社群驅動程式 (如有)。
googet update
googet install google-compute-engine-driver-nvme
在執行 Microsoft Windows 的 C3 和 C3D 執行個體上，本機 SSD 磁碟的效能較低
執行 Microsoft Windows 的 C3 和 C3D 執行個體，本機 SSD 效能會受到限制。
我們正在努力提升效能。
附加至執行 Microsoft Windows 的 n2-standard-80 執行個體時，Hyperdisk Extreme 磁碟區效能較低
執行 Microsoft Windows 的 n2-standard-80 機型運算執行個體，在附加至執行個體的所有 Hyperdisk Extreme 磁碟區中，最多可達到 80,000 IOPS。
解決方法
如要讓執行 Windows 的 N2 執行個體達到最高 160,000 IOPS，請選擇下列其中一種機器類型：
n2-highmem-80n2-highcpu-80n2-standard-96n2-highmem-96n2-highcpu-96n2-highmem-128n2-standard-128
使用 gVNIC 時網路處理量不佳
使用 gVNIC 驅動程式 GooGet 套件 1.0.0@44 版或更早版本的 Windows Server 2022 和 Windows 11 運算執行個體，在使用 Google Virtual NIC (gVNIC) 時，可能會遇到網路輸送量不佳的問題。
如要解決這個問題，請按照下列步驟，將 gVNIC 驅動程式 GooGet 套件更新至 1.0.0@45 以上版本：
如要查看運算執行個體上安裝的驅動程式版本，請在管理員命令提示字元或 Powershell 工作階段中執行下列指令：
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 映像檔
如果 C4 機型搭載超過 144 個 vCPU，或 C4D 和 C3D 機型搭載超過 180 個 vCPU，則不支援 Windows Server 2012 和 2016 OS 映像檔。使用 Windows Server 2012 和 2016 OS 映像檔的較大 C4、C4D 和 C3D 機型將無法開機。如要解決這個問題，請選取較小的機型，或使用其他 OS 映像檔。
使用 360 個 vCPU 和 Windows 作業系統映像檔建立的 C3D 執行個體將無法啟動。如要解決這個問題，請選取較小的機型，或使用其他 OS 映像檔。
如果 C4D 執行個體是使用超過 255 個 vCPU 和 Windows 2025 映像檔建立，將無法開機。如要解決這個問題，請選取較小的機型，或使用其他 OS 映像檔。
Windows Server 2016 和 2012 R2 的 M3、C3、C3D 和 C4D 執行個體發生一般磁碟錯誤
目前在特定 Windows 客戶端上，為執行中的 M3、C3、C3D 或 C4D 執行個體新增或調整 Hyperdisk 或 Persistent Disk 大小時，可能無法如預期運作。Windows Server 2012 R2 和 Windows Server 2016，以及對應的 Windows 用戶端映像檔，無法正確回應磁碟連接和磁碟大小調整指令。
舉例來說，如果您從執行中的 M3 執行個體移除磁碟，磁碟就會卸離，但 Windows 作業系統不會辨識出該磁碟已無法使用。後續寫入磁碟的作業會傳回一般錯誤。
解決方法
如果您使用在 Windows 作業系統上執行的 M3、C3、C3D 或 C4D 執行個體，並修改 Hyperdisk 或永久磁碟磁碟區，則必須重新啟動運算執行個體，系統才會辨識磁碟修改內容。