WilliamLam.com

How to compile Busybox for ESXi ... kind of Part 1

by // 1 Comment

I had initially researched this topic a few months back and decided not to write about it since it did not yield the results I was expecting. Some recent twitter conversations with Carter Shanklin and Didier Pironet this morning motivated me to dig up this content and share it with the community.

Before I get started, a word of caution:
!!!! THIS IS NOT SUPPORTED BY VMWARE - PLEASE USE AT YOUR OWN RISK !!!!

As you all know, ESXi does not have a Service Console like the classic ESX, but it does have a limited console based on Busybox, specifically v1.9.1 which is still the current version even with the latest release vSphere 4.1 Update 1. Busybox is heavlily customized by VMware and you will find a limited set of POSIX-like utilities, it is no where feature complete to your traditional POSIX environment and there is good reason for this.

If you have ever downloaded vSphere Hypervisor (formally known as ESXi), you may have noticed an "Open Source" tab at the top. This page contains some of the open source licensing information that VMware has used and incorporated into their products, most of these are just text files listing the various packages. One file that is of interest is the "OSS Source Code for ESX, ESXi and ESXi Embedded 4" which actually includes some of the open source RPMs and packages used to build Busybox for both classic ESX and ESXi (Yes, classic ESX also includes a busybox binary).

One interesting thing to note, is the date of this package, it has not been updated for almost two years. I am not sure if this is done intentionally, but I doubt that would be the case. It is also odd that VMware is still using an old release of Busybox (1.9.1), the latest release is at 1.18.3 and there have been quite a few updates between 1.9.1 and the current release. There has been speculation and rumors in the past that VMware choose a particular version of Busybox to get around the licensing of Busybox with ESXi. I do not know if this is true, but I do know, there have been quite a few bug fixes since incarnation of ESXi and you may hit some of those if you venture into Busybox console also known as Tech Support Mode (formally known as Unsupported Console)

The build environment that I used is running the latest version of CentOS 5.5 64bit which can be downloaded here.

Step 1

Download VMware-esx-public-source-4.0-162945.tar.gz (565MB) from from VMware's website and SCP it to your build system

Step 2

You will also need to install the following packages, you can do so using yum if you are using CentOS or RHEL and have a proper repository configured. You can use the following:

yum install -y gcc flex bison texinfo ncurses-devel libselinux-devel.x86_64 pam-devel.x86_64

Step3

Create a temporarily directory and move the tar.gz file into the directory and then extract the contents using the following command:

tar -zxvf VMware-esx-public-source-4.0-162945.tar.gz

You now should have a bunch of *.rpm files that have been extracted. There are two interesting RPM packages that we are interested that have "busybox" in the name, one of classic ESX (vmware-esx-busybox-1.9.1-1.624.vmw.src.rpm) and one for ESXi (vmware-visor-busybox-1.9.1-1.654.vmw.src.rpm)

Step 4

You will need to create the following directory before installing the ESXi RPM package. Use the following command:

mkdir -p /usr/src/redhat/SOURCES

Next, you will install the vmware-visor-busybox-1.9.1-1.654.vmw.src.rpm by using the following command:

rpm -ivh vmware-visor-busybox-1.9.1-1.654.vmw.src.rpm

Note: Don't worry about the warnings regarding the user/groups that do not exists, these are most likely a default from VMware's environment that expects the mts user and group.

Step5

Now you will change into the /usr/src/redhat/SOURCES directory and you should see three files:

  • busybox-1.9.1.tar.bz2 (Busybox v1.9.1)
  • config-vmware-visor (Busybox config file from VMware)
  • vmware.patch (VMware patch for building Busybox)

You will now extract the contents of the Busybox archive by using the following command:

tar -xvjpf busybox-1.9.1.tar.bz2

Next you will copy the vmware.patch into the busybox-1.9.1 directory by using the "cp" command and then change busybox-1.9.1 directory. If you do a "ls" you should see the following files:

Step 6

We are now going to apply the patch provided by VMware which will update some of the C source code found in default Busybox 1.9.1 along with setting up a build environment. We go through a dryrun process to see what files will be patched, use the following command:

patch --dry-run -p1 < vmware.patch

To apply the patch, you will run the following command:

patch -p1 < vmware.patch

After the patch has been applied, there are two interesting files that will be created in addition to the source code updates:

  • README.vmware (Pretty well documented set of changes + how to build Busybox)
  • vmware-env.sh (environment script that is sourced to build Busybox)
Step7

Now we are ready to build Busbox, the exact instructions are specified towards the end of the README.vmware file

Basically you will be executing the following commands:

VMWARE_TARGET=visor
source vmware-env.sh
cp ../config-vmware-visor .config
make oldconfig
busybox-build

Now if you executed the above, you will find that you quickly run into some build errors.

This is where the "kind of" part of the blog post comes in. If you recall, we sourced the vmware-env.sh script just prior to building, this is a script that VMware wrote to quickly setup the build environment for compiling Busybox for either ESX or ESXi.

For this particular build and release, they are using specific versions of GCC, Binutils and PAM. You might ask why not substitute these with the versions found on system? I have actually gone through that, but ran into other compliation issues which maybe due to fact that GCC and other components are much newer and not compatible with older versions of Busybox. I have also tried to match the build environment by using buildroot but continue to hit other compilation issues. The only way I can see building this particular patched version of Busybox is to get a build environment that matches what VMware uses.

In Part2, I will go into details on building your own Busybox binary for ESXi which I promise will be much more fruitful than this. Stay tuned ...

Update: It looks like there is a slightly more recent version of ESX(i) OSS released on 07/13/2010, for whatever reason, it was filed under VMware View section. The source RPM for ESXi still looks like the same one released back in 2009, but there some other packages that differ from the one found on vSphere Hypervisor page.

Another way to enable management traffic on ESXi

by // 3 Comments

Here is another way in you can enable the management traffic type on a VMkernel interface in ESXi without having to resort to using the vSphere API, this especially useful when automating a kickstart installation.

When you enable a specific vmkX interface (esxcfg-vmknic -l) to allow for the management traffic type, there is an entry that is made in the /etc/vmware/hostd/hostsvc.xml file. The specific interface is denoted by a unique nic id which starts off at 0000 and is incremented by one for additional VMkernel interfaces that are added.

If you add a second VMkernel interface called vmk1 and you wanted to also enable it for management traffic, the file would look like the following:

For the changes to take effect, you will need to restart hostd agent by running /etc/init.d/hostd restart. You will also need refresh the network sub-system by using vim-cmd hostsvc/net/refresh which will refresh the vSphere Client view else you will have to do it manually before you can see the update.

This is probably overkill, but I decided to write a simple script in which you can pass the VMkernel interface name and the script will update hostsvc.xml file with the proper nic id/etc. Here is an example for enabling management traffic for vmk1:

Download: enableMgmt.sh

If you would like to integrate this into your ESXi kickstart, you can easily do so based on the number of VMkernel interfaces you will be creating during the installation. You can add the following into your %post section which uses a here document to overwrite the existing hostsvc.xml with the expected VMkernel interfaces that should have the management traffic type enabled.

HOSTSVC_FILE=/etc/vmware/hostd/hostsvc.xml

cat > ${HOSTSVC_FILE} << __CREATE_HOST_SVC__

  
    vmk0
    vmk1
    vmk2
  
  normal
  
    on
    on
    on
  

__CREATE_HOST_SVC__

This is a cleaner alternative than using python and connecting to the vSphere API locally on an ESXi host which is described in my blog article Automating ESXi 4.1 Kickstart Tips & Tricks Tip #7

How to backup/restore vMA's config + vi-fastpass DB

by // 1 Comment

I recently wrote an article on the process of cloning vMA which provides a way of backing up vMA. Due to the ease of deploying vMA as a virtual appliance (using OVF), there aren't too many reasons you would need to backup this virtual machine. If you lost the system for whatever reason, you can easily re-deploy with just a few clicks.

However, having said that, if you extensively make use of vi-fastpass fpauth and manage a lot of targets whether they are ESX(i) or vCenter hosts, you need to understand it is not simply just re-deploying another vMA host. When you add a target to vMA's vi-fastpass, two accounts are provisioned on the host "vi-adminXX" and "vi-userXX", these accounts are associated with an encrypted cipher located on vMA which allows for "fastpass" access to the host without having to re-type the password to the host each time. If you were to re-deploy a new vMA host and add the targets again, your host will not only contain the old entries but now a new set of accounts for your new vMA host. This can be an issue as you start to have stale accounts on your ESX(i) or vCenter host.

To prevent this issue, you can actually backup both vMA's configurations which is primarily stored in a sqlite database and the vi-fastpass credential store. In the following example, I have two ESXi hosts being managed by my primary vMA and I also have a standby vMA DR host in which I will backup the files to.

First, you want to make sure you do not have any active vifptarget sessions, this is not a requirement but it can ensure you do not copy over any vMA "session cache" files to your DR site. You can check by doing a long listing in /home/vi-admin/.vmware and looking for the directory vmasessioncache which will contain any active cached sessions if you recently initialized a fastpass target.

Note: Again this is not really necessary and you can exclude the vmasessioncache directory as part of your backup

You will first need to "dump" the existing vMA database into a file and provide a name of your choice, you will need to run the following command:

sqlite3 /var/opt/vmware/vMA/vMA.db .dump > vMA.db.backup

Next, you will need to "scp" the following files to your vMA DR:

  •  vi-fastpass encrypted credential store file
    • /home/vi-admin/.vmware
  •  vMA's configuration dealing with vi-fastpass targets + vi-logger
    • /home/vi-admin/vMA.db.backup
  •  vMA's default logging configs + paths
    • /etc/vmware/vMA/vMA.conf 

You now should login to your vMA DR host and you should see only two files in the home directory of the vi-admin user: vMA.conf and vMA.db.backup (.vmware directory is a hidden directory in /home/vi-admin)

From here, you will restore vMA.conf and you will need to run the following command:

sudo mv vMA.conf /etc/vmware/vMA/vMA.conf

Next, you will restore vMA.db and you will need to run the following command:

sudo sqlite3 /var/opt/vmware/vMA/vMA.db < vMA.db.backup

At this point, we can verify the database contents by just running the ".dump" command:

sqlite3 /var/opt/vmware/vMA/vMA.db .dump

Now, we're not done yet, we need to run one additional tool that will perform some VMware "black magic" which will allow this new vMA to access all your ESX(i) and/or vCenter targets just as you had it before on your primary vMA.

You will need to create a file that provides some dynamic shared libraries for the tool we are going to execute. Create a file under /etc/ld.so.conf.d/vmware-vma using "sudo" and paste the following two lines:

  • /opt/vmware/vma/lib
  • /opt/vmware/vma/lib64

Now you will need to run the following to read in the configuration:

sudo ldconfig -f /etc/ld.so.conf.d/vmware-vma

Now you are ready to run the "migratecredstore" utility which is located under /opt/vmware/vma/bin which will perform the "black magic" and make sure you use sudo.

Once you see the successful message on completing the migration of your credential store, you have now fully restored your original vMA configuration. Here we perform a list of the active servers that was once accessible on primary vMA and initializing a target and verifying that it does in fact work.

One thing to note, if you still have access to your primary vMA, both your vMA's are now in an active/active state, with caveat that your primary vMA is the only one allowed to make any changes. What I mean by this, is when you initially add a host to vMA's fastpass, it not only creates two accounts, but it also associates it's system's UUID as part of the unique identifier which is stored on the host with the key VMAID

This means that if you deleted the target off your vMA DR host, it does not actually remove this entry on your ESX(i) and/or vCenter host. Only the primary vMA which has the matching UUID is able to remove the entry all together when you perform a "vifp removeserver" operation.You can see the system UUID by using the dmidecode utility.

We can also see this within the vMA database, when viewing this on the vMA DR host, you will actually see both entries of the primary and the DR vMA UUIDs because we restored the database with the original vMA's config.

If you need your vMA DR host to be able to modify entries or rotate passwords, you will need to shutdown vMA and update it's bios.uuid within the .vmx entry. You must use the "original" vMA's UUID which you should see from the database by running the following command:

sqlite3 /var/opt/vmware/vMA/vMA.db "select * from management_info;"

You will also need to delete the "new" UUID to ensure that only one exists which should be the "original" UUID, you can so by running the following command substituting your UUID:

sudo sqlite3 /var/opt/vmware/vMA/vMA.db "delete from management_info where myUUID='422E4042-63EE-86D1-D22A-79B6ABCA8D68';"

At this point, your vMA DR is now your primary and your old vMA is no longer needed.