The Service Console: Part 1 – What is it?

by BU NC HC on NOVEMBER 12, 2008

So I wanted to talk on best practices for your Service Console, what it’s for, and why and how to make it
redundant. As that’s a lot of information, we’ll break it out in some parts.

This first part we’ll talk about what the service console is, and what it does.

So what is the ‘Service Console’? It is the “Console Operating System” that is responsible for user
interaction with ESX. In the full ESX 3/3.5 (as in not ESXi), the service console is a VM that is based on
RHEL 3. In fact this is often what keeps folks confused and arguing that “ESX is just Linux”. However, this
is very much not the case. VMware has also tried to do everything possible to deemphasize the use of the
service console, and, in the ESXi release, and perhaps future releases, it will go away completely, to be
replaced by things like VIMA (VMware Infrastructure Management Assistant).
What’s it do this service console? I suppose my single line above wasn’t quite a good enough, but that is
more or less what it is responsible for: User interaction with ESX. This is a bigger task that it first appears
when you consider the various ways one can communicate with ESX:

 Command Line Interface (CLI)

 SSH Access
 Web Management (this includes SOAP, and the other various API’s)
 Using the VMware Infrastructure Client
 Communication with Virtual Center
The Service Console is also responsible for keeping this communication secure. This is done in several
ways as well.

 ESX Firewall (iptables)

 SSL to the web services
 Standard Linux authentication methods (keep your eyes open for a future article on getting ESX
to talk to AD)
The last two things the Service Console does are manage access to ‘non-critical’ hardware, and provide
support applications. Interesting, no? Lets explore those further.
What is ‘non-critical’ hardware? ‘Non-critical’ hardware is anything outside the Core 4 (Memory, Disk,
Networking, CPU), things like serial ports and cd-roms. This keeps the VMKernel light and agile to better
support your VM’s.

The last bit is support applications, and these are simply applications, like vm-support, or the esxcfg-* set
of commands that allow you to keep the host running in tip top shape. With ESXi, these are handled
either via the VIMA, or rCLI, which can both be downloaded from VMware’s site.

So, we’ve now covered what the Service Console is, and what it does. Next go around we’ll cover the why
and how of making it redundant.

The Service Console: Part 1 – What is it?

by BU NC HC on NOVEMBER 12, 2008

So I wanted to talk on best practices for your Service Console, what it’s for, and why and how to make it
redundant. As that’s a lot of information, we’ll break it out in some parts.

This first part we’ll talk about what the service console is, and what it does.

So what is the ‘Service Console’? It is the “Console Operating System” that is responsible for user
interaction with ESX. In the full ESX 3/3.5 (as in not ESXi), the service console is a VM that is based on
RHEL 3. In fact this is often what keeps folks confused and arguing that “ESX is just Linux”. However, this
is very much not the case. VMware has also tried to do everything possible to deemphasize the use of the
service console, and, in the ESXi release, and perhaps future releases, it will go away completely, to be
replaced by things like VIMA (VMware Infrastructure Management Assistant).
What’s it do this service console? I suppose my single line above wasn’t quite a good enough, but that is
more or less what it is responsible for: User interaction with ESX. This is a bigger task that it first appears
when you consider the various ways one can communicate with ESX:

 Command Line Interface (CLI)

 SSH Access
 Web Management (this includes SOAP, and the other various API’s)
 Using the VMware Infrastructure Client
 Communication with Virtual Center
The Service Console is also responsible for keeping this communication secure. This is done in several
ways as well.

 ESX Firewall (iptables)

 SSL to the web services
 Standard Linux authentication methods (keep your eyes open for a future article on getting ESX
to talk to AD)
The last two things the Service Console does are manage access to ‘non-critical’ hardware, and provide
support applications. Interesting, no? Lets explore those further.

What is ‘non-critical’ hardware? ‘Non-critical’ hardware is anything outside the Core 4 (Memory, Disk,
Networking, CPU), things like serial ports and cd-roms. This keeps the VMKernel light and agile to better
support your VM’s.

The last bit is support applications, and these are simply applications, like vm-support, or the esxcfg-* set
of commands that allow you to keep the host running in tip top shape. With ESXi, these are handled
either via the VIMA, or rCLI, which can both be downloaded from VMware’s site.

So, we’ve now covered what the Service Console is, and what it does. Next go around we’ll cover the why
and how of making it redundant.

The Service Console: Part 3 – ESXi

by BU NC HC on DECEMBER 17, 2008

Well now. We’ve come a long way since parts 1 & 2 haven’t we? That is all well and good considering,
and makes for some light background reading. However, the game changes with ESXi, as there is no
“Supported” Service Console on it’s platform.

In reality, the vmkernel runs a busybox executable. (Busybox is a linux in an executable binary sort of
thing), and you can enable DropBear SSH, and the like on it. Doing this however, will likely void your
warranty or support agreement, or prevent you from getting your per incident support taken care of, so I
strongly recommend against it.
With that said then. How does ESXi handle all of the communication we talked about before, how do you
make it redundant, and how do you interact with ESXi in a meaningful way? Let’s take a look at the first
two, the last will be covered in a future post.
“Service Console” Communications in ESXi

How does ESXi overcome it’s lack of a good and proper “Service Console”? At the physical console you
get something that resembles a server BIOS screen from which you can configure the ESXi host.

So that’s cool, but how does it communicate with the VI Client or VMware’s vCenter (formerly Virtual
Center)? It does this using a “Management IP”. By default this Management IP is set by DHCP at host
boot time, or can be configured manually from the console above. Remember this IP.

Making ESXi Management Communication Redundant

This actually works in quite the same way it did for the “Fat” version of ESX (Classic). You can setup NIC
teaming, and a redundant vSwitch on another network. Read Part 2 for more information there.

Create New Partitions

Following VMware best practices, it is best to dedicate entire partitions for the following directories:

/var

/tmp

/home

This can be accomplished by clicking New.

Follow the configurations from the following table, as the file system should reflect these sizes. Click Next when finished.

Local Storage Partitions

This table shows the service console partitions and sizes for each ESX Server host. Some of these recommended partition sizes are
larger than the default values. The additional partitions and increased sizes will protect against the critical root partition getting filled
up which can lead to issues. Note that this section does not apply for ESX Server 3i. Also, the following partition table uses less than
16 GB of space.

Service Console Partitions and Sizes for Each ESX Server Host
MountPoi Partition Size Description
nt
 /dev/sda (Primary)
/boot ext3 250 MB Change for additional space for upgrades

N/A swap 1600 MB Change for maximum service console

swap size

/ ext3 5120 MB Change for additional space in root

/dev/sda (Extended)
/var ext3 4096 MB Create partition to avoid overfilling root
with log files

/tmp ext3 1024 MB Create partition to avoid overfilling root

with temporary files

/opt ext3 2048 MB Create partition to avoid overfilling root

with VMware HA log files

/home ext3 1024 MB Create partition to avoid overfilling root

with agent / user files

vmkcore 100 MB Pre-configured

Free Space (Optional) Auto-configured and used for

local VMFS-3 volume (needed for virtual
machines running Microsoft’s Clustering
Software.