WilliamLam.com

Ghetto webAccess for ESXi

by // 14 Comments

I got the idea for this post a few months back after noticing several questions on the VMTN forums on how to enable webAccess for ESXi. With ESXi, the webAccess interface is no longer available as it was with classic ESX. After seeing the question and randomly browsing through the various flings on VMware Labs, I noticed an interesting fling called Ops Panel for ESX. Ops Panel provides a simple javascript that leverages the vSphere MOB to perform basic power operations for virtual machines and it is loaded onto the homepage of a classic ESX host remotely using Greasemonkey.

I immediately wondered if I could run the javascript directly on an ESX or ESXi host without the use of Greasemonkey. With a quick tweak of the default index.html homepage, I was able to get a simple "ghetto" webAccess running on both an ESX and ESXi host. I also ran into several bugs, one that dealt with how the power state of a virtual machines was being captured by the differences in the ESX(i) 4.0, 4.1 and 5.0 APIs and a recent fix to a CSRF (Cross-Site Request Forgery) vulnerability in ESX(i) 4.1 Update 1 that made it difficult to get Ops Panel running on more than just ESX(i) 4.0.

I reached out to the fling creator Ivan Donchev and he was kind enough to help assist me in the issues I ran into and also provided an updated version of his script to properly handle both the power state and the CSRF workaround. He recently published an update to his script a few weeks back supporting both ESX 4 and ESXi 5 but missed ESX(i) 4.1 support due to limited amount of testing. This was an easy fix and I modified the script to include support for ESX(i) 4.1 and also changed the default power off operation to a guestOS shutdown. The modified version of the script can be downloaded here.

When you browse to the homepage of your ESX(i) host using the browser, you will be prompted to login which require the same credentials as if you were to login to the host directly using the vSphere Client or vSphere MOB.

Once you have logged in, it will search for all virtual machines running on the host and generate the list of virtual machines and their respective power states.

You can then perform the appropriate power operation such as a power on, shutdown or suspend using the icons on the right. This can be really useful if you don't have access to vCenter Server, vSphere Client or SSH access to the host but just have a web browser.

To load the Ops Panel script on an ESX(i) host, you will need to do the following:

Note: These instructions are applicable for both ESX and ESXi, but with ESXi, it is important that the commands to copy both the modified index.html and Ops Panel script to docroot are executed as changes are not persisted after a reboot for ESXi hosts.

You can also add this to your kickstart file by appending the lines above in your %firstboot stanza so you automatically get Ops Panel after install. Though this will not give you a full webAccess that classic ESX did but it definitely is a useful way to quickly get to your virtual machines and perform simple power operations using a web browser.

How to Query VM Disk Format in vSphere 5

by // 5 Comments

Prior to vSphere 5, it was not trivial to identify the particular disk format for a given virtual machine's disk. Using the vSphere Client, you would see a virtual machine's disk be displayed as either thin or thick. The problem with this is that the "thick" format can be either:

  • zeroedthick - A thick disk has all space allocated at creation time and the space is zeroed on demand as the space is used
  • eagerzeroedthick - An eager zeroed thick disk has all space allocated and wiped clean of any previous contents on the physical media at creation time. Such disks may take longer time during creation compared to other disk formats.

Users would not be able to distinguish the exact type using the vSphere Client or the vSphere 4 APIs. With the release of vSphere 4, VMware did introduce a new property in the vSphere 4 API called eagerlyScrub which was supposed to help identify whether a virtual disk was allocated as an eagerzeroedthick disk. Unfortunately there may have been a bug with the property as it never gets modified whether a disk is created as zeroedthick or eagerzeroedthick.

The only method that I was aware of to truly figuring out the disk format would be to manually parse the virtual machine's vmware.log file to identify the disk type which I wrote a script for in 2009.

During the vSphere 5 beta, I had noticed the vSphere Client UI now properly displays all three virtual machine disk format: zeroedthick (displayed as flat), thin and eagerzeroedthick (displayed as thick).

Seeing that VMware now displays the three different formats, I wanted to see if it was possible to extract this using the vSphere 5 APIs and not have to rely on the hack of reading the vmware.log files. It turns out that the eagerlyScrub property is now functioning properly when a VMDK is provisioned or has been inflated/converted to the eagerzeroedthick format. I wrote a simple vSphere SDK for Perl script called getVMDiskFormat.pl which allows you to extract the disk formats of all virtual machines connecting to either vCenter or directly to an ESX(i) host.

The script allows for two types of output: console (directly on the console) or csv (creates .csv file)

If you select csv output, by default it will be stored in a file called "vmDiskFormat.csv". You also have the option of specifying the filename by using the --filename flag and providing a name of your choosing.

You can then load the csv file into excel and easily sort through the various disk format types.

All this is already included in the latest version of the VMware vSphere Health Check Report 5.0 if you want a centralize report that includes virtual machine disk format.

How to Automate the Deployment & Configuration of vShield Manager 5

by // 8 Comments

If you have ever worked with VMware vShield Manager, you know that deployment and configuration of the virtual appliance is pretty much a manual process. You can automate the deployment of the vShield Manager OVA using the various vSphere SDK's or the ovftool, but the initial IP address configuration for vSM still needs to be configured manually using the remote console for the very first time.

An easy solution to this problem would be for VMware to create the vSM OVA to support IP address configuration out of the box as part of the deployment options (but why make things easy). In any case, I will demonstrate how you can easily automate both the deployment and the initial configuration of vShield Manager to your vSphere environment.

Before I begin, I can not take credit for coming up with the idea of automating vShield Manager deployment, the credit goes to Alan Renouf. Alan recently contacted me and ask if it was possible to automate the IP configuration. The answer is yes and here is a solution.

One of the main challenges in figuring out how to automate the IP address configuration of vShield Manager was due to the vtysh integrated shell daemon for Zebra that launches by default as part of the "admin" user account. This interface is used to manage the kernel routing and management table and made it very difficult to interface with for any type of automation. I decided manually go through a vSM configuration and then using Knoppix LIVE-CD, I was able to mount up the vSM filesystem and look around to get a better understanding of what was going on. After some investigating, it looks like IP address configuration is stored in /common/configs/cli/zebra.conf, here is an example of what the configuration looks like:

Armed with this knowledge, it was pretty straight forward in developing an automated way of deploying and configuring vShield Manager. I created a script called deployvShieldManager.sh which utilizes guestOpsManagement.pl, vCLI and ovftool. It's recommended that you use vMA and install ovftool to quickly get started. At a high level, the script is doing the following:

  1. Deploy vShield Manager OVA using ovftool
  2. PowerOn vSM and wait 2 minutes for VMware Tools to be ready on the system
  3. Create new zebra.conf, backup the old zebra.conf and upload new zebra.conf using the new vSphere 5 VIX integration
  4. PowerOff vSM to force the configurations to be read in upon next bootup
  5. PowerOn vSM and it is now ready for use

At the top of the script, there are several configuration variables that need to be edited by the user to specify the vSM configuration, including vCenter and ESX(i) host to deploy vSM.

Here is a list of variables that need to be configured at the top of the deployvShieldManager.sh script:

Once you are done updating the variables, you are now ready to execute the script. Before the script performs any changes, it will first prompt the summary of configurations you have specified in the script. Once you are satisfiy, you may than proceed by typing "y" or "yes" to start, or if you would like to cancel, type "n" or "no".

Note: The script will perform some basic validation such as existence of the vShield Manager OVA, ovftool, etc. else you will get an error message and the script will exit.

Next, the script will perform the deployment of vSM using ovftool and proceed with the configuration of vSM once it has been deployed.

Note: If it takes longer to poweron vSM in your environment to get it into a ready state, you may want to tweak the sleep period from 120 seconds (2minutes) to something longer.

At this point, you now should see a new vShield Manager VM deployed and if you take a look at the summary page, you should see the new IP address and hostname configurations.

Now all that is left is to point your browser to the vSM address and you should be prompted to login to vShield Manager management interface.

Instead of manually deploying vShield Manager in your environment, you can now automate the initial deployment and configuration for general use or with VMware vCloud Director. For further automation and configuration of vShield manager, once vSM is online and accessible, you can leverage the vShield REST API.