So I talked about using /var instead of /var/log for you standard ESX deployment… Still I see people do lots of weird things, these are my recommendation for esx partitioning:
Primary:
/boot - 250MB
/ - 5120MB
Swap - 1600MB
Extended Partition:
/var - 4096MB
/home - 2048MB
/opt - 2048MB
/tmp - 2048MB
VMKcore - 100MB
VMFS - Fillup, but leave atleast 5GB for additional partitions in the future as Bouke and Eric suggest below!
This will take up around 18GB of the 36GB you have these days as a minimum. And you’ll avoid filling up your root file system with log files, core dumps or temporary files. Start using it if you’re not doing it…
And if you did manage to fill up your root file system use this command from the COS to find any files larger than 10MB:
find –type f –size +10240k
Eric Sloof says
Shouldn’t you fill up VMFS with half of what’s free so you can always add an additional partition?
Wade Holmes says
Hi Duncan,
I have a question/comment. Doesn’t VMFS created during install lack proper disk geometry alignment, while VMFS created through VC is properly aligned? Would this make it prudent to wait to create VMFS partitions later through Virtual Center?
Bouke Groenescheij says
I agree with Eric Sloof on this one: I always tend to have some free space at the end. This can be used for multiple purposes: make more VMFS or more EXT3. Great article!
Justin says
We do something very similar, but a little larger on /, /var, and /tmp and no /opt or /home. I have yet to come across any reason to need additional VMFS partitions (which you wouldn’t need if you had filled the drive the first time), or additional ext3 partitions on the local storage of my ESX hosts.
Gabrie van Zanten says
Hi
I would create a much larger tmp partition, maybe 10 or 20Gb instead of 2Gb. I remember the upgrade package from ESX Server 3.0.x to ESX Server 3.5 Update 2 Refresh being 1.9Gb. Although normally I would rather reinstall.
Gabrie
Hany says
i’m wondering of there is any official documentation/recommendation from VMware regarding this? perhaps with a table referenced to the amount of memory (e.g. 8GB, 16GB, 64GB ..etc.) and/or the approximate number of running VMs on the ESX host ..
this ESX partitioning part has been always inconsistent in terms of best practices or recommendations.
Keith says
Good stuff keep the articles coming 🙂
we setup as below; has worked well thus far
/boot = default
/ = 5120
swap=1600
/var=5120
/tmp=5120
/home=2048
/vmkcore=100
/vmfs = rest
Leo Raikhman says
Hi,
/opt is redundant as of ESX 3.5 – the partitioning scheme from 3.0 no longer applies as AAM (HA) now logs to /var/log, not to /opt, negating the need for a /opt partition.
Otherwise, I’m very similar.
Cheers,
Leo
michael says
#
Wade Holmes
October 23rd, 2008 at 21:38
Hi Duncan,
I have a question/comment. Doesn’t VMFS created during install lack proper disk geometry alignment, while VMFS created through VC is properly aligned? Would this make it prudent to wait to create VMFS partitions later through Virtual Center?
can anyone answer this question?
Duncan says
huh, i typed a reaction this morning and it’s gone…
/opt = will also be used by other 3rd party agents.
@eric / bouke , you are right… might be useful to leave at least 5GB unpartitioned
@wade, well the alignment… how many people actually align their vm’s? that’s right not many. anyway I don’t think one should actively use their local vmfs. so you can wait for VC that’s fine with me. Would create a better aligned disk indeed.
@hany there are no official statements except for the best practices on partnet centrals and my best practice is close to that one…
@gabrie I never do upgrade packages, I always use the CD or update manager. don’t see the point in creating 20GB /tmp partitions, well maybe if you’ve got 76Gb than having 10 extra in temp… otherwise…
GregW says
One observation, some good sizing info here ; but ; when you come to running something like vm-support (to collect logs) depending on your hosts and how long they have been up / running / usage ect ect – some of these partition sizes may not work out too well.
scorelord says
I’d recommend to use the vmreference recommendation. http://www.vmreference.com/vi3-card/
Never used /var though. Always used var/log… Why would one need to use /var only?
Duncan Epping says
you need to use /var cause the service console core dumps are stored in /var/core. if you would use /var/log you could end up with core dumps filling your /.
George says
I thought the core dumps are store in VMKcore partition…
Duncan says
The name actually reveals what it stores “VMKcore”, VMKernel…
George says
Then , that trainer in the VI3 I&C had no clue about ESX… Thanks!
George says
But the official documentation says:
vmkcore – A vmkcore partition is required to store core dumps for
troubleshooting. VMware does not support ESX Server host configurations
without a vmkcore partition
Install Guide , page 91
I’m getting confused…
Duncan Epping says
George,
the vmkcore partition is used to store the core dumps generated by the vmkernel. the /var/core directory is used to store the coredumps generated by the service console, which is red hat.
George says
Got it. Thanks Duncan. By the way, your site rocks!!
teaphe says
how do I create the vmkcore and vmfs partition during the installation of ESX or in VC? co’z I can’t find a vmfs and vmkcore file system during the installation of ESX.
THanks.
dogcanterbury says
IMHO I think if the infrastructure is shared storage, there is no point creating a vmfs partition. think not?
Duncan says
If you are running 3.5 and doing boot from SAN. No there’s no point indeed.
but if you are running 4.0 the Service Console is a VMDK so you will need VMFS to boot it from.
Sid Smith says
What about environments that are moving to vSphere and are utilizing the local VMFS for VMs or vSWP files. In this case I would recommend having two separate VMFS partitions on the local storage. One for the Service Console vmdk, and one for everything else be it vSWP or VM’s. Any thoughts on that?
Duncan says
I totally agree, I would actually always have two seperate partitions just in case you ever need it for testing or whatever.
Sid Smith says
The only caveat with deploying multiple VMFS partitions is you need to perform a scripted installation in order to achieve this….as far as I can see. However I think all installations should be scripted anyway…..
chad king says
So what should one do if they dont have availible space and cannot free it up. I know for windows I used paragon for disk-resizing partitioning. Is there anything like this in Linux that we could do? I.E. someone needs to update ESX and they cant because of the spacing issue?