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
vSphere 4.0 Quick Start Guide
Shouldn’t you fill up VMFS with half of what’s free so you can always add an additional partition?
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?
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!
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.
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
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.
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
[...] a lost art form in ESXi Written by jason on October 24, 2008 – 1:19 am – On the heels of Duncan Epping’s blog article about ESX partitioning best practices comes my first look at the automatic partitioning in [...]
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
#
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?
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…
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.
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?
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 /.
I thought the core dumps are store in VMKcore partition…
The name actually reveals what it stores “VMKcore”, VMKernel…
Then , that trainer in the VI3 I&C had no clue about ESX… Thanks!
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…
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.
Got it. Thanks Duncan. By the way, your site rocks!!
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.
IMHO I think if the infrastructure is shared storage, there is no point creating a vmfs partition. think not?
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.
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?
I totally agree, I would actually always have two seperate partitions just in case you ever need it for testing or whatever.
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…..