Posts Tagged ‘Partitioning’

ESX partitioning a lost art form in ESXi

October 24th, 2008

On the heels of Duncan Epping’s blog article about ESX partitioning best practices comes my first look at the automatic partitioning in ESXi.

Before I dive into ESXi, allow me to provide a brief primer on the history of ESX partitioning as I see it. Once upon a time, long before the coming of ESXi and when there was only ESX, there existed great debates in books, whitepapers, knowledgebase articles, datacenters, forums, and blogs about how best to properly partition ESX. Careful planning up front meant better optimization, stability, and uptime of the ESX host, saving the company money from poor host performance, reduced downtime, and unplanned outages. The ESX administrator also slept better at night. What is the big debate? ESX administrators evolve from varying backgrounds where they dealt with a range of operating systems. Each administrator brings their best ideas, experiences, and nightmares the he or she would probably like to forget, to the table. With the ESX Service Console (Console Operating System or COS for short) based on a version of Red Hat, Linux and Unix administrators were natively the best equipped to carry on an intelligent conversation of Linux partitioning “Do’s and Don’ts”. However, ESX did add a few twists in how it used the COS and the file system. Taking into account the native behavior of Red Hat in addition to the ESX specific characteristics, partitioning best practices evolved. While not every administrator will agree on the exact size a given partition should be, a pattern in how ESX is properly partitioned is fairly evident, plus or minus the partition size variance that fits the personal taste of the administrator or perhaps company baseline policies or standards. ESX partitioning strategy was an art form; maybe something to brag about when getting your geek on in a circle of peers. I’ll go out on a limb here and say that no self respecting ESX administrator used the automatic partitioning ESX offered even though it might have saved a little time and in fact was and is still today the default partitioning choice during an ESX installation. No offense intended, but the automatic partitioning in ESX was less than stellar. In fact, automatic partitioning sizes were not consistent with best practices taught in the Virtual Infrastructure classroom training. Right there is a good a reason as any to partition manually.

Recently, I began evaluating ESXi. Having been a seasoned ESX administrator for quite a while, one of the things I noticed about the ESXi installation (in addition to its incredibly fast installation time) was the partitioning configuration. Or lack thereof. Had I blown through the screens so quickly that I didn’t notice and accidentally performed automatic partitioning? It was no accident. A second installation revealed that ESXi makes the partitioning choices for us, and provides us no opportunity to size our own partitions short of deleting and recreating after the fact using fdisk in the unsupported “Tech Support Mode” console. That’s nothing but trouble. The only partitions you should be creating after the ESX/ESXi installation are VMFS volumes.

So I’m stuck with automatic partitioning in ESXi. It’s a paradigm change I could get used to if it’s technically sound. But what does it look like and what are the partitions in ESXi used for? An unsupported trek into the “Tech Support Mode” console allowed me to run some df -h, fdisk -l, and ls commands to find out.

On an 8GB disk, an installation of ESXi 3.5.0 Update 2 creates the following partitions automatically:

Vmhba1:0:0:1 Extended

Vmhba1:0:0:2 FAT16 4,095MB Looks like /. contains directories: downloads, uwswap, var

Vmhba1:0:0:3 VMFS 3,347MB datastore for VMs, ISOs, VMKernel swap

Vmhba1:0:0:4 FAT16 <32M 4MB Unknown

Vmhba1:0:0:5 FAT16 48MB contains miscellaneous files (boot.cfg, *.tgz, etc.)

Vmhba1:0:0:6 FAT16 48MB contains miscellaneous files (boot.cfg, *.tgz, etc.)

Vmhba1:0:0:7 VMKcore 110MB allocated for VMkernel core dump

Vmhba1:0:0:8 FAT16 540MB contains directories: core (for COS dumps?), opt

Ok, some of the partition sizes above were quite small. Understandably, I started out with a small 8GB disk, not giving ESXi much to work with. My next question was “would the auto created partition sizes be larger if I used a larger disk?”. So I reinstalled using a 16GB disk to find out.

On a 16GB disk, an installation of ESXi 3.5.0 Update 2 creates the following partitions automatically:

Vmhba1:0:0:1 Extended

Vmhba1:0:0:2 FAT16 4,095MB Looks like /. contains directories: downloads, uwswap, var

Vmhba1:0:0:3 VMFS 11,539MB datastore for VMs, ISOs, VMKernel swap

Vmhba1:0:0:4 FAT16 <32M 4MB Unknown

Vmhba1:0:0:5 FAT16 48MB contains miscellaneous files (boot.cfg, *.tgz, etc.)

Vmhba1:0:0:6 FAT16 48MB contains miscellaneous files (boot.cfg, *.tgz, etc.)

Vmhba1:0:0:7 VMKcore 110MB allocated for VMKernel core dump

Vmhba1:0:0:8 FAT16 540MB contains directories: core (for COS dumps?), opt

Between the 8GB install and the 16GB install, not a single partition size change with the exception of VMFS. It simply grew the VMFS partition to consume the additional 8GB of disk.

With this automatic partitioning scheme, how heavily are each of the partitions utilized out of the box?

Vmhba1:0:0:2 FAT16 4,095MB 25% used

Vmhba1:0:0:3 VMFS 11,539MB n/a

Vmhba1:0:0:4 FAT16 <32M 4MB Unknown

Vmhba1:0:0:5 FAT16 48MB 0% used

Vmhba1:0:0:6 FAT16 48MB 76% used

Vmhba1:0:0:7 VMKcore 110MB 0% used (and let’s hope for the sake of uptime it stays this way)

Vmhba1:0:0:8 FAT16 540MB 32% used

Bottom line: Am I comfortable with this partitioning? Time will tell if it’s adequate. I’ll keep a watchful eye on the experiences of others on the VMTN forums. I’m not using ESXi in production or development right now. Further information gathering on ESXi may reveal there are other deployment methods for ESXi that allow more granular control of its installation parameters. For now, I’m in the evaluation stage to see if ESXi is the right fit. It certainly carries with it some attractive attributes but there are also things I must learn to let go of such as the Service Console and all of the utility it provides.