The Service Console: Part 3 – ESXi

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.