兩部分內容:
1) 實際操作體驗下在vmware player里回收guest vm的磁盤空間，還給host；
2)順便把之前的筆記翻出來關於vmware unmap/reclaim, 對照總結。
1. 回收VMWare 磁盤空間
筆記本上用了VMWarePlayer 7(面向個人版本，裝在win/mac里)，里面裝了ubuntu15.Thin disk. 半年不到，幾個折騰下來發現vm占的空間就飆上去了現在要占40+GB。反思下，主要由於linuxpackage upgdate, 創建刪除dockerimage。直接后果就是本子180GB空間要耗盡。刪了vm里的無用的文件，接下來的主要問題，需要把VM瘦身磁盤空間還給本子。
嘗試player的菜單里做碎片整理-壓縮，只要回來3GB，還不夠，guest linux有38GB free
osboxes@osboxes:/media/osboxes/VMware Tools$ df -lh
Filesystem Size Used Avail Use% Mounted on
udev 568M 0 568M 0% /dev
tmpfs 116M 9.3M 107M 9% /run
/dev/sda1 48G 7.2G 38G 17% /
應該使用vmware tools從guest OS里開始下手，vwmare會把一個工具放在guest OS 里(應該是mount給guest)。需要自己去安裝下，Linux里叫vmware-toolbox-cmd，通過它發起回收。
root@osboxes:~#vmware-toolbox-cmd help disk
disk:perform disk shrink operations
Subcommands:
list: list available locations
shrink <location>: wipes and shrinks a file system at the givenlocation
shrinkonly: shrinks all disks
wipe <location>: wipes a file systemat the given location
我用的是shrink 。需要root權限，有一些限制(最好看下后面的pdf手冊，聲程不支持journalingfs: ext4/xfs/jfs， what fuck ext3就不算了? 反正我直接ext4上運行了也沒錯我提示)
1. 准備階段：主要搜集不用的guest os unused blocks(such as deleted files) . VMWare會把帶回收的空間搶占主/inflate，免得被人再分走. 48GBSSD 83%是deleted可回收； scan大概幾分鍾；期間vm可以正常訪問。然后你會發現整個磁盤基本都被占用了
osboxes@osboxes:/media/osboxes/VMware Tools$ df -lh
Filesystem Size Used Avail Use% Mounted on
udev 568M 0 568M 0% /dev
tmpfs 116M 9.3M 107M 9% /run
/dev/sda1 48G 44G 909M 99% /
2. 回收階段: 花的時間較長20來分鍾，vm沒有響應。網絡中斷
完成后，resume (就開始報錯, 被忽略。能報錯說明系統沒死...)
thin LUN. 依然顯示50GB，但大部分是hole/unprovisoing. 本子的windows已經顯示多了30+GB
osboxes@osboxes:~$ df -lh
Filesystem Size Used Avail Use% Mounted on
udev 568M 0 568M 0% /dev
tmpfs 116M 9.4M 107M 9% /run
/dev/sda1 48G 7.9G 37G 18% /
2. VMWare reclaim storage總結
主要是之前做的ppt ，
vSphere Reclaim基本到5.1之后才可用；5.0雖然開始支持但因為重大bug不推薦。在ESX 5.5 的兩種方式
1. vmkfstools–y <%free space to unmap>
- it crease a tempfile in top dir named.asyncUnmapFile. Reserved size= number *blockSize
2. esxcli storagevmfs unmap --volume-label=volume_label|--volume-uuid=volume_uuid--reclaim-unit=number
- number of VMFSblocks to UNMAP per iteration. If not specified, default value of 200.
- Run may fail or runlong time depending on #and how storage array behaves/performance
主要實現步驟(官圖):
基本思路說起來簡單：上層不用了，要通知下層: 在哪，多大，請注意回收(不是保證)；但環節很多(至少3個還不算array內部的)，細節很多 尤其是早期的layout就沒考慮shrink功能；做起來那叫個費勁
-
GuestOS 里需要VMWare tools eitherwipe or shrink fs。主要目的搜集free block &location. 通常要在fs級別要和fs一起。除非你一把清了磁盤不care數據
-
VMWare tools 得到結果/ metadata
-
vSphere 通知vmfs/sparse disk做re-org: unmap to vSCSI -> SE sparse Disk
這就要搬數據了取決於sparse/thin layout 的設計，但原則是大塊回收。Vmware的設計比較簡單而糙。
read /write to move,update sparseDisk metadata, compact, use a temp file .asyncUnmapFil. vSphere issue “shrink”when enough free at end of SE disk,
不是說糙就多壞，但很可能設計之初沒這方面的意識和考慮；最后補功課，往往事倍功半or 效果不好。怎么做都別扭的感覺。恨不得推倒重來
4. 然后VMFS級別釋放空間: by SCSI unmap or NFS-truncate
5. 最后通知后台的share storage回收空間，這樣資源才能分給其他使用者。async to reclaim,企業存儲里分層太多(sw defined精髓...)，基本上把上面的4步再來一遍。異步-攢-搬-更新metadata，IO密集, metadata load/lock/update。不是輕松的事。什么時候真正把空間回收了，還沒法細說；當然都基本做到了透明 online. 以后再需要空間時會alloc-on-demand，然后…循環。
當然，用戶操作起來基本是半/自動化, 意識不到這里面一坨苦逼的活，而且極容易出錯，影響性能。我shrink完了，guest linux隔會就開始報system detectexception. Fuck也不知道哪個筋出錯了，不過還能繼續用，那就委屈了。
新的存儲系統基本在設計之初就充分考慮thin,shrink，當然端到端的支持得配合；shrink/reclaim的效率，性能影響這得看各家的功夫，不一而足，尤其是還糾纏着snap，dedup這些share-data以及auto-balancee/rebuild/tiering之類的IO密集應用，在架構,layout方面要綜合考慮，一開始就考慮。
其他參考:
1. vmware tool手冊，linux/windows ***bsd都支持：http://www.vmware.com/pdf/vmware-tools-installation-configuration.pdf
2. 利用vMotion+vSphere 的方法：http://blogs.vmware.com/vsphere/2012/04/vaai-thin-provisioning-block-reclaimunmap-in-action.html