Skip navigation

This is part 2 of whole series of Using ESXi to replace ESX. ESXi comes long way and still not taking major market for production. But I personally believer RCLI, VCenter+ESXi will be the future. Vmware has already developed hidden page to guide everyone to upgrade from ESX to ESXi. Yes, please read on and I will explain it later.

So this is sort of deep dive to ESXi system. However, there ain’t much information about ESXi4 so I have to add lots of own opinions. If I made mistake, please feel free to point out.

Ok. Let’s take look what the difference between ESX and ESXi at Architecture level.

This is ESX4 architecture. Essentially, everything is running on Service Console (Red Hat). VMKernel itself is an operating system just like all other OS. But it relies on SC to do all communication works and runs different agent. VMware agents (vpxa, hostd, etc) runs on SC and always run into stability issue after people install all other Hardware monitoring agents on SC. According to my experience, we always have some HA agents issue, SC stop responding to ping and heartbeats. Then, the issue resolved by itself after few minutes. All command lines are running on SC and then, SC forwards to VMKernel and wait for reply. This is long way to go and consumes lots of extra resources and bring tons of headache to VMWARE.

The above picture is ESXi diagram. I have to say, ESXi is not only a free product, but also a brand new design from architecture level. It has following advantages comparing with ESX.

Vmware agetns ported to run directly on VMKernel.

Let me bring up another diagram so  you can take a close look.

As you can see, vpxa, hostd and other important processors have migrated from SC to VMKernal. They are running on User world API stack and waiting for the communication from RCLI, vPowershell, and VC.

Authorized 3rd party modules can also run in Vmkernel. These provide specific functionality

  • Hardware monitoring
  • Hardware drivers

There are quite big changes in the Hardware monitoring world. VMware in default weak SNMP protocol (no SNMP trap set for ESXi) and focus on CIM broker.

The Common Information Model (CIM) is an open standard that defines how computing resources can be represented and managed. It enables a framework for agentless, standards-based monitoring of hardware resources for ESXi.

Basically, instead of using SNMP trap and query SNMP to your HOST, you should enable WBEM to do all the jobs. If  you want to deploy your ESXi system, you should not download ESXi directly from vmware site, but instead, you should go to your server company to download their special version of ESXi. For example, HP provides HP WBEM(Web Base Enterprise Management) embedded ESXi for free downloading. ESXi allows third-party to pre-install CIM Plug-ins and ESXi and plug-in can be upgraded separately. All what you need to do is to download HP SIM Manager and start querying. (In default, WBEM queries every 2 minutes)

With this design, ESXi can use agentless framework to let hardware monitoring system get full details of Host and also secured and prevent unexpected error caused by HW Agent (like HP SIM Agents).

The “dual-image” approach lets you revert to prior image if desired

This is very interesting design special for ESXi.

The ESXi system has two independent banks of memory, each of which stores a full system image, as a fail-safe for applying updates. When you upgrade the system, the new version is loaded into the inactive bank of memory, and the system is set to use the updated bank when it reboots. If any problem is detected during the boot process, the system automatically boots from the previously used bank of memory. You can also intervene manually at boot time to choose which image to use for that boot, so you can back out of an update if necessary.
At any given time, there are typically two versions of VI Client and two versions of VMware Tools in the store partition, corresponding to the hypervisor versions in the two boot banks. The specific version to use is determined by which boot bank is currently active.
As what the pdf says, ESXi alwasy keep another version of configuration file and other components. If boot fails, it can switches over like “Last good configuration” function in MS.
If you runs command fdisk -l in the ESXi, you will get following picture.

As you can see, the first part is Extended partition, also called Store partition. It’s about 917MB in ESXi4 instead of 750MB in ESXi 3. It stores Auxiliary files like VI client, VMWare tools, runtime storage etc.

The second partition is 4GB as what VMWARE called Scratch partition. Next one is VMFS partition. Partition FAT16<32M is bootloader partition. It remains as 4MB to choose which boot bank should be loaded. Boot bank (255MB in ESXi) contains core hypervisor code. Diagonistic Partition (112MB in ESXi4) is for core dump purpose. And the last one is Hypervisor 3 Locker. Once you start Locker mode, no remote access will be accepted.

As you can see, ESXi4 has 3 different boot options. Primary, backup and locker mode. It provides failover and security as well. I will review this part again in my next part (part 3).

No other arbitrary code is allowed on the system

Essentially, ESXi should be consider as an appliance with firmware. Yes, there are still quite few things you can mock around, like open SSH, setup SNMP TRAP, Backup configuration settings without host profile function, but comparing ESX 4, it’s much simple, easy, fast, efficient and safe.

Much less updates means much better stable system

Let’s see this diagram from Vmware, then it will explain by itself.

Finally, at last but not least.

VMWARE has developed web page to help user to Upgrade from ESX to ESXi. But you can’t find link from it’s parents page which is vSphere page.

I provide the link so you can see it by yourself.

http://www.vmware.com/products/vsphere/esxi-upgrade/architecture.html

To be continued….

Add-on:

One of my friends just questioned about ESXi and think ESX is better environment to execute his precious codes. I think Service Console has nothing to do with implement or execute code because this job is done by vSphere API. ESXi has vSphere API just like ESX and has no issue to execute any codes running on ESX.

For better understanding, I’m showing you this picture to prove my point.


Reference:

http://www.vmware.com/files/pdf/vmware_esxi_architecture_wp.pdf

http://www.vmware.com/products/vsphere/esxi-upgrade/architecture.html

http://docs.hp.com/en/5991-6518/ch01s06.html

Advertisements

One Comment

  1. Great information. very useful


One Trackback/Pingback

  1. […] scheme which the user can’t change. See this blogpost at Jason Boche’s site, and another blog article at Geeksilver’s site (and one more for […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: