If you’ve worked with VMware View you will know that moving hundreds of desktops into your datacentre has a large storage requirement. If you haven’t seen it yet you need to look at View Composer (also this more official pdf link) and look at the way it stores each desktops changes in a delta file for that VM. I wanted to look at how the delta file grows over time as for a large pool this is the dominant storage consumer.
One of the things that I think is very important about working with linked clones is that a refresh or recompose should be a routine activity. Both a refresh and a recompose discard the changes made to the OS disk in the desktop and start from a clean state, a new delta file. Refresh is used to prevent the delta disk growth filling a datastore. Recompose is used to apply a changed master disk image to a group of desktops, often a patched and updated master, so recompose should be as frequent as critical updates. A good View Composer implementation will allow refresh and recompose without impacting user productivity. A recompose always involves a refresh, so I will only talk about refresh from here on.
I spent some time with a customer who is choosing not to refresh on a frequent basis. Due to software distribution methods a refresh will be impactful to the user, so it is to be avoided. Instead of patching the master and recomposing they are patching every desktop. Also all AV updates are done in the desktop, rather than in a master and recompose to apply or using vShield Endpoint to offload AV functions.
I wanted to assess the disk space impact of the choice not to refresh frequently, so I have setup a little test. I created a View Composer pool of one VM and left it alone for a month. The master VM is Windows 7, 2GB RAM and a 40GB OS disk, it has Office 2007 and Microsoft anti-malware along with a few other applications installed and was fully patched on the day I created the pool. To prevent my profile from making the delta grow I setup a persistent disk and to prevent temporary files causing the delta to grow I setup a disposable disk. Once the pool of one VM was created I set the VM to auto logon with my user ID and made sure it was getting updates from my WSUS server. Then I left it alone and recorded the disk usage over time.
The delta grew quite fast, exceeding 1GB within a day and continuing to grow until it was over 2GB after three weeks. For the last week the growth has slowed, only a few megabytes.
So what does this mean?
- Expect delta files to hit a gigabyte even of you refresh every day. On my normal Windows 7 pool based on the same master and refreshed on every logoff I routinely see deltas of close to 1GB.
- The first month’s growth will probably continue through the next month. The nature of NTFS is to prefer to write to empty blocks rather than overwrite deleted files. The slowing of growth will only be temporary, I expect patch Tuesday in October to drive another increase in delta size.
- Most importantly design to accommodate your decisions, test your assumptions. It looks like my delta file is going to grow at 1GB per month plus the initial 1GB. To accommodate this growth over a three month refresh I’d need to allocate 4GB per VM for delta growth, plus disposable and persistent disks and vSwap files and a little more to be safe, maybe 5GB. Given a 1GB RAM reservation the vSwap would be 1GB for the 2GB of configured RAM. The disposable could be limited to 1GB if the windows page file was kept small. This means 5GB + 1GB + 1GB = 7GB plus the persistent disk for each desktop based on what I have setup. If the storage was specified with enough capacity then there is only the operational and user impact of recompose to be considered.
I will leave my test VM running for as long as I can to test my expectation of continuing delta growth. I did have to shut it down to upgrade the ESX server it is on to vSphere 5 today, that doesn’t seem to have effected the delta size.
© 2011, Alastair. All rights reserved.
RSS - Posts