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.
I have a 2003 Server with WSFU that I have been doing this since 2008. HOWEVER, I ran into a problem after “upgrading” from vSphere 4.0 to 5.1. While both Windows and vSphere show plenty of disk space, GhettoVCB/vmkfstools now throws an error that it ran out of disk space at the point where it would if there were no compression.
Originally I made the VHDs for the backups thin. I tried eagerzerodthick, but it made no difference. It runs out at the same point.
As far as speeds go, I get wildly different speeds between compression and no compression. Across a GB internet connection I get 70MB/second without compression, and about 26MB/second with compression on. The compression only uses one thread/vCPU.
One must watch logs carefully with vcbGhetto because after the backup fails, it will delete you oldest backup resulting in rotating out your good backups.
Thanks for the info, Jack. That is good to know, but bad that it happens. I’m still back on 4.1 (which is currently fine for my needs) but I’ll have to keep that in mind when I decide to upgrade. I only keep two backups in my rotation so that could really goof me up.
My backup server has been upgraded since my original post. I’ll have to check my current throughput. I’m never in front of the machine when it is running a backup (and I tend to only run them as necessary) so I haven’t paid much attention. I’ve also pulled most of the data from the vms and moved it to the openfiler vm, which gets backed up via robocopy scripts, so my vms are much smaller than in the past.
PS: I figured out why this doesn’t always work. In a nutshell, there are problems that arise when thin size of the VM is greater than ~50GB. It works for a while, but then there will be problems. You can read my post on the vSphere forum for details and links to the Microsoft article.
Thanks. I will do that. I appreciate the information.
Oops! Left off the link to the vSphere article:
http://communities.vmware.com/message/2249270#2249270
Hi guys,
I am trying to solve the exact same problem. I am going to try this windows compression solution, but can anybody explain what is actually happening here?
If we have the VM provisioned as thin, and the ghettovbc script is copying that thin file, why does it take up the full amount of space on the windows NFS share? I am just trying to wrap my head around this. Thanks