Wednesday, June 4, 2008

VMware ESX server 3.x snapshots - capacity planning

So, as we said the snapshot is really useful stuff. But when you take one you need to keep in mind a few rules which should help you to maintain it.

At first, it is useful to know the behaviour of our virtual machine. Maybe, it is growing fast one and that means the snapshot will grow fast as well. The question is how fast. Let's think about a virtual machine whose virtual disk is 10GB large. Then, its snapshot can be as large as the disk but not more. Only 10GB data can be modified. So, at worst, the virtual machine size may grow twice.

But you need to remember another thing. If you take a snapshot of virtual machine's memory (RAM) it needs some disk space as well (it has own delta file). The size of it depends, naturally, on the size of memory and assigned values to the memory reservation and limit parameters. Again, the snapshot may be as large as the size of memory but not larger. So, if you preconfigure the machine with 1GB of memory it is convenient to have 1GB of extra disk space.

How do the reservation and the limit influence it all? Everything which is beyond the reservation and below the limit and that is allocated memory by the virtual machine can be stored in the virtual machine's swapfile if there is no free physical memory available. The swapfile is, by default, stored in the virtual machine's datastore. And because the reservation, by default, has zero value the swapfile has the same size as the memory. So we need another 1GB of extra disk space. Overall, we need , theoretically, 12GB of free disk space.

Let's make some summary of rules:
  1. fast growing virtual machine means fast growing snapshot - e.g. RDBMS, SMTP servers
  2. slowly growing machines has slowly growing snapshots - e.g. firewalls
  3. snapshots can't be larger than the virtual machine's virtual disks
  4. don't forget about virtual machine's memory and swapfile
  5. don't forget about taken snapshots in the past because long time snapshot will take much more longer time to commit the changes

No comments: