两部分内容:
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
[email protected]:/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，通过它发起回收。
[email protected]:~#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可以正常访问。然后你会发现整个磁盘基本都被占用了
[email protected]:/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
[email protected]:~$ 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