Compressing Windows NFS share to simulate ESXi thin provisioning
The problem
In an effort to automate backups of some of my VMWare ESXi virtual machines, I configured a Windows Services for Unix (WSFU) share as a datastore, and set up GhettoVCB to backup the machines to the share. The problem that I discovered with this approach is that WSFU does not retain the “thin” provisioning the virtual machines were built with. My example vm was a 40GB installation of Ubuntu 10.04 (highly recommended).
A solution
A solution that I arrived at was to simply enable Windows compression on the share itself. This is accomplished simply by right-clicking on the shared folder, click Advanced, check Compress contents to save disk space, then OK.
The only downside I could see with this approach (besides it being a bit kludgy) was that the backup would take longer. This would not be a big deal to me as the backups occur in the dead of night and would be complete long before I would be on the machines. The plus would be it should take up space very equivalent to that on the VMFS datastore, if not less.
The rest of the post details my observations working with the Ubuntu virtual machine.
The before numbers
The virtual machine uses 13.5GB of the provisioned 40GB. The backup took 27 minutes to complete before compression. The CPU utilization on the Windows machine hovered around 40% (this is an older, single-core).
After enabling compression
The CPU utilization was much higher during the backup with compression on. It ranged between 73 and 95%.
Surprising to me, the new job didn’t take much longer at all. The backup ran for 28.72 minutes, less than two minutes longer than the previous job, and resulted in a file size of just 8.25GB. Not a bad trade-off at all.
What I did find was strange, though, was the filesizes of two folders I had created prior to compressing. When I flipped the compression setting to on, Windows did its thing on the existing data. The folders compressed down to 7.33GB. The vmdk was exactly the same. A higher level of compression must be possible on closed files than on data being compressed on the fly. It is not a problem for me at all, it just seemed an interesting tidbit.
In summary, if you are using a WSFU storage device for your backups, turning folder compression on is definitely worth your effort.
hi mike – i have been studying this same solution that you have covered here in this and a couple other blog entries. i am curious if you have actually completed a successful restore of you ubuntu vm or any other vm that have sent to the windows nfs. i read that windows nfs is not a supported datastore but have not determined why. thanks for all your effort here.
Jason,
I have tested the restore two ways, both successful. The first was to remove the existing Ubtuntu 10.04 from inventory, rename it on the local datastore, and then copy over the backup from the NFS datastore. I added it into the inventory and started it up. Worked perfectly.
The other method, which I just tested again, was to also remove it from inventory, but then I browsed the NFS datastore for the .vmx file of Ubuntu 10.04. I added it into inventory and started it up. VMware did ask if it was a copy to which I answered yes (the default), and then it started the vm up. It was initially a little slower to start up from this compressed Windows datastore but it ran well enough.
I wouldn’t want to run my vms directly from this compressed NFS Windows datastore, but it certainly works well for my needs. It is also only using 148GB of disk space for nearly 500GB of backups.
impressive. thanks for your input. based on that i feel compfortable in proceeding.
i run vm’s off iscsi but have not tried nfs before. this will work well for a dr plan. amazing what we can do now days!
thanks again…
and yes one more question…. when you formatted the drive for your nfs, did you use the defaults or did you specify a block configuration?
I just took the default.