VMWare 回收磁盘空间

两部分内容:

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功能；做起来那叫个费劲

1. GuestOS 里需要VMWare tools eitherwipe or shrink fs。主要目的搜集free block &location. 通常要在fs级别要和fs一起。除非你一把清了磁盘不care数据

2. VMWare tools 得到结果/ metadata

3. 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