已知問題

本頁面說明使用 Compute Engine 執行個體時可能遇到的已知問題。如要瞭解專門影響 Confidential VM 的問題，請參閱「Confidential VM 限制」。

一般問題

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

訪客代理程式會忽略 NetworkInterfaces 設定中的 ip_forwarding 選項

訪客代理程式 NetworkInterfaces 設定區段包含 ip_forwarding 選項。您可以使用這個選項，防止代理程式從中繼資料伺服器 (MDS) 安裝別名 IP 位址和 IP 轉送路徑。不過，如果客體代理程式版本使用外掛程式架構 (包括核心外掛程式)，代理程式會忽略 ip_forwarding 設定選項。無論設定為何，訪客代理程式都會安裝別名 IP 位址和 IP 轉送路徑。詳情請參閱訪客代理程式說明文件。如果您在設定中使用 SAP Netweaver Pacemaker，並搭配內部負載平衡器 (ILB)，就會受到這個問題影響。

如要緩解這個問題，請按照回溯相容性說明文件的指示，將中繼資料屬性 enable-guest-agent-core-plugin 設為 false。

啟用安全啟動功能的運算執行個體可能無法啟動

在極少數情況下，如果 Shielded VM 執行個體是在 2025 年 11 月 7 日前建立，且已啟用安全啟動功能，或使用全磁碟加密軟體或將密鑰密封至 vTPM PCR，則可能無法啟動。這可能是因為 Microsoft 安全啟動憑證在 2026 年下半年到期後，更新順序不正確 (例如在沒有適當憑證的情況下更新 shim)。

解析度

如要解決這個問題，請使用新憑證更新運算執行個體。詳情請參閱「Microsoft 安全啟動憑證到期指南」。

如果停電，連接至 C4、C4A、C4D、C4N 和 H4D 執行個體的本機 SSD 磁碟可能無法擷取所有寫入作業

主機伺服器斷電後，如果 Compute Engine 可以復原本機 SSD 磁碟上的資料，在該主機伺服器上執行的運算執行個體就會重新啟動，並連接所有磁碟，資料則會包含主機發生錯誤前完成的所有寫入作業。

如果是 C4、C4A、C4D、C4N 和 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) 配額。

如果 Persistent Disk 配額限制低於 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 執行個體會使用這類 GPU。這些問題可能會導致工作負載中斷，例如 nvidia-smi 指令沒有回應。如果發現 A4 VM 的工作負載中斷，請確認是否符合下列任一條件：

• VM 的運作時間 (lastStartTimestamp) 超過 65 天。
• 記錄顯示 提及 0x02a 的 Xid 149 訊息。

如果符合上述任一條件，就必須重設 A4 VM 附加的 GPU。為避免日後因韌體問題而中斷工作負載，建議您至少每 60 天重設一次 GPU。詳情請參閱「重設 GPU」。

注意：如果 A4 VM 屬於 GKE 叢集，您可以使用 GKE GPU 節點重設工具解決輕微的 GPU 問題，例如 nvidia-smi 指令沒有回應，而不必重新啟動 VM。

在單一租戶節點上建立 C4 執行個體時，可能發生主機錯誤

在單一租戶節點上執行的 C4 機型執行個體，可能會因主機錯誤或執行個體建立失敗，而意外終止。

為解決這個問題，Google 已將每個單一租戶節點允許的 C4 執行個體數量上限限制為 20 個。

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 參數：

  警告：如果您完成這些步驟，但未將 Cluster Toolkit 更新至 1.65.0 以上版本，則使用 gcluster deploy 指令重新部署叢集時，這些手動變更會遭到覆寫。

  1. 使用 SSH 連線至叢集的主要控制器節點。

     gcloud compute ssh --project PROJECT_ID --zone ZONE DEPLOYMENT_NAME-controller
     

     如要找出主要控制器節點的確切名稱和 IP 位址，請使用 Google Cloud 控制台，並前往「VM instances」(VM 執行個體) 頁面。

  2. 建立目前 cloud.conf 檔案的備份。這個檔案通常位於 /etc/slurm/。

     sudo cp /etc/slurm/cloud.conf /etc/slurm/cloud.conf.backup-$(date +%Y%m%d)
     

  3. 使用 sudo 權限，透過文字編輯器開啟檔案 /etc/slurm/cloud.conf。

  4. 新增或修改包含 UnkillableStepTimeout 的行。例如，將逾時時間設為 900 秒 (15 分鐘)，如下所示：

     UnkillableStepTimeout=900
     

  5. 儲存檔案。

     注意：Cluster Toolkit 部署作業通常會從控制器節點設定 NFS 共用，用於 /etc/slurm 和 /home 等目錄。這項設定表示，在控制器節點上對 cloud.conf 所做的任何變更，都會自動顯示在所有運算節點上。

  6. 使用 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 機型預留資源，請改為執行下列任一操作：

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

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

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

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

搭配 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-*-lssd
• c4-highmem-*-lssd
• c3-standard-*-lssd
• c3d-standard-*-lssd

C3D 執行個體的單一串流 TCP 處理量變化

如果 C3D 執行個體有超過 30 個 vCPU，單一串流 TCP 處理量可能會不穩定，有時會限制在 20 到 25 Gbps。如要達到更高的速率，請使用多個 TCP 流量。

如果運算執行個體每個核心使用一個執行緒，CPU 使用率觀測能力指標會不正確

如果運算執行個體的 CPU 每個核心使用一個執行緒，則在 Compute Engine Google Cloud 控制台「VM instances」(VM 執行個體) 頁面的「Observability」(觀測能力)* 分頁中，CPU 使用率 Cloud Monitoring 指標只會調整至 50%。大多數機器類型的預設值為每個核心兩個執行緒。詳情請參閱「設定每個核心的執行緒數量」。

如要查看運算執行個體的 CPU 使用率 (正規化為 100%)，請改為在 Metrics Explorer 中查看 CPU 使用率。詳情請參閱「使用 Metrics Explorer 建立圖表」。

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

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

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

• 啟用 TCP 適用的 Identity-Aware Proxy，繼續使用瀏覽器中的 SSHGoogle Cloud 控制台功能連線至運算執行個體。

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

• 使用 Google Cloud CLI 連線至運算執行個體，而非瀏覽器中的 SSH。

磁碟的臨時名稱

使用 gcloud compute instances update 指令或 instances.update API 方法更新運算執行個體時，Compute Engine 可能會暫時變更運算執行個體磁碟的名稱，在原始名稱中加入下列任一後置字串：

• -temp
• -old
• -new

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

因調整磁碟大小，導致部分 Persistent Disk 延遲時間增加

在某些情況下，調整大型永久磁碟 (約 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 以下。您必須為所有區域中，具有資源型承諾使用合約的所有專案設定配額上限。您可以透過下列任一方式執行這項操作：

  • 請按照申請調整配額的相同步驟操作，並要求降低配額限制。
  • 建立配額覆寫。

注意：設定配額上限只是暫時的解決方法，您仍須修正 compute.regions.list 方法的 items[].quotas[].limit 欄位定義，並將其變更為 number 類型。如要將承諾使用 SKU 的預設配額限制改回無限制，請移除配額限制上限。

GPU 執行個體的已知問題

以下各節說明 Compute Engine GPU 執行個體的已知問題。

加速器最佳化機型會自動連接本機 SSD 磁碟，可能需要數小時才能終止並重新啟動

加速器最佳化機型會自動連接 GPU。除了 A2 標準型以外，大多數 A 系列加速器最佳化機型都會自動連接本機 SSD 磁碟。

加速器最佳化機型不支援即時遷移，您必須將主機維護政策設為 TERMINATE。發生故障或主機錯誤後，這些機器類型最多可能需要一小時才會終止。如果加速器最佳化機型會自動連接本機 SSD 磁碟，終止程序可能需要數小時。

搭配 GPU 執行個體使用 Dynamic NIC 時，發生建立錯誤和效能降低

Dynamic 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 裸機執行個體的已知問題。

手動啟動主機維護作業不適用於 X4 執行個體

如果是 X4 執行個體，手動啟動主機維護事件中說明的程序不適用。

解決方法

1. 停止 X4 執行個體。
2. 執行個體狀態變更為 TERMINATED 後，啟動 X4 執行個體。

如要瞭解如何停止或重新啟動 X4 執行個體，請參閱「停止或重新啟動 Compute Engine 執行個體」。

C4D 裸機機型不支援 SUSE Linux 15 SP6 映像檔

C4D 裸機執行個體無法執行 SUSE Linux Enterprise Server (SLES) 15 SP6 版 OS。

解決方法

請改用 SLES 15 SP5。

模擬主機維護作業不適用於 C4 Bare Metal 執行個體

c4-standard-288-metal 和 c4-highmem-288-metal 機器類型不支援模擬主機維護事件。

解決方法

使用以其他 C4 機型建立的虛擬機器 (VM) 執行個體，模擬維護作業。

1. 使用結尾不是 -metal 的 C4 機型建立 VM 執行個體。

   建立 VM 時，請將 C4 執行個體設為 Terminate，而非在主機維護事件期間使用即時遷移。

2. 模擬這個 VM 的主機維護事件。

在模擬主機維護事件期間，設為 Terminate 的 VM 行為與 C4 裸機執行個體相同。

在 RHEL 8 上使用 Z3 裸機執行個體時，成效低於預期

使用 Red Hat Enterprise Linux (RHEL) 第 8 版搭配 Z3 裸機執行個體時，網路效能低於預期。

根本原因

RHEL 8 使用的 Linux 核心版本 (4.18) 缺少 Page Pool 功能。

解決方法

使用 Z3 裸機執行個體時，請使用較新版本的 RHEL 或其他作業系統。

使用 Dynamic Network Interface 的相關問題

本節說明使用多個網路介面和 Dynamic Network Interface 的相關已知問題。

使用 Dynamic NIC 搭配別名 IP 範圍、通訊協定轉送或直通式網路負載平衡器時，封包遭到捨棄

在下列情況下，訪客代理程式會自動為 vNIC 新增本機路由，但不會為 Dynamic NIC 新增：

• 設定別名 IP 範圍時，訪客代理程式會為別名 IP 範圍建立本機路由。
• 建立目標執行個體，並參照用於通訊協定轉送的運算執行個體時，訪客代理程式會為相關聯的轉送規則 IP 位址建立本機路由。
• 將後端新增至直通式網路負載平衡器時，訪客代理程式會為相關聯的轉送規則 IP 位址建立本機路由。

由於系統不會為動態 NIC 新增本機路由，因此動態 NIC 可能會捨棄封包。

如要解決這個問題，請按照下列步驟手動新增 IP 位址：

1. 使用 SSH 連線至執行個體。

2. 如要設定別名 IP 範圍，請按照下列步驟操作。您也可以略過這個步驟。

   1. 在 /etc/default/instance_configs.cfg 中，確認 ip_aliases 設定已設為 true。

   2. 如果 ip_aliases 設定設為 false，請修改檔案，將其變更為 true，然後重新啟動客體代理程式：

      systemctl restart google-guest-agent
      

3. 使用下列指令，為別名 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 版的訪客代理程式中，安裝及管理 Dynamic NIC 時發生問題

如果您設定自動管理 Dynamic NIC，且執行個體執行的訪客代理程式版本介於 20250901.00 至 20251120.01 之間，可能會遇到下列問題：

• 訪客代理程式無法在執行個體的訪客 OS 中安裝及管理 Dynamic NIC。

  在客體 OS 中執行參照動態 NIC 的指令時，可能會收到包含 Cannot find device 的錯誤訊息。

• 刪除多個動態 NIC 會導致無法存取中繼資料伺服器。

根本原因

自 20250901.00 版起，訪客代理程式已遷移至新的外掛程式架構，以提升模組化程度。新架構一開始不支援自動安裝及管理 Dynamic NIC。

解析度

如要解決這些問題，請更新執行個體，改用 20251205.00 以上版本的訪客代理程式：

1. 如要將客體代理程式更新至最新版本，請參閱「更新客體環境」。
2. 如要確認執行個體執行的訪客代理程式版本，請參閱「依作業系統版本查看已安裝的套件」。

如有需要，您可以暫時解決這些問題，方法是按照「回溯相容性」一節的操作說明，將執行 20250901.00 至 20251120.01 版訪客代理程式的執行個體，還原至先前的訪客代理程式架構。

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

使用動態 NIC 時，封包攔截可能會導致封包遺失。如果管道提前終止，封包可能會遭到捨棄。這個問題會影響工作階段模式和非工作階段模式。

根本原因

在封包攔截期間，如果管道提早終止 (輸入攔截和輸出重新插入)，就會發生封包捨棄。提早終止會導致輸入封包的乙太網路標頭缺少 VLAN ID。由於輸出封包衍生自修改後的輸入封包，因此輸出封包也缺少 VLAN ID。這會導致端點索引選取錯誤，以及後續封包捨棄。

解決方法

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

運算執行個體位於多個執行個體群組時，Dynamic NIC 作業會失敗

如果您新增或刪除 Dynamic NIC，而作業卡在 RUNNING 狀態，進度為 0%，最後失敗並顯示 INTERNAL_ERROR，這可能是因為運算執行個體位於多個執行個體群組 (代管或非代管)。

如要完成作業，請從所有執行個體群組中移除執行個體，只保留一個。您可以從代管執行個體群組中移除執行個體，或從非代管執行個體群組中移除執行個體。

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)

根本原因

3.20 之前的 DOCA OFED 版本與 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

如果 VM 執行個體使用的 Debian 11 映像檔版本早於 v20250728，則無法執行 apt update

2025 年 7 月 22 日，Debian 社群從主要的 Debian 上游移除 Debian 11 (Bullseye) 反向移植。這項更新會導致 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 的預設「轉譯器」。具體來說，它會在 /usr/lib/netplan/00-network-manager-all.yaml 插入 netplan 的新 YAML 設定，其中包含以下內容：

network:
  version: 2
  renderer: NetworkManager

這項設定與我們使用 cloud-init 的 networkd 早期佈建功能衝突。

復原

如果運算執行個體已重新啟動，但無法存取，請按照下列步驟操作：

1. 按照救援運算執行個體的指示操作。

2. 掛接無法存取的運算執行個體 Linux 檔案系統分區後，請執行下列指令 (將 /rescue 替換為掛接點)：

   echo -e 'network:\n  version: 2\n  renderer: networkd' | sudo tee /rescue/etc/netplan/99-gce-renderer.yaml
   

3. 繼續重新啟動無法存取的運算執行個體。

使用 Ubuntu OS 20250530 版的運算執行個體顯示錯誤的 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. 修改網路名稱解析設定檔 /etc/systemd/resolved.conf.d/gce-resolved.conf，將 Domains=local 變更為 Domains=~local
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
   

openSUSE 映像檔缺少 mkfs.ext4

2025 年 8 月起，最近發布的 v20250724 openSUSE 映像檔 (從 opensuse-leap-15-6-v20250724-x86-64 開始) 缺少 e2fsprogs 套件，該套件提供管理檔案系統的公用程式。這個問題的常見症狀是，當您嘗試使用 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 必須包含特定模組。如果將缺少這些 NVMe 模組的 initramfs 系統遷移至 C3 執行個體，啟動程序就會失敗。這個問題也可能影響其他有獨特硬體需求的執行個體類型。

解決方法

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

dracut --force --no-hostonly

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

dracut -f --no-hostonly

Z3 上搭載 SUSE 12 映像檔的本機 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 就不支援停用可預測的網路介面名稱。

解析度

在問題解決之前，您可以停止並啟動運算執行個體，藉此還原網路連線。如要避免網路連線再次中斷，請採取下列做法：

1. 編輯 /etc/default/grub 檔案，並移除核心參數 net.ifnames=0 和 biosdevname=0。

2. 重新產生 grub 設定。

3. 重新啟動運算執行個體。

無法驗證 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 檔案。不過，您的運算執行個體可以在不同的存放區設定檔或自動化工具中設定這項設定。

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 執行個體的已知問題

• 使用社群 NVMe 驅動程式在 Windows 上支援 NVMe 的功能目前為Beta 版，效能可能與 Linux 執行個體不一致。 Google Cloud 公開映像檔中的社群 NVMe 驅動程式已替換為 Microsoft StorNVMe 驅動程式。建議您更換 2022 年 5 月前建立的運算執行個體 NVME 驅動程式，改用 Microsoft StorNVMe 驅動程式。
• 在建立執行個體後，您無法立即連線至該執行個體。全新的 Windows 執行個體會使用系統準備 (sysprep) 工具來設定執行個體，這可能需要 5 至 10 分鐘才能完成。
• Windows Server 映像檔必須連上 kms.windows.googlecloud.com 網路連線才能啟用，如果未在 30 天內完成初始驗證，就會停止運作。由 KMS 啟用的軟體必須每 180 天重新啟用一次，但 KMS 每 7 天就會嘗試重新啟用一次。請務必設定 Windows 運算執行個體，確保執行個體保持啟用狀態。
• 存取非模擬特定模型暫存器的核心軟體會產生「一般保護錯誤」，根據訪客作業系統的不同，這可能會造成系統當機。
• vioscsi 驅動程式用於 SCSI 磁碟，會設定 removable 旗標，導致磁碟被視為卸除式儲存空間。這會導致 Windows 意外限制存取受群組原則物件 (GPO) 限制的磁碟，而這些 GPO 是針對抽取式儲存裝置。

在 Windows Server 2012 R2 和更早版本中，無法啟動訪客代理程式

在執行舊版 Windows 作業系統 (例如 Windows Server 2012 R2、Windows Server 2012 或 Windows Server 2008 R2) 的執行個體上更新客體代理程式套件後，如果手動執行二進位檔，系統會顯示錯誤訊息，指出無法辨識二進位檔。

自 Go 1.21 起，上游 Go (Golang) 不再支援 Windows Server 2012 R2 和更早版本。使用 Go 1.21 以上版本建構的訪客代理程式發布子版本無法在這些作業系統上執行。

解決方法

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

• 升級作業系統：將 VM 執行個體升級至支援的版本，例如 Windows Server 2016 以上版本。詳情請參閱「Windows 終止支援」。

• 還原至先前的訪客代理程式版本：如果必須繼續執行 Windows Server 2012 R2 或更早版本，請從其他執行中的運算執行個體或快照，重新安裝相容的訪客代理程式套件：

  1. 在運作中的運算執行個體上，檢查 google-compute-engine-windows 和 google-compute-engine-metadata-scripts 套件的版本。
  2. 前往 Googet 快取目錄 C:\ProgramData\Googet\cache\` and copy the.goo` 檔案，將上述套件複製到損壞的 VM。
  3. 在損壞的 VM 上，使用 googet install -reinstall PACKAGE_NAME.goo 逐一安裝複製的套件。

• 為避免訪客代理程式更新至不相容的版本，請停用訪客代理程式的自動更新功能。

訪客代理程式無法啟動

在特定負載條件下，Windows 訪客代理程式版本 20251011.00 無法啟動。

根本原因 Windows 訪客代理程式套件版本 20251011.00 錯誤地將 Windows 訪客代理程式的啟動模式設為 Windows 服務管理員上的 auto。

解決方法 如要解決這個問題，請將執行個體更新為使用 20251120.01 以上版本的訪客代理程式。

手動解決方法 如果無法安裝 20251120.01 版，請執行下列指令：

• sc.exe config GCEAgent start=delayed-auto

使用非英文名稱的 Windows 執行個體可能無法使用憑證管理功能

Windows 訪客代理程式會使用字串比對，識別管理員帳戶和群組。因此，只有在使用英文名稱命名使用者帳戶和群組 (例如 Administrators) 時，憑證管理功能才能正常運作。如果使用非英文名稱，憑證管理功能 (例如產生或重設密碼) 可能無法正常運作。

Windows Server 2016 無法在 vCPU 數量達 180 個以上的 C3D 機型上啟動

Windows Server 2016 無法在具有 180 或 360 個 vCPU 的 C3D 機型上啟動。如要解決這個問題，請選擇下列其中一種做法：

• 如需使用 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 上使用 VirtIO 網路介面的 Windows 執行個體，有一個已知錯誤，即使用下列指令測量 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 網路介面的運算執行個體不會發生這個問題。

為避免這個問題，Google 建議使用其他 NTP 漂移測量工具，例如 Meinberg Time Server Monitor。

將運算執行個體從第 1 代或第 2 代更新為第 3 代或更新版本後，無法存取開機裝置

Windows Server 會在首次啟動時，將開機磁碟繫結至初始磁碟介面類型。如要將現有的運算執行個體從使用 SCSI 磁碟介面的舊版機器系列 (第 1 代或第 2 代) 變更為使用 NVMe 磁碟介面的新版機器系列 (第 3 代或更新版本)，請先執行 Windows PnP 驅動程式 sysprep，再關閉運算執行個體。這個 sysprep 只會準備裝置驅動程式，並確認下次啟動時，系統會掃描所有磁碟介面類型，找出開機磁碟。

在 PowerShell 提示中，以 Administrator 身分執行：

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

如要變更運算執行個體的機器系列，請按照下列步驟操作：

1. 停止運算執行個體。
2. 編輯運算執行個體，改用新的機型。
3. 啟動運算執行個體。

如果新的運算執行個體無法正常啟動，請編輯運算執行個體，改用原始機器類型，然後重新啟動執行個體。完成這些步驟後，運算執行個體應會成功執行。請詳閱遷移規定，確認您符合這些規定。然後再次按照操作說明操作。

使用 NVMe 磁碟的機器系列，可連接的磁碟數量有限

如果運算執行個體使用 NVMe 磁碟介面和 Microsoft Windows OS 映像檔，則特定機器系列的磁碟連接限制為 16 個磁碟。這項限制適用於 N4、C3、C3D 和 M3 機器系列。

使用相容的 NVMe 驅動程式 (例如 Microsoft StorNVMe 驅動程式) 時，C4、C4D、N4D 和 M4 等機器系列支援超過 16 個磁碟。

這項限制不適用於本機 SSD 儲存空間。為避免發生錯誤，請將受影響機器系列的 Persistent Disk 和 Hyperdisk 儲存空間合併，每個運算執行個體最多 16 個磁碟。

替換 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 磁碟區的效能較低

以 n2-standard-80 機型為基礎、執行 Microsoft Windows 的運算執行個體，在所有附加至執行個體的 Hyperdisk Extreme 磁碟區中，最多可達到 80,000 IOPS。

解析度

如要讓執行 Windows 的 N2 執行個體達到 160,000 IOPS，請選擇下列其中一種機型：

• n2-highmem-80
• n2-highcpu-80
• n2-standard-96
• n2-highmem-96
• n2-highcpu-96
• n2-highmem-128
• n2-standard-128

使用 gVNIC 時網路處理量不佳

如果 Windows Server 2022 和 Windows 11 運算執行個體使用 gVNIC 驅動程式 GooGet 套件 1.0.0@44 以下版本，則透過 Google Virtual NIC (gVNIC) 傳輸資料時，網路處理量可能會降低。

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

1. 請在管理員命令提示字元或 Powershell 工作階段中執行下列指令，確認運算執行個體安裝的驅動程式版本：

   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 Package Repository：

   googet update
   

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

vCPU 數量超過 144 個的 C4 機型，以及 vCPU 數量超過 180 個的 C4D 和 C3D 機型，不支援 Windows Server 2012 和 2016 OS 映像檔。使用 Windows Server 2012 和 2016 OS 映像檔的大型 C4、C4D 和 C3D 機型將無法啟動。如要解決這個問題，請選取較小的機型，或使用其他 OS 映像檔。

使用 360 個 vCPU 和 Windows OS 映像檔建立的 C3D 執行個體將無法啟動。如要解決這個問題，請選取較小的機型，或使用其他 OS 映像檔。

如果 C4D 執行個體是使用超過 255 個 vCPU 和 Windows 2025 映像檔建立，則無法啟動。如要解決這個問題，請選取較小的機型，或使用其他 OS 映像檔。

Windows Server 2016 和 2012 R2 上的 M3、C3、C3D 和 C4D 執行個體發生一般磁碟錯誤

警告：系統已不再支援 Windows Server 2012 R2，不建議使用。升級至支援的 Windows Server 版本。

目前在特定 Windows 訪客上，無法正常為執行中的 M3、C3、C3D 或 C4D 執行個體新增 Hyperdisk 或 Persistent Disk，或調整其大小。Windows Server 2012 R2 和 Windows Server 2016，以及其對應的 Windows 用戶端映像檔，無法正確回應磁碟連接和磁碟大小調整指令。

舉例來說，如果您從執行中的 M3 執行個體移除磁碟，磁碟會卸載，但 Windows 作業系統不會辨識出磁碟已無法使用。後續寫入磁碟時，會傳回一般錯誤。

解析度

如果您使用在 Windows 作業系統上執行的 M3、C3、C3D 或 C4D 執行個體，並修改 Hyperdisk 或 Persistent Disk 磁碟區，則必須重新啟動運算執行個體，系統才能辨識磁碟修改。