Here is a topic that has been discussed in great depth on the VMTN forums over the years but Roger Lund has asked me if I would post my ESX partitioning scheme. Here it is, with a bit of my reasoning which I’ve learned along the way. Enjoy!
Create the following partitions in the following order:
| Mount Point | Type | Size | Primary? | Notes |
| /boot | ext3 | 250MB | Yes | The default from VMware is 97MB. When we migrated from ESX 2.x to ESX 3.x the partition size grew from 50MB to nearly 100MB. I came up with 250MB to leave breathing room for future versions of ESX which may need an even larger /boot partition. This is all a moot point because I don’t do in place upgrades. I rebuild with new versions. |
| <swap> | 1600MB | Yes | Twice the maximum amount of allocatable service console memory. My COS memory allocation is 500MB but if I ever increase COS memory to the 800MB max in the future, I’ve already got enough swap for it without having to rebuild the box to repartition. | |
| / | ext3 | 4096MB | Yes | The default from VMware is 3.7GB. We want plenty of space for this mount point so that we do not suffer the serious consequences of running out. |
| /home | ext3 | 4096MB | Not really needed anymore and the default from VMware is that this partition no longer is created. For me this is just a carryover from the old ESX days. And disk space is fairly cheap (unless booting from SAN). I’ll put this and other custom partitioning out to pasture when I convert to ESXi where we are force fed VMware’s recommended partitioning. | |
| /tmp | ext3 | 4096MB | The default from VMware is that it doesn’t exist, rather it creates the /tmp folder under the / mount point. This is not a great idea. VMware uses a small portion of /tmp for the installation of the VirtualCenter agent but my philosophy is we should have plenty of sandbox space in /tmp for the unpacking/untarring of 3rd party utils such as HP Systems Insight Manager agents. | |
| /var | ext3 | 4096MB | The default from VMware is 1.1GB and additionally VMware makes the mount point /var/log isolating this partition strictly for VMware logs. We want plenty of space for this mount point so that we do not suffer the serious consequences of running out. In addition, we want this to be a separate mount point so as not to risk the / mount point by consuming its file system space. VMware logs and other goodies are stored on this mount point. | |
| <vmkcore> | 110MB | The default from VMware is 100MB. I got the 110MB recommendation from Ron Oglesby in his RapidApp ESX Server 3.0 Quick Start Guide (this book is a gem by the way; my copy is worn down to the nub). Although I asked Ron, he never explained to me where he came up with 110MB but let’s just assume the extra 10MB is cushion “just in case”. This is the VMKernel core dump partition. The best case scenario is you rarely if ever have a use for this partition although it is required by ESX whether it’s used by a purple screen of death (PSOD) or not. | ||
| Leave the remaining space unpartitioned. This can be partitioned as VMFS-3 later using VirtualCenter for maximum block alignment. |
Not sure how your current ESX partitions are configured? Log on to the service console (COS) and run the command vdf -h
Update: The partitioning scheme above has been superseded in a new blog entry on 1/13/09. /opt was added. Here is the link to that post.
Jason, I use 110 as if you only use 100mb and have to rebuild you will find that the 100mb partitions is in reality only 97.6 ish.
Jason,
Thanks for posting this!
Linked to this from my blog.
Roger L
http://rogerlunditblog.blogspot.com/
I always break out /var/core into its own mount point. I have had a few servers core dump, fill /var/core and cause hostd to lockup. This makes the ESX host and vms on that server un-manageable vua Virtual Center until hostd is restored. Below is the blog here I describe it a little more.
http://blog.colovirt.com/2008/10/31/vmware-esx-server-partitioning/