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

posted @ 2017-05-07 11:24 D_R_Y 阅读(...) 评论(...) 编辑 收藏