VMWare的Ubuntu (Linux)虚拟机硬盘空间压缩的正确做法(已更新)

【更新:提供一个新的思路】

思路:
添加一个新的虚拟硬盘,设置容量要比之前的大,然后用Ubuntu的安装盘iso从CD启动。利用Gparted分区工具给新的虚拟硬盘分出一个比之前分区的大一点空间的分区,然后复制就分区,粘贴到新分区。虚拟机关机后,将旧的虚拟硬盘移除,再次从CD启动,利用Boot-Repair工具修复启动。尝试重启后没有问题,就把旧的虚拟硬盘文件删除即可。
Gparted分区工具在复制粘贴分区时只读取实体的文件,但不会把分区中没有抹除的空间复制出来。这个方法就是利用这个原理来去除分区中残留的以前文件曾经停留国的空间。这个方法对付Linux类的分区格式,比如EXT4,是有效的。

参考步骤:
1、下载Ubuntu的安装盘iso。
2、新增一个虚拟硬盘,空间必须设置的比旧的大一些(比如之前是120GB,则设置为160GB),将虚拟磁盘存储为单个文件,选择SCSI,设置为独立——永久。
3、虚拟机以iso文件启动,进入Ubuntu安装界面,选择“试用Ubuntu”,进入桌面。
4、搜索Gparted,打开分区工具。给新磁盘创建分区,新分区必须比旧分区大。然后,逐一将旧磁盘的旧分区右键复制,再到新磁盘的对应新分区右键粘贴。接着就等Gparted把分区里的实体文件拷贝到新分区,指导出现本操作完成的提示。关闭GParted,再关闭虚拟机。
5、虚拟机设置,点击旧硬盘,选择移除,再次从CD启动进入Ubuntu安装界面,选择“试用Ubuntu”,进入桌面。
6、打开终端,安装并运行Boot-Repair工具
sudo add-apt-repository ppa:yannubuntu/boot-repair && sudo apt-get update
sudo apt-get install -y boot-repair && boot-repair
然后根据提示修复启动,注意此时只剩一个新的虚拟硬盘,所以修正启动的结果也就只在这个新虚拟硬盘里,这也是为何要再次CD启动的原因。Boot-Repair的使用请参考《Ubuntu 18.04 启动失败的修复方法》
7、修复启动完成后,关闭虚拟机。虚拟机设置,将CD设置的启动时连接前面的勾选去掉,接下来就是直接从硬盘启动了。
8、启动后没有问题的话,手动到虚拟机文件夹把旧的虚拟硬盘文件(vmdk文件)删除。好了,空间就这样节省出来了。

【原文如下】

VMWare下的Linux虚拟机,使用时间越长,磁盘文件(*.vmdk文件)会越来越大。清理虚拟机内文件后,还是不会减少。用VMWare自带的磁盘压缩,也不见效果。这是个Linux虚拟机的通病,经过几代VMWare版本的升级也得不到解决。

 

我有一个Ubuntu虚拟机,内部占用硬盘空间只9GB(用df -hl命令查询)左右,但是vmdk文件在29GB左右。在网上找了很久,通过自己实验,终于解决了这个困扰多时的问题。

 

解决方法:

 

1、打开Ubuntu虚拟机的终端

 

sudo su

#使用root权限

 

cat /dev/zero > zero.fill

#将占用空间却无法清理的东西转变成一个 zero.fill文件,这个过程的时间会比较长,最后出现:

cat: 写入错误: 设备上没有空间

 

rm -f zero.fill

#将这个zero.fill文件彻底删除

 

注意:在此过程中并不会增大虚拟机vmdk文件的容量,因此不用担心硬盘分区被挤爆。

 

sudo shutdown now

#关闭虚拟机

 

2、VMWare硬盘压缩

 

编辑虚拟机设置——硬件——硬盘(SATA),选择实用工具——压缩(C)

过一段时间,等压缩完毕后,将VMWare关闭。

重新打开VMWare,查看一下硬盘——容量——当前大小,应该会和虚拟机实际硬盘占用相差不大了。

 

我的Ubuntu虚拟机压缩前是29GB,压缩后仅剩8.4GB,整整回收了20GB空间。

其实,Linux虚拟机压缩按照这个方法是可靠的,不过安全起见,我在第一次做压缩操作的时候还是将整个虚拟机目录拷贝到另一个分区去做,最后确认没问题了才拷贝回来覆盖原来的目录。

猜你喜欢

转载自blog.csdn.net/stlinax/article/details/85330671