簡介圍繞VMware精簡磁盤空間回收整理的實戰(zhàn)文檔面向虛擬化運維人員、ESXi平臺使用者以及需要排查存儲容量異常的技術(shù)人員重點解決Thin磁盤在vmfs5環(huán)境下無法自動釋放空間、VMDK占用持續(xù)膨脹的問題。壓縮包共1個docx文件大小約408KB內(nèi)容以圖文步驟、命令說明和場景對比為主便于按實際環(huán)境查閱。文檔結(jié)合Windows虛擬機磁盤實際使用量與VMDK占用不一致的現(xiàn)象梳理精簡卷回收機制并對比SDelete清理空閑空間后停機執(zhí)行vmkfstools回收以及通過Storage vMotion遷移、轉(zhuǎn)換厚置備延遲歸零再遷回Thin的在線處理方式說明兩者在停機要求、目標存儲容量和操作復(fù)雜度上的差異同時給出回收后的驗證思路。已有2021人學習或下載適合需要處理存儲容量告警、優(yōu)化精簡磁盤占用并補充ESXi存儲管理經(jīng)驗的讀者參考。1. 刪了 20G 日志VMDK 一點沒瘦Thin 盤最反直覺的一幕在 Thin 精簡置備的虛擬機里刪掉一大堆日志進數(shù)據(jù)存儲一看vmdk 大小紋絲不動——這是 VMware 精簡磁盤空間回收里最經(jīng)典的一幕。我遇到的那次客戶機磁盤實際只用了 27.8GVMDK 卻實打?qū)嵳贾?36.7G中間差了將近 9G 的“幽靈空間”。vmfs5 不支持自動回收你在客戶機里刪文件只是改了文件系統(tǒng)的元數(shù)據(jù)底下的塊還掛在你賬上。這類故障不報錯、不影響業(yè)務(wù)只在存儲告警沖到 80% 的那天集中爆發(fā)折騰起來往往要停機窗口。適合所有在 ESXi 上跑 Thin 盤、被“空間去哪了”問住過的運維和開發(fā)照著后面的順序排查一遍。2. 空間為什么回收不掉vmfs5 的 UNMAP 缺口和三種假象2.1 刪文件只是改元數(shù)據(jù)塊并沒有還給存儲先把鏈路拆開看?？蛻魴C里的文件系統(tǒng)NTFS、ext4刪文件時做的是把 inode 或 MFT 記錄標記為空閑數(shù)據(jù)塊的內(nèi)容原封不動躺在磁盤上。Thin 磁盤的“瘦”依賴底層能感知哪些塊已經(jīng)沒用了客戶機告訴虛擬磁盤控制器“這塊我不要了”TRIM/UNMAPESXi 再把消息傳給 VMFSVMFS 把這部分塊標記為空閑并歸還給數(shù)據(jù)存儲。這條鏈路任何一環(huán)斷了vmdk 就只能一直胖著。vmfs5 恰恰斷在最后一環(huán)。常見的說法是 vmfs5 不把客戶機的 UNMAP 請求往下傳即使你的虛擬磁盤控制器已經(jīng)是 PVSCSI、客戶機是 Windows Server 2012 R2 及以上跑Optimize-Volume -ReTrim也是空轉(zhuǎn)。真正把自動 UNMAP 做進來的是后來的 VMFS6而且在那邊還要客戶機、虛擬硬件版本、ESXi 版本三方對齊才生效。所以在一堆還在用 vmfs5 的老環(huán)境里別指望“刪了就會自動瘦”這件事從來都得手動做。手動做的思路也不復(fù)雜既然系統(tǒng)不知道哪些塊是空閑的那就主動把空閑塊寫成明確的 0SDelete、zerofree、dd都能干vmdk 里于是出現(xiàn)大片連續(xù)的全零塊再讓 ESXi 把這些零塊“打洞”回收vmkfstools -K。零是確定值不是“未知”這就是整個回收方案能成立的物理基礎(chǔ)。理解這一點后面所有報錯你都能自己推。2.2 三種“以為回收了”的假象第一種假象最常見在客戶機里跑了一遍磁盤清理、碎片整理甚至fstrim看進度條跑完了就以為搞定。碎片整理反而更糟它會把原本空閑的塊搬來搬去可能讓 vmdk 更胖。fstrim在 vmfs5 上不會有任何下層效果命令返回成功只代表客戶機側(cè)執(zhí)行完了。第二種是看錯了指標。vSphere Client 里虛擬機磁盤有兩組數(shù)字已置備空間Provisioned和使用空間Used。Thin 盤的“已置備”是你創(chuàng)建時給的上限永遠不變“已使用”才是真正占著數(shù)據(jù)存儲的量。很多人盯著已置備空間納悶為什么不降其實應(yīng)該看的是 vmdk 文件在數(shù)據(jù)存儲里的實際落盤大小。第三種是緩存和刷新。vmkfstools -K跑完之后Client 界面上的存儲用量有延遲有人看一眼沒變就以為失敗了轉(zhuǎn)頭又跑一遍。判斷成功的唯一可靠方式是回 ESXi Shell 用ls -lh看文件大小別信界面。提示在動手之前先確認數(shù)據(jù)存儲的塊大小和 VMFS 版本。vmfs5 統(tǒng)一 1MB 塊回收粒度以 MB 計所以你刪掉幾百 KB 零碎文件基本看不到變化別為這點空間白折騰。2.3 先做決策SDelete 打洞還是 Storage vMotion擺在你面前的兩條路本質(zhì)完全不同。方法一是“客戶機清零 ESXi 打洞”只處理已刪除的空閑空間速度快、對存儲的額外占用小但要求虛擬機停機。方法二是 Storage vMotion把虛擬機整盤復(fù)制到另一個數(shù)據(jù)存儲副本按實際使用量重新落盤天然就是瘦的全程在線但要拷貝全量數(shù)據(jù)、要有第二塊存儲、動輒幾小時。我一般按這張表決策判斷維度SDelete vmkfstools -KStorage vMotion是否需要停機需要虛擬機必須關(guān)機不需要在線遷移耗時量級與空閑空間大小相關(guān)通常幾十分鐘與磁盤已用總量相關(guān)通常數(shù)小時對生產(chǎn) IO 的沖擊集中在清零階段峰值高全程持續(xù)拷貝長時間占用帶寬額外存儲需求無目標存儲需容納整機已置備容量能否順帶改磁盤格式不能能厚置備、Thin 隨你選適用場景有維護窗口、只有一塊存儲不能停機、要換存儲或改格式選錯的代價不小。有次維護窗口只留了兩小時有人選了 vMotion一個 2TB 的盤拷到一半窗口結(jié)束只能中斷白折騰。反過來只有一塊存儲、又想在線瘦身那就沒得選——先把空間騰出來再說。3. SDelete vmkfstools -K 實操從 36.7G 打回 27.8G3.1 客戶機側(cè)把空閑空間寫成零SDelete 是微軟 Sysinternals 套件里的命令行工具作用是按你指定的方式處理邏輯磁盤上的空閑空間。它需要在客戶機里跑所以先把sdelete64.exe傳進虛擬機。我習慣直接丟到C:\根目錄路徑短、不容易被權(quán)限攔住。用管理員權(quán)限打開 CMD別用普通窗口否則寫磁盤會直接失敗:: 切到工具所在目錄示例放在 C 盤根目錄 cd /d C:\ :: -z 表示把空閑空間清零這是虛擬化場景專用的模式 :: -q 關(guān)閉交互提示-nobanner 去掉啟動橫幅輸出更干凈 sdelete64.exe -z C: -q -nobanner參數(shù)上要分清-z和-c-c是清理空閑空間用隨機數(shù)據(jù)覆蓋再刪適合安全擦除-z才是清零專門喂給精簡磁盤回收用。用-c只會讓 vmdk 更胖因為隨機數(shù)據(jù)不構(gòu)成連續(xù)零塊打洞打不動。另外-p控制覆蓋遍數(shù)默認 1 遍就夠了設(shè)成 3 遍除了把清零時間拉長三倍沒有任何收益。執(zhí)行時你會看到一條進度條在跑磁盤 IO 會明顯飆高因為工具正在往每一個空閑簇里寫零。這一步對業(yè)務(wù)盤要留神如果客戶機磁盤本身已經(jīng)用到 90% 以上空閑空間沒多少跑起來很快就結(jié)束但也意味著可回收的空間本來就有限。3.2 關(guān)機與前提確認快照、鎖、格式清零跑完接下來必須關(guān)機。這一步?jīng)]有捷徑vmkfstools -K要獨占訪問 vmdk虛擬機開著就報文件占用。關(guān)機指的是完整關(guān)機Guest Shutdown 或 Power Off不是掛起掛起狀態(tài)下磁盤同樣被持有。關(guān)機后通過 SSH 登錄虛擬機所在的 ESXi 主機。ESXi 默認沒開 SSH需要在主機“服務(wù)”里臨時啟用安全 Shell用完記得關(guān)。登錄后先做三件事# 1. 進入虛擬機所在目錄路徑按實際數(shù)據(jù)存儲名替換 cd /vmfs/volumes/datastore1/your-vm # 2. 看回收前的落盤大小記下來做對比 # 第一列是占用塊數(shù)第二列是文件表觀大小 ls -ls *.vmdk # 3. 檢查有沒有快照增量盤有 -000001 這類后綴就是還有快照 ls -1 *-0000*.vmdk 2/dev/nullls -ls這個組合比單純ls -lh有用得多。第一列的塊數(shù)明顯小于“表觀大小 ÷ 512”時說明這是稀疏文件也就是 Thin兩列基本對得上說明是厚置備。這一步?jīng)Q定了后面有沒有必要打洞——厚置備盤打洞不省空間純屬浪費時間。第三條命令是重點。如果目錄里存在-000001.vmdk、-000002.vmdk之類的增量盤說明這臺機器還掛著快照。此時你清零的零塊全寫進了增量盤基礎(chǔ)盤一個字節(jié)都沒變vmkfstools -K打基礎(chǔ)盤等于白打。正確做法是先在快照管理器里刪除或合并所有快照等合并任務(wù)真正結(jié)束不是進度條消失就算完再繼續(xù)。3.3 在 ESXi 上執(zhí)行打洞并驗證確認干凈之后執(zhí)行回收命令。注意-K是大寫含義是 punch zero把全零塊還給 VMFS# 對單個 vmdk 打洞路徑寫完整別用相對路徑 vmkfstools -K /vmfs/volumes/datastore1/your-vm/your-vm.vmdk # 一臺虛擬機有多塊盤時逐個處理別圖省事用通配符 for d in /vmfs/volumes/datastore1/your-vm/*.vmdk; do echo processing $d vmkfstools -K $d done # 回收完成后核對落盤大小 ls -ls /vmfs/volumes/datastore1/your-vm/*.vmdk命令跑起來會打印進度百分比這個過程是從后往前掃描 vmdk、識別連續(xù)零塊并釋放塊數(shù)越多越慢幾十 GB 的盤通常要等十幾分鐘到半小時。中途別 CtrlC中斷不會損壞數(shù)據(jù)但會留下部分回收的狀態(tài)下次還得從頭跑?；厥胀瓿珊髮Ρ萳s -ls的第一列。開頭那個案例回收前 vmdk 占 36.7G打洞之后落到 27.8G 左右和客戶機里的實際使用量基本對齊這就算成功了。如果數(shù)字只降了一點點八成是客戶機里沒跑-z、跑的時候不是管理員、或者盤上有快照——回上一節(jié)重新確認一遍。注意vmkfstools -K只處理零塊?？蛻魴C里那些“看起來刪了但文件系統(tǒng)還標記占用”的塊它一概不認。所以順序永遠是先清零再打洞反過來做毫無意義。4. Storage vMotion 回收不停機把 Thin 盤瘦下來的第二種走法4.1 遷到厚置備延遲歸零再遷回 Thin不能停機的時候就只能走遷移這條路。原理不難理解Storage vMotion 是整盤復(fù)制目標端的 vmdk 是按源端“實際使用了多少塊”重新寫出來的那些沒被引用的空閑塊根本不會被復(fù)制過去副本天生就是瘦的。操作步驟在 vSphere Client 里完成關(guān)鍵在格式選擇上右鍵虛擬機 → 遷移 → 選擇“僅更改存儲”不要選“更改計算資源”避免順帶遷主機引入額外變量。選擇目標數(shù)據(jù)存儲確認它有足夠空間。在“選擇虛擬磁盤格式”里選厚置備延遲歸零Thick Provision Lazy Zeroed不要選“與源格式相同”。確認后提交任務(wù)等任務(wù)真正完成。如果最終還想用 Thin再做一次遷移回到原數(shù)據(jù)存儲這次格式選Thin。為什么中間要繞一次厚置備因為第一次遷移的目的是“重寫”不是“瘦身”。選厚置備延遲歸零目標端會按已用塊完整寫出跳過所有空閑塊落盤即瘦。等你確認空間已經(jīng)釋放再遷回 Thin 拿回動態(tài)擴展的靈活性。如果第一次就選 Thin行為其實也差不多但中間格式選厚置備更容易判斷“到底復(fù)制的量對不對”出問題時排查路徑更清晰。第二次遷回時有個細節(jié)目標數(shù)據(jù)存儲必須真的能容納這臺機器Thin 雖然不會立刻占滿但數(shù)據(jù)存儲剩余空間小于虛擬機已用空間時遷移會直接拒絕。4.2 硬條件目標容量、快照狀態(tài)、兼容性遷移失敗大多栽在這三件事上。容量算法是最容易誤判的一條。厚置備延遲歸零會按虛擬機的已置備容量占位不是按已使用量。一臺配了 500G 盤、實際只用 100G 的虛擬機遷到目標存儲需要 500G 可用空間不是 100G。報錯信息通常是目標數(shù)據(jù)存儲空間不足很多人第一反應(yīng)是“我明明還有 200G”問題就出在這個算法差異上。解決辦法要么先擴存儲要么在維護窗口里先用方法一把已用空間壓下去?？煺諣顟B(tài)是第二條。機器掛著快照時虛擬磁盤格式轉(zhuǎn)換常常做不了任務(wù)會失敗或者干脆不給選格式。判斷方法還是看目錄里有沒有-0000xx.vmdk。有的話先在快照管理器里合并合并任務(wù)在大盤上可能跑很久別看著進度條走完就以為結(jié)束要去任務(wù)列表確認狀態(tài)是“已完成”。兼容性排在第三?？绮煌?CPU 架構(gòu)的 ESXi 主機做遷移可能觸發(fā)兼容性檢查失敗虛擬機的虛擬硬件版本太老某些格式轉(zhuǎn)換也不支持。穩(wěn)妥的做法是先在當前主機內(nèi)部換數(shù)據(jù)存儲同主機、不同 datastore避開計算資源的兼容性問題等格式轉(zhuǎn)換完成再考慮跨主機。4.3 代價它不便宜別當成日常操作Storage vMotion 好用但代價得算清楚。它是全量復(fù)制源端要讀、目標端要寫、網(wǎng)絡(luò)上要傳三份資源同時吃。一臺 1TB 的虛擬機在普通千兆環(huán)境里跑幾個小時很正常這段時間存儲陣列的 IO 壓力會明顯上升跑在同一個數(shù)據(jù)存儲上的其他業(yè)務(wù)可能跟著變慢。更關(guān)鍵的是它不可逆地消耗了一次“全量拷貝”的額度。你今天遷一次瘦下來過兩個月客戶機里又刪了一堆文件還得再遷一次。反復(fù)遷的成本比停機做一次vmkfstools -K高得多。我的習慣是有維護窗口就老老實實用方法一把 vMotion 留給“必須在線”和“順便要換存儲”這兩種場景。5. 避坑清單五種讓回收當場翻車的情況5.1 vmkfstools 報文件被占用現(xiàn)象執(zhí)行vmkfstools -K立刻報錯退出提示無法打開磁盤、文件正在使用速度快到像是根本沒開始跑。原因虛擬機沒真正關(guān)機或者雖然關(guān)了但還有殘留進程持有 vmdk最常見的是掛起狀態(tài)、備份軟件正在做快照、或者另一臺 ESXi 主機上的控制臺還連著。解決先確認虛擬機電源狀態(tài)是“已關(guān)閉”而不是“已掛起”把 vSphere Client 和遠程控制臺全部斷開等一兩分鐘讓鎖釋放再重試。仍然報錯就去任務(wù)列表里看有沒有沒跑完的克隆或遷移任務(wù)那類任務(wù)會長期持有磁盤鎖必須等它結(jié)束或者取消掉。5.2 SDelete 跑完vmdk 反而更大了現(xiàn)象客戶機里清零順利完成回頭一看 vmdk 比之前還大幾個 G存儲用量不降反升。原因三種可能。一是這臺機器還掛著快照零塊全寫進了增量盤增量盤暴漲二是盤的格式本來就是厚置備寫零等于在已經(jīng)占滿的區(qū)域又寫了一遍三是用了-c而不是-z隨機數(shù)據(jù)不構(gòu)成連續(xù)零塊自然打不出洞。解決先看目錄里有沒有-0000xx.vmdk有就合并快照再用ls -ls判斷是不是厚置備如果是先做一次 Storage vMotion 轉(zhuǎn)成 Thin 再談回收最后確認命令里用的是-z。三條都排除才考慮是不是客戶機文件系統(tǒng)本身有大量保留塊比如啟用了去重的存儲卷那種情況清零效果會打折。5.3 Storage vMotion 報目標空間不足但明明還剩很多現(xiàn)象遷移任務(wù)剛開始就失敗提示目標數(shù)據(jù)存儲空間不夠可你在 Client 里看剩余空間還有一大截。原因厚置備延遲歸零按已置備容量占位。你的 Thin 盤實際只用了 100G但虛擬磁盤配置是 500G目標端就要 500G 可用空間。Client 顯示的“剩余空間”扣掉的是實際占用兩者口徑不一樣。解決要么把虛擬磁盤容量調(diào)小需要客戶機內(nèi)先縮分區(qū)風險高要么先把已用空間壓一壓要么換一塊更大的目標存儲。實在沒辦法就只能回到方法一用停機窗口打洞它不需要第二塊存儲。5.4 回收顯示成功數(shù)據(jù)存儲用量卻沒變現(xiàn)象vmkfstools -K跑完沒報錯ls -ls看 vmdk 也確實變小了但數(shù)據(jù)存儲的整體使用率一點沒降告警還在。原因數(shù)據(jù)存儲里除了這臺機器還有別的空間占用——快照增量盤、虛擬機交換文件.vswp、日志、以及別的虛擬機。另外 Client 界面有刷新延遲指標不是實時的。解決在 ESXi Shell 里進數(shù)據(jù)存儲根目錄用du -h -d 1 .看各個虛擬機目錄的實際占用一眼就能定位是誰在吃空間。確認是別的對象占的就別在這臺機器上繼續(xù)折騰了。如果是界面沒刷新退出重新登錄即可。5.5 Linux 客戶機上用 fstrim 完全無效現(xiàn)象客戶機是 Linux跑了fstrim -av顯示成功甚至提示釋放了多少字節(jié)回到 ESXi 一看 vmdk 沒縮。原因還是 vmfs5 那條鏈路的問題?？蛻魴C發(fā)出的 TRIM 請求在 vmfs5 上不往下傳命令返回成功只代表客戶機側(cè)執(zhí)行完了下層沒收到任何東西。解決Linux 上的等價做法是把空閑空間寫成零文件再刪掉比如dd if/dev/zero of/zero.fill bs1M寫滿后rm -f /zero.fill然后關(guān)機走vmkfstools -K。ext3/ext4 還可以用zerofree但必須把文件系統(tǒng)重新掛載為只讀才能跑生產(chǎn)機上要安排好窗口。兩種方式效果一樣選順手的那條。6. 快速定位五步確認這塊 Thin 盤到底瘦沒瘦被“空間到底回收了沒有”反復(fù)折磨過幾次之后我固化了一套五分鐘能走完的確認流程按順序做基本不會誤判。第一步看客戶機側(cè)。進虛擬機看磁盤實際使用量記下這個數(shù)字。它是你的目標值vmdk 落盤大小最終應(yīng)該貼近它而不是貼近已置備容量。第二步看 vmdk 落盤大小和格式。SSH 進 ESXicd到虛擬機目錄跑ls -ls *.vmdk。第一列是塊數(shù)明顯小于表觀大小說明是 Thin兩列接近就是厚置備厚置備盤不用考慮打洞。第三步查快照。ls -1 *-0000*.vmdk 2/dev/null有任何輸出說明還有增量盤先合并快照再做別的否則后面全是無用功。第四步查數(shù)據(jù)存儲整體占用。在數(shù)據(jù)存儲根目錄跑du -h -d 1 .看看空間是不是被別的虛擬機、交換文件或者日志吃掉了。這一步能擋掉至少三分之一的“回收失敗”誤報。第五步才動手并且在動手前后各記錄一次ls -ls的結(jié)果做對比。把常見現(xiàn)象和排查動作對應(yīng)起來這張表可以直接貼在工位上現(xiàn)象優(yōu)先懷疑一條命令vmdk 大小完全不變客戶機沒清零或盤是厚置備ls -ls *.vmdk打洞報文件被占用虛擬機未真正關(guān)機 / 有任務(wù)持鎖查看任務(wù)列表與電源狀態(tài)打洞成功但不縮存在快照增量盤ls -1 *-0000*.vmdk清零后 vmdk 反而變大用了-c而非-z或有快照檢查命令參數(shù)與快照遷移報空間不足目標按已置備容量算空間df -h對比已置備大小存儲用量始終不降空間被其他對象占用du -h -d 1 .還有一個容易被忽略的驗證動作回收完成后不要馬上重啟虛擬機先在 ESXi 側(cè)確認 vmdk 大小穩(wěn)定下來再開機進客戶機檢查文件系統(tǒng)完整性。清零過程只碰空閑塊理論上不會影響數(shù)據(jù)但我確實見過有人在客戶機沒完全關(guān)機的情況下強行打洞結(jié)果文件系統(tǒng)元數(shù)據(jù)錯亂最后只能從備份恢復(fù)。從那以后我每次做精簡磁盤回收前都強制走一遍“關(guān)機狀態(tài)確認 快照清單 回收前大小記錄”這三件事哪怕再急也不省。踩過的坑告訴我這套流程里最貴的從來不是命令本身而是漏掉一個前提條件后重來的那幾個小時。希望幫到你。本文還有配套的精品資源點擊獲取