大記憶體 VM 在 vMotion 期間無回應:從 preCopyNext 與 SCSI Abort 判斷

大内存虚拟机在 vMotion 期间内存传输导致的无响应问题

問題概述與早期判斷

大記憶體 VM 在 vMotion 遷移期間,可能在記憶體傳輸階段出現週期性無回應。根據 VMware KB 427086 的說明,此問題與精細記憶體追蹤緩衝器溢出有關,可能導致應用程式不可用與效能嚴重下降。若在 vmkernel.log 中觀察到 VMotion preCopyNext 等待超過 30 秒的警告,且伴隨 PVSCSI abort 訊息,應優先懷疑此問題。

故障症狀識別

在 vMotion 記憶體傳輸期間,受影響的 VM 可能出現以下現象:

  • 應用程式無回應
  • 客戶端 I/O 命令失敗
  • 效能嚴重下降

這些症狀通常在記憶體傳輸階段週期性出現,而非持續性。若 vMotion 完成後症狀消失,更支持此判斷方向。

關鍵日誌檢查點

ESXi 主機日誌

在 /var/run/log/vmkernel.log 中,可觀察到以下訊息:

YYYY-MM-DDTHH:MM:SS.Z Wa(180) vmkwarning: cpu40:45715994)WARNING: VMotion: 1451: 8686083635737680100 S: Waited 30.315 seconds for the monitor to process a preCopyNext action. This may cause unexpected vMotion failures.

同時可能伴隨 PVSCSI SCSI ABORT 訊息:

YYYY-MM-DDTHH:MM:SS.Z In(182) vmkernel: cpu133:45716049)PVSCSI: 2769: scsi1:2: SCSI ABORT ctx=0x363

VM 日誌

在 /vmfs/volumes/<datastore>/<vm>/vmware.log 中,可看到 SCSI 中止與重置資訊:

YYYY-MM-DDTHH:MM:SS.Z In(05) vcpu-77 - PVSCSI: scsi3:2: aborting cmd 0x2dc
YYYY-MM-DDTHH:MM:SS.Z In(05) vcpu-92 - PVSCSI: scsi2:2: aborting cmd 0x37a
YYYY-MM-DDTHH:MM:SS.Z In(182) vmkernel: cpu188:45716086)VSCSI: 3473: handle 196348699146723760(GID:8624)(vscsi0:3):Reset request on FSS handle 1892843346 (0 outstanding commands) from (vmm0:)

根本原因分析

根據 KB 427086 的說明,問題的根本原因為精細記憶體追蹤緩衝器溢出。當 VM 在 vMotion 期間同時處理大量 I/O 請求時:

  1. 高 I/O 活動導致精細記憶體追蹤緩衝器溢出
  2. 系統回退至粗粒度追蹤模式
  3. 在此模式下,單一記憶體變更會標記整個大記憶體區塊為已修改,而非僅標記特定頁面
  4. 此「放大」效應大幅增加 CPU 開銷,導致系統過載與 I/O 超時

需注意,此為 KB 文件所述的機制,實際是否觸發仍取決於 VM 的記憶體大小、I/O 負載模式與主機資源狀況。來源未提供明確的記憶體門檻值。

風險評估

  • 應用程式在 vMotion 期間不可用,影響業務連續性
  • I/O 超時可能導致 vMotion 失敗,需重新嘗試,而重試可能再次觸發相同問題
  • 記憶體越大的 VM,受記憶體追蹤放大效應的影響越大,風險越高
  • 在高 I/O 負載下,症狀可能更為嚴重

版本修復狀態

根據 KB 427086,VMware 依來源 KB 的版本規劃,預計在 VCF 9.1 處理此問題,新版本將改變 vMotion 期間記憶體追蹤的實作方式,調整 vMotion 記憶體追蹤的實作。目前尚無立即修復補丁。

營運建議

對於大記憶體 VM 的 vMotion 操作,建議在低 I/O 時段執行、密切監控資源使用、評估記憶體配置是否可調整,並追蹤 VCF 9.1 的發布時程。在修復版本部署前,將大記憶體 VM 的 vMotion 視為高風險操作,納入變更管理流程中評估,避免在業務尖峰時段對高 I/O 負載的大記憶體 VM 執行遷移。

目前較安全的處理方式

  • 先以事件時間對齊 vmkernel.log、VM 的 vmware.log 與應用程式監控,確認不是一般網路、儲存或 Guest OS 問題。
  • 避免在業務尖峰或高 I/O 時段重複嘗試同一台大記憶體 VM 的 vMotion。
  • 若遷移是維護必要條件,先在同類非正式環境重現並確認可接受的停頓時間,正式操作要準備中止與回復方案。
  • 不要為了這個症狀直接把 MTU 改成 9000,也不要未經容量評估就修改 VM memory reservation、limit 或配置大小。

原文與審校說明

原文參考:大内存虚拟机在 vMotion 期间内存传输导致的无响应问题。發布版保留 KB 事件特徵與日誌,刪除直接修改 MTU、記憶體限制及未驗證 PowerCLI 腳本等高風險內容。

有VM问题需要协助?

免费试用VMware技术助理(已接Deepseek)!即时解答VM难题

→ 🤖VM技术助理

解析和诊断各类vCenter错误,ESXi日志,虚拟机vmware.log

→ 📕VMware日志分析器

图书推介 - 京东自营

24小时热门

还有更多VMware问题?

免费试下我们的VMware技术助理(已接Deepseek)!即时解答VM难题 → 🤖VM技术助理

试试 📕VMware日志分析器 ,免费诊断各类vCenter错误,ESXi日志,虚拟机vmware.log等等

########

扫码加入VM资源共享交流微信群(请备注加群):

需要协助?或者只是想技术交流一下,直接联系我们!

推荐更多

//uplcm.com/4/9119499