Get Adobe Flash player

Best Practices for vSphere (ESX 4) Service Console Partitions

One of my popular posts on VM /ETC has been Best Practices for ESX Host Partitions. Now with vSphere, VMware has changed the recommended ESX 4 Service Console partitioning slightly. So, consider this post an update to the first one. As in the past, I’ve taken this information from the VMware Partner services delivery IP available to partners on VMware Partner Central. Specifically I am taking information from the vSphere Essentials PoC delivery guide(s) found in the vSphere 4 Services Kit.

Quoting myself from the first post, some things are still worth mentioning up front:

“Installing ESX is fast and simple. By default you could click through the installer GUI changing only your local time zone and end up with a stable, dependable host. However, there are some recommended partitioning best practices that should be followed in order to make sure you minimize possible future headaches and create a repeatable and scalable environment.”

When you install ESX 4 you should choose Advanced for the installation type so you can delete the default partitioning shown in the following screen shot:


After deleting / changing the default s you can then create custom partitions as recommended.

Custom Partitioning

  • The following Custom Partitioning Design is recommended:

Mount Point







The / (or “root”) partition stores the ESX system and all files not stored in another custom partition. If this partition is filled to capacity, the ESX host could crash. It is imperative to prevent this.




The swap partition is used to supplement RAM if the service console runs out of physical memory.




The /home partition is created as a failsafe to help prevent / from filling up. Service console accounts (not vCenter) each have an associated /home folder. As a best practice, administrators should not use these folders for storage. If service console accounts are to be used and there are multiple users requiring access, the size of this partition may need to be increased. By default, /home is part of the / partition. By creating a custom partition for it the / partition will be protected if /home fills to capacity.




The /tmp partition is also created as a failsafe to help prevent filling the / partition. /tmp is often used to untar support files, temporarily store copied logs and stage patches. By default, /tmp is part of the / partition. By creating a custom partition for it the / partition will be protected if /tmp fills to capacity.




Traditionally, /vmimages was used to store CD-ROM images (.ISOs) and Floppy Disk images (.flp, .img). However, most organizations following best-practices have moved this from each individual host to a single shared-storage location. However, by default ESX creates a /vmimages folder within / . This makes it dangerously easy for an Administrator to mistake it for the shared-storage repository and copy images into it that will fill / . As a failsafe to help prevent this, a small custom /vmimages partition can be created. If the local /vmimages folder is actually used, this size may need to be increased.




The /var partition stores most system logs. Creating a custom /var partition provides substantial, dedicated log storage space (/var/log) while protecting the / partition from being filled by log files. Normally /var is part of the / partition.


  • The installer also automatically creates the following partitions without displaying them:




/boot stores the files necessary to boot the service console.




The vmkcore partition temporarily stores log and error information should the VMkernel crash.


Note that it is no longer necessary to designate partitions as primary or extended.

When you are done creating the new partitions per the table you should have a scheme like in the following screen shot.

VMware engineer Duncan Epping recommends the same basic partitioning on his blog at Epping also expands at bit more on some of the reasoning for customizing the partitions at

“The reason for this is the fact that the service console is a VMDK. This VMDK is stored on the local VMFS volume by default in the following location: esxconsole-/esxconsole.vmdk. By the way, “/boot” has been increased as a “safety net” for future upgrades to ESX(i).

So for the manual installations there are three partitions less to worry about. I would advise to use the following sizes for the rest of the partitions, and I would also recommend to rename the local VMFS partition during installation. The default name is “Storage1?, my recommendation would be “-localstorage”.

/     – 5120MB
Swap  – 1600MB
Extended Partition:
/var  – 4096MB
/home – 2048MB
/opt  – 2048MB
/tmp  – 2048MB

With the disk sizes these days you should have more than enough space for a roughly 18GB for ESX in total.”


[ad] Empty ad slot (#1)!

Related Posts



I blog with Blogsy

Comments / DISQUS