VMware ESX and ESXi 4.1 Datastores, Partitions, and Mount Points

Carole Warner Reece

I’ve been studying VMware lately – specifically vSphere 4.1 and ESX/ESXi 4.1. This article is the first of several planned ‘observations’ on VMware from the perspective of a network-centric person delving into data center virtualization.


About a year ago I starting studying VMware. I’ve run through many of the online courses at VMware’s web site – I’m a VMware Sales Professional (VSP), and a VMware Technical Sales Professional (VTSP), and worked through several of the online Infrastructure Virtualization classes. So I decided to spin up and go for the VMware Certified Professional (VCP) status.

Last month I attended the vSphere 4.1: Install, Configure, Manage class. I liked playing on the labs, I liked my instructors Vince and Garth, but I did not feel that the course really had a plot I could completely follow. After the class, I spent a good bit of time reading Scott Lowe’s Mastering VMware vSphere 4 book and also the VMware documentation. I thought the book was quite helpful in putting ESX/ESXi/vSphere and the myriad of tools in a framework I could better follow. I also found that the VMware PDFs contain lots of facts that were helpful on the exam, and I recently passed the VCP exam. (My suggestions for VCP candidates – read Scott’s book, attend the required class, practice on VMware, review the blueprint, and look up the recommendations for each blueprint step in the VMware PDFs or other sources.)

Datastores, Partitions, and Mount Points

Now on to my first set of ‘observations’.  One aspect of ESX/ESXi that I needed to think through was the concept of the datastores, partitions, and mount points, and how they apply to host installations.

In the VMware environment, a datastore is a storage location for virtual machine files – this could be a VMFS volume, a directory on Network Attached Storage, or a local file system path.

A partition is a logical division on a hard disk, like a C:, D:, or E: logical drive created on a single physical Windows disk. (You can also have logical partitions on an extended partition.)  Partitions allow for a single hard drive to contain multiple operating systems, and to encapsulate and isolate chunks of data from other chunks of data.

A mount point is a directory in the currently accessible filesystem on which an additional partition is logically attached or mounted. A mount point is associated with a logical partition.  So a mount point is a directory such as ” /var/log ” that corresponds to the ” C: ” designation of a partition on a Windows machine. Any directory that is not a mount point is part of the same partition as either the root directory or another mount point.  If you put files in one mounted partition, the files will only consume space in that partition.
Mount Point Example: If your mount point is /var, then the directory /var/log is part of the /var partition. However if your mount point is /var/log, then the /var directory is part of the / partition. (The / partition is also known as the root partition.)

Partitions with ESX 4.1

So how do paritions apply to ESX 4.1 hosts? During an ESX 4.x installation, three physical partitions are created:

  • The /boot partition holds the files that are needed to boot ESX; there are no options for user to change during installation and it is hidden. The /boot partition must be on the disk that the BIOS boots from.  In VMware 4.1, the /boot partition requires 1100 MB.
  • The Vmkcore partition – is the core dump partition where ESX will write info about a system crash; it is hidden during installation and can not be modified. In VMware 4.1, the Vmkcore partition is 110 MB.
  • VMFS – all the rest of the local storage is a VMFS 3 datastore. This is an extended partition. (VMFS is the VMware File System

The Service Console used for the ESX Server command-line management interface is located in the VMFS filesystem as a virtual disk named esxconsole.vmdk. (This virtual disk can be stored on a SAN LUN or different block device than the system disk, as long as it has been partitioned and formatted as VMFS.)  As a best practice, the esxconsole.vmdk should not be situated on a shared SAN LUN.

  • The files that make up the Service Console are found in the root (  /  ) partition of esxconsole.vmdk. The root partition contains the ESX operating system and services, and is accessible through the Service Console. The size of the esxconsole.vmdk varies between deployments, and a minimum requirement is approximately 8GB. The root partition also contains installed third-party add-on services or applications.  All other Service Console partitions attach to a mount point under the root partition.
  • There are other partitions in the Service Console disk:
  • The swap partition holds the Service Console swap file. This virtual disk should be at least twice size of Service Console memory, and can be from 600MB to 1600 MB in size.
  • The /var/log partition stores the logs created by the Service Console during operations. The ESX graphic and text installers create this as a 2000MB partition by default. You can adjust the size and mount point for this partition or directory  n the Advanced settings of the installer. For example, Scott Lowe recommends using /var as the mount point, so that space consumed in /var directory when you do patch management is not consumed out of the root partition.
  • The /opt partition is an optional partition that can be used to hold additional vSphere components and third party products that can be installed. By making the /opt partition a mount point, you can separate the files from /opt from the space allocated in the / partition.
  • The /home partition is an optional partition that can be used for storage by individual users.
  • The /tmp partition is an optional partition that can be used to store temporary files.
  • The /usr partition is an optional partition that can be used to store user programs and data.

Partitions with ESXi 4.1

So how do paritions apply to ESXi 4.1 hosts? VMware ESXi installations do not use a Service Console, so need fewer partitions. Both ESXi Embedded and ESXi Installable automatically create two partitions and a VMFS datastore:

  • The scratch partition supports the system swap. This is a 4GB partition which is created on the disk from which ESXi is booting. Although the scratch partition is not required, it is recommended by VMwre. When it is present it is used to store vm-support output.
  • The vmware diagnostic partition is the core dump partition where ESXi will write info about a system crash. In VMware 4.1, the VMware diagnostic partition is 110 MB.
  • VMFS – all the rest of the local storage is a VMFS 3 datastore. This is an extended partition.

— cwr


If you would like some additional details, the following references should be helpful:

ESX and vCenter Server Installation Guide

ESXi Installable and vCenter Server Setup Guide

Module 14 of VMware vSphere 4.1: Install, Configure, Manage Student Manual

Mastering VMware vSphere 4 by Scott Lowe

2 responses to “VMware ESX and ESXi 4.1 Datastores, Partitions, and Mount Points

  1. I was just wondering what you thought of the VCP exam/class. My company doesn’t really want to pay for the training (which is a bit expensive and required) because I’ve been working with VMware for a few years now. They don’t believe that the class would offer much that I’m not already aware of. However, I would like to get the VCP cert as a bit of a resume builder. What are your thoughts?

  2. Hi Lauren –

    If you have been using VMware for a few years, you might consider taking an alternate course that counts towards the VCP cert, such as VMware vSphere Troubleshooting, which may work better for advancing your knowledge.

    You could also take the VCP test before taking a course, probably after reviewing the exam blueprint and looking up the recommendations for each blueprint step in the VMware PDFs or other sources. If you pass the exam, you could see if you could talk your management into sending you to one of the cert prerequisite courses. If you don’t pass, you can tell them you are a bit rusty on some details, and want to take a class.


Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.