Application Awareness HA is not a new feature in vSphere 5, it has actually has been around since vSphere 4.1. With this feature, vSphere HA can monitor heartbeats generated from an application monitor within the guestOS and reboot the virtual machine.
What is actually new in vSphere 5 is the availability of the Application Awareness API for anyone to consume and integrate into their own application and/or script. Prior to this, the API was only exposed to ISV and 3rd party vendors with solutions such as Symantec's ApplicationHA and Neverfail's vAppHA.
The Application Awareness API (will be shorthanded as AAA, going forward) is supported in both Linux and Windows (32/64bit) and can be accessed by installing a package within the guestOS. This package includes the necessary AAA libraries to create your own program/scripts in C, C++, Java and Perl. In addition, the package also includes a pre-compiled binary (vmware-appmonitor) that implements all the AAA methods that can easily be called from within a script or program. AAA uses the VMware Tools as communication channel to the ESX(i) host and you will need to ensure VMware Tools is installed and running. Since the communication is between VMware Tools and the ESX(i) host, there is no reliance on a TCP/IP network for this communication channel.
UPDATE: You can download GuestAppMonitor SDK here.
There are currently 6 AAA methods:
- VMGuestAppMonitor_Enable()
- Enables Monitoring
- VMGuestAppMonitor_MarkActive()
- Call every 30 seconds to mark application as active
- VMGuestAppMonitor_Disable()
- Disable Monitoring
- VMGuestAppMonitor_IsEnabled()
- Returns status of Monitoring
- VMGuestAppMonitor_GetAppStatus()
- Returns the current application status recorded for the application, three possible values:
- green = Virtual machine infrastructure acknowledges that the application is being monitored.
- red = Virtual machine infrastructure does not think the application is being monitored. The
HA monitoring agent will initialize an asynchronous reset on the virtual machine if the status is Red - gray = Application should send VMGuestAppMonitor_Enable again, followed
by VMGuestAppMonitor_MarkActive, because either application monitoring failed, or the virtual machine was vMotioned to a different location
- Returns the current application status recorded for the application, three possible values:
- VMGuestAppMonitor_Free()
- Frees the result of the *_GetAppStatus() call (only required when writing your own program)
Here is the basic workflow for using AAA within your application:
To start using AAA functionality, you will first need to have a vSphere HA enabled cluster and enable the "VM and Application Monitoring" under VM Monitoring.
You have the ability to configure the sensitivity of AAA from Low, Medium and High which correlates to the heartbeat interval and frequency of virtual machine reboots. You also have the option of configuring your own custom policy.
Lastly, you can choose which virtual machines will be included in VM Monitoring and/or Application Monitoring.
Note: It is important to note, that HA will expect an application heartbeat to be generated every 30secs. If HA fails to receive a heartbeat within 30secs, it will transition the appHeartbeatStatus state from green to red. Depending on the configured sensitivity policy, once the heartbeat interval has been violated, HA will then restart the virtual machine. For example, if you have the sensitivity configured to medium and a heartbeat was not received within 30secs, it will change to a red state. If HA still has not received a heartbeat within 60secs of that time, then it will reboot the virtual machine.
Step 1 - Copy the AAA package to Linux system and extract the contents
Step 2 - Change into VMware-GuestAppMonitorSDK/docs/samples/C/ and ensure you have gcc compiler. You may have to change the makefile if you are on a 64bit platform as it is configured by default to point to the 32bit library. When you are ready, just type "make" and you should get compiled binary called "sample" which is the sample C application
Before you run the application, you need to ensure that your shared library path variable LD_LIBRARY_PATH has been updated to include the libappmonitorlib.so. To update the variable, you will run the following command:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/full/path/to/VMware-GuestAppMonitorSDK/lib64
Step 3 - You can now run the "sample" application which runs in a continuous loop and automatically enables AAA within the virtual machine and sends heartbeats to ESX(i) host. You can press control+C which then brings up three options: stop (s), disable (d), continue (c). The last two options should be pretty straight forward, but if you decide to stop the heartbeating and you don't resume, you will see HA restart the virtual machine based on your cluster configuration.
As you can see, once the heartbeats have not been received within the specified interval, HA will take action and reboot the virtual machine as expected. Here is a detail of the events as seen by vCenter and the HA cluster:
Here is an example of installing AAA on a Windows system and using the pre-compiled vmware-appmonitor binary:
Step1 - Copy the AAA package to Windows system and extract the contents
Step 2 - Launch a cmd prompt and change into C:\Users\Administrator\Desktop\VMware-GuestAppMonitorSDK-457765\VMware-GuestAppMonitorSDK\bin\win64 directory. Depending if you are on a 32/64bit OS, you will need to modify the win{32,64}
Step 3 - Run the vmware-appmonitor.exe which will then provide you with options: enable, disable, markActive, isEnabled, getAppStatus
Note: The options in vmware-appmonitor for both Linux and Windows are exactly the same, this is very nice for consistency and scripting purposes. Just like with the direct use of the API, you need to first run the enable command to turn on Application monitoring and then run the markActive command which sends the heartbeats. You can always check the current heartbeat status by running getAppStatus or check whether AAA is enabled by running isEnabled command
As a reference, here are the paths to the vmware-appmonitor for both Linux and Windows:
- VMware-GuestAppMonitorSDK/bin/bin{32,64}/vmware-appmonitor
- VMware-GuestAppMonitorSDK-457765\VMware-GuestAppMonitorSDK\bin\win{32,64}\vmware-appmonitor.exe
For those of you who are not into programming languages such as C,C++ and Java, here is an example using Perl. In the example, the script simulates the monitoring of an application by checking whether or not a file exists. The script starts off by creating a file that will monitored and then loops for 5 minutes and checks for the existence of the file. Once the 5 minutes are up, the script then disables Application monitoring and exits.
Note: You will need to set the two variables at the top which define the path to the shared library and the vmware-appmonitor binary.
So far we have demonstrated on how to setup AAA within the guestOS and provided a variety of programming/scripting interfaces such as C,C++, Java and Perl to integrate with your own application/script. Now what if we wanted to extract the heartbeat status for all virtual machines that have AAA implemented going through vCenter? You can easily do so by using the vSphere API and querying the appHeartbeatStatus property of your virtual machine.
I wrote a very simple vSphere SDK for Perl script getVMAppStatus.pl that allows you to query a virtual machine connecting to either vCenter or directly to an ESX(i) host to extract the heartbeat status.
Download the getVMAppStatus.pl script here.
The script can return three different status: gray, green or red and the definition for each is defined above.
Now before you jump right in and start leveraging this awesome API in either a custom application or script, you need to understand your application and various ways on detecting that it has failed and when you would like vSphere HA to reboot the virtual machine. Simply checking whether the process is running may or may not be enough.
To get more details on some of the best practices around using the Application Awareness API, I would highly recommend you check out Tom Stephens upcoming VMworld 2011 presentation TEX1928 Implementing Application Awareness in the Web Client and The Uptime Blog for more details about implementing AAA . For now, if you would like to learn more about Application Awareness API, check out last year's VMworld presentation.
How to compile a statically linked rsync binary for ESXi
Running rsync on ESXi is not a new topic, there are a number of users in the community who have made this work. One well-known user, Dave Mishchenko, who runs vm-help and recently authored VMware ESXi: Planning, Implementation, and Security, provides an rsync binary that can be downloaded to run on ESXi. Not that I did not trust Dave and the source of his rsync binary, but I wanted to compile my own and understand the process Dave took to get to a compatible rsync for ESXi. In talking to Dave, I found out the binary was actually provided by a VMTN user, named glim who had noted some of the details in this VMTN thread.
The user basically created a statically linked versus a dynamically linked version of rsync which runs without relying on libraries that may or may not be present on ESXi. My initial attempts failed using both a 32/64bit CentOS 5.5 and latest version of rsync 3.0.7 and 3.0.3. The compilation of rsync was successful, but upon executing on ESXi, it immediately had a segmentation fault. I started to think there might be some dependencies in libraries that were used to compile rsync that I was missing. I was also in conversation with Alain Spineux, creator of MKSBackup regarding this same topic and he had found a way to compile rsync based on the article Hacking ESXi by Stjepan Groš.
Stejepan found that using CentOS 3.9, one could compile both statically and dynamically linked binaries without any modifications to ESXi. Though Stejepan did not provide the steps to compile rsync, it is relatively simple to do so. I also found that you do not need to use older 3.0.3 release of rsync, you can use the latest version which is 3.0.7 as of writing this article.
Before we get started, let me remind you of the disclaimer:
*** THIS IS PROBABLY NOT SUPPORTED BY VMWARE, USE AT YOUR OWN RISK ***
Download and install CentOS 3.9 i386 - You can find a list of download sites here
With a default installation of CentOS 3.9, you just need to get GCC installed
yum -y install gcc
Next you will need to download the latest version of rsync which is 3.0.7 here and SCP it to your CentOS system
Next you will now extract the contents of the rsync-3.0.7.tar.gz
tar -zxvf rsync-3.0.7.tar.gz
Now you will change into the rsync-3.0.7 directory and run the configure command
./configure
Now you will run the make command which will compile rsync, but you will also be passing in additional flags to create a statically linked binary
make CFLAGS="-static" EXEEXT="-static"
Finally, you will need to run the strip utility which discards all symbols from object files
strip rsync-static
You now have a self-contain rsync binary labeled rsync-static found in the current working directory
Next up, you will SCP the rsync-static binary to your ESX(i) host and set the appropriate permissions to execute. I decided to temporarily store it in /tmp, but if you want the binary to persist through a reboot, you may want to store it in either a local or remote VMFS/NFS volume.
I quickly verified that rsync was in functional, by rsyncing /etc directory in ESXi over to another host. I use the following command:
/tmp/rsync-static --compress --progress --stats -e dbclient -Rr /etc build-centos:/upload
Once the file transfer has completed, you should see the /etc directory replicated on the destination host.
You may have noticed in the command line we are specifying "dbclient", by default rsync will go over SSH but ESXi does not actually have the traditional ssh client that we are all used to. It actually uses dropbear which is tiny SSH server and client which is frequently used in embedded systems such as Busybox.
Since /bin/ssh path does not exists, rsync will fail unless you specify the dbclient to the -e parameter.
Alain also found that retrieving peer name may fail and the rsync code currently does not properly handle this failure and just exits. By looking at the clientname.c source code which is part of rsync, Alain noted that even the developers left a comment that states the error could probably be handled without exiting. The fix is to just comment out the rsynerr line which does not force the program to exit when hitting this problem and this can be found on line 171.
Once you have made the changes, you just need to follow the instructions above to compile your static rsync binary. This is not necessary required, but if you run into this issue, this is a quick hack that can help.
I would like to thank Alain for sharing this tidbit of information
How to compile Busybox for ESXi ... kind of Part 2
Continuing from part1 of How to compile Busybox for ESXi ... kind of Part 1 we found some challenges in compiling VMware's Busybox version found in ESXi OSS Source Code. In this article, we will go through process of compiling the latest version of Busybox which is currently 1.18.3 to run on ESXi.
Again, before getting started, a word of caution:
!!!! THIS IS NOT SUPPORTED BY VMWARE - PLEASE USE AT YOUR OWN RISK !!!!
The build environment that I used is running the latest version of CentOS 5.5 64bit which can be downloaded here.
Download busybox-1.18.3.tar.bz2 from the Busybox's website and SCP it to your build system.
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
Extract the contents of busybox-1.18.3.tar.bz2 using the following command:
tar -xvjpf busybox-1.18.3.tar.bz2
You will now change into the busybox-1.18.3 directory and from here you have a few ways of building Busybox. To get a list of build options, use the following command:
make help
You can customize the build of Busybox by enabling and disable specific applets to be compiled. If you want to build Busybox with no applets (not really useful), you can run the following command:
make allnoconfig
make
Once the compilation is complete, you will now have a Busybox binary in which you can run but it does nothing useful:
You can also perform the exact opposite by enabling all options which can be called using the "allnoconfig" or "defconfig", you can run the following command:
make defconfig
make
Once the compilation is complete, you now have Busybox binary which has all the available applets by default:
Enabling all applets, the Busybox binary still comes out to be less than 900k. If you wanted to create a custom Busybox with specific applets, you can manually edit the .config file which is where the features are either enabled or disabled. This can get very tedious, luckily there is a make option which allows for an interactive menu on selecting the applets you would like to include in the build.
To enable the interactive menu, you will run the following command:
make menuconfig
From here, you will be able to configure the Busybox settings and the various applet types by their functions such as networking or mail utilities. One feature that is actually disabled in the VMware's version of Busybox is the support for large files, if you tried to tar up a file that was larger than 2GB and then extract the file, you will notice you get an error regarding the file size. The reason is VMware decided to not enable this feature in their Busybox build.
Once you are done selecting or de-selecting all your Busybox settings and applets, you will need to save your configuration which is stored in the .config.
Once you have exited from the interactive Busybox menu, you are now ready to build your custom version of Busybox, you will run the following command:
make
If everything went well, you now should have a busybox binary in your current working directory. Here is an example of my custom Busybox image:
If you would like to customize the version information found when just running busybox command without any arguments, you can edit the Makefile and append your custom text to EXTRAVERSION variable.
Now you just need to re-run the "make" command and your new busybox binary will include the additional version information.
Now before you jump and start creating your own Busybox binary, I must throw in another caveat that re-iterates the title of this post. Just because you have Busybox built with all these applets, it does not mean it will run 100% on ESXi, the reason being is there are specific dependencies that the non-VMware Busybox applets may rely on which are just not available with ESXi. This is one of the reasons why VMware did not just enable all applets from Busybox to begin with, your mileage will vary depending on the particular command you have enabled.
Here is an example of my custom Busybox applet "crontab" using the "-l" flag which lists any active cron entries for the particular user:
It runs just fine on ESXi as you can see, but let's try using the "-e" flag which if you are familiar with using crontab you will know that is the option to edit your cron entries:
Ooops, what's this? It looks like this particular operation of crontab relies on vfork which is not implemented. I have seen other similar errors with other applets relying on particular dependencies in the environment that just does not exist with ESXi. I have not tested every single applet and some may work 100% while others may be partially functional, you will need to test and verify for yourself.
If you feel adventurous, go ahead and download Busybox and start playing with it. I would highly recommend that you test this in your vSphere development environment before trying this on a production host. I would also recommend that you do NOT replace the default Busybox binary found on ESX(i) as you can run into some serious issues. Since the Busybox binary is self-contained, you can store it in /tmp or somewhere more permanent such as a local or remote VMFS datastore and renaming the file will also remove any confusion.
If you find other utilities that you feel that should be included in the default Busybox applet and do not want to resort to something like Poor man's traceroute for ESXi, be sure to submit your feedback to either your VMware rep or file a feature request.
If you are interesting to learning more about Busybox, check out their FAQ page and this page for more details.
Again, another warning:
!!!! THIS IS NOT SUPPORTED BY VMWARE - PLEASE USE AT YOUR OWN RISK !!!!