SolutionOriented Blog

vCenter Mobile Access

[vCMA updated 16-MAR-2011 to include SSL mode as default.]

It’s just a short, 270MB download separating you from managing your vCenter or licensed vSphere host from your mobile phone, Internet tablet or PC’s web browser. This simple virtual appliance performs all of the client API calls to vCenter and presents a web-based user interface that requires only basic HTML – perfect for mobile devices. It’s a bit quirky with DPM (as you’ll see later in the post) but it has a compelling feature list as well in this v1.0 fling from VMware.

The vCenter Mobile Access appliance is quick and easy to install. VMware provides these curt instructions to get you started:

1. Extract the zip file to a temporary directory, for example c:\temp. The files contained in the zip file include :
   * vCenterMobileAccess-1.x.y.z.ovf
   * system.vmdk
2. Launch the VI Client and log into your ESX box or vCenter instance.
3. In the inventory view, select the menu File-> Virtual Appliance -> Import
4. Select the option “Import from file” and browse to the OVF file, for example: c:\temp\vCenterMobileAccess-ovf\vCenterMobileAccess-1.0.0.10.ovf and follow the wizard next steps.
5. In the “End User License Agreement” page, read the license agreement completely, click on the “Accept all license agreements”, and continue the steps.
6. In the “Name and Location” page, provide the name for your virtual machine.
7. Once the wizard completes, a virtual machine will be created. Select the virtual machine and power it on.
8. Once it powers on, you can access the web application from your mobile device browser using the URL http:///vim.
   Once connected, you will see the login screen where you can provide the vCenter or ESX IP address or name as well as username and password.
   

Installation of the virtual appliance is fairly straight forward, but there are a few “gotchas” to be encountered depending on your environment. For instance, if you do not run DHCP in your management or test network, you’re going to need to drop to the console for setup. Also, the default password is extremely weak, so changing it before testing or deployment is imperative. Also, there is an incompatibility in the latest version between the appliance management console (web) and Firefox, although this issue DOES NOT extend to the vCenter Mobile Access application proper.

Detailed vCMA Installation

Here’s a more expansive how-to that addresses some of these issues in deeper detail. To install VMware’s vCMA from the OVF package, I did the following:

1. Extracted the zip file to a network share reachable from my workstation;
2. Logged into vCenter with the VI Client;
3. Selected the menu File -> Deploy OVF Template…
   1. Selected “Deploy from file:” and browsed to the “.ovf” file, selecting it (i.e. vCenterMobileAccess-1.0.0.41.ovf), then clicked “Next >”;
   2. Viewed the OVF Template Details, then clicked “Next >”;
      1. Product: vCenter Mobile Access
      2. Version: 1.0.0.41
      3. Vendor: VMware, Inc.
      4. Download Size: 291MB
      5. Size on disk: 2048MB
      6. Description: The vCenter Mobile Access allows administrators to manage their datacenter environments on-the-go via mobile devices.
   3. Read and accepted VMware’s Technology Preview License Agreement, then clicked “Next >”;
   4. Selected the default VM name, vCenter Mobile Access, and selected a datacenter and folder to place the VM into, then clicked “Next >”;
   5. Selected a cluster (or host) to house the VM, then clicked “Next >”;
   6. Selected a resource pool (optional), then clicked “Next >”;
   7. Selected a datastore to store the VM files, then clicked “Next >”;
   8. Selected the vNetwork to connect the VM’s “Network 1″ interface to, then clicked “Next >”;
      (note: this network must have access to vCenter which may require adjustments to a firewall setting depending on your environment.)
   9. Reviewed the deployment task summary and then clicked “Finish” to deploy.
      (note: wall-clock deployment time was under 3 minutes.)
   10. Finally, the deployment requester changed to “Completed Successfully” and I clicked ‘Close” to complete the process.
4. Before powering-on the appliance, I disabled logging from the “Options” tab of the Virtual Machine Properties page by right-clicking on the VM, selecting “Edit settings…”, clicking the “Options” tab and selecting “General” from the “Advanced” section, then uncheck the “Enable logging” box.
5. Next, I opened the console and powered-on the VM.
   1. Note: vCMA defaults to VMware hardware version 4. For systems with demonstrated compatibility issues with version 4 issues with vMA, or where using backup facilities that use changed block tracking, take this opportunity to upgrade to hardware version 7.
6. Once the appliance has booted, you’ll need its IP address. The vCMA appliance is setup for DHCP: if no DHCP is found, it will self-assign an IP address until one is manually configured. To manually change the vCMA address, I did this:
   1. Opened the vCMA virtual console;
   2. Using down-arrow, selected “Configure Network” and hit the “enter” key;
      1. Selected “n” to disable DHCP;
      2. Entered the vCMA’s intended IP address (i.e. 192.168.100.100);
      3. Entered the vCMA’s netmask (i.e. 255.255.255.0);
      4. Entered the vCMA’s network gateway (i.e. 192.168.100.254);
      5. Entered the primary DNS server for the network (i.e. 192.168.100.15);
      6. Entered the secondary DNS server for the network (i.e. 192.168.200.15);
      7. Declined the proxy server configuration;
      8. Checked and confirmed the IP settings;
         

         Option pages from vCMA management portal.

7. Recorded the management URL from the console screen:
    
   

   Management URL listed on vCMA console sceen

8. Followed the management URL (i.e. https://192.168.100.100:5480) to the vCMA management page. The management portal allows the following options:
   1. Login to the management portal (user is “root” with default password of “vmware”)
      (Note: logging-in with Firefox, you may get the following error:
      You will not get this error with Internet Explorer, Apple’s Safari, Google’s Chrome, Google’s Android Browser and Dolphin Browser for Android.) 
      

      Ooops. Mozilla's Firefox not welcome here...

   2. View System Information;
   3. Reboot the virtual appliance;
   4. Shutdown the virtual appliance;
   5. Check the Network Status;
   6. Change the Network Settings, including:
      1. IP Address
      2. Netmask
      3. Gateway
      4. Preferred DNS
      5. Alternate DNS
      6. DHCP versus Static IP settings
      7. Enable Proxy Server:
         1. Proxy Server address
         2. Proxy Port
9. Logged-into the root console to change the default password from “vmware” to something more secure:
   1. From the console, select “Login” and hit the enter key;
   2. Logged-in using “root” at the “login:” prompt;
   3. Entering “vmware” at the “Password:” prompt:
   4. Changed the password by issuing the “passwd” command and followed the prompts:
      

      Using "passwd" to modify the vCMA root default password.

   5. Logged-out by issuing the “exit” command.
10. Installation is now complete.

Using vCMA

With the installation complete, accessing the vCMA simply requires passing the URL of your vCMA appliance to the mobile browser of your choice. Assuming your vCMA is named “vcma” in DNS, the URL would be:

http://vcma/vim

Without the “/vim” ending the URL, you’ll see the Apache Tomcat “successful installation” page. With the “/vim” extension, you should see the following:

vCMA Login Page

To login to your vCenter server, you’ll need to enter the IP address or the host name of your vCenter server. If your vCMA appliance does not have DNS access, you must use the vCenter IP address. For username, you must enter a vCenter user with access credentials sufficient to operate the vCenter functions required in the session. If your vCenter is a domain member, the domain is not needed in the username field. Enter the password matching the specified user as usual.

SOLORI’s Note: vCMA can be used to manage individual hosts outside of vCenter’s control. This is NOT recommended for hosts that are concurrently managed by vCenter as it may create disruptions in vCenter’s control. However, to control a non-vCenter managed host, use a local account configured within ESX/ESXi that has the rights to perform the needed tasks (typically “root” or other “root-created” accounts). This mode could also be useful in scenarios where vCenter is run as a VM and inadvertently becomes disabled or unavailable.

The vCMA “home” page displays the basic “menu” of features as named icons. These features are Search, Migrate, Hosts and Clusters Inventory, Scheduled Task Manager, Alarm Viewer, Event Viewer, IP Tools and Client Options. If your vCenter is part of an SRM setup, an SRM control option will be present as well.

vCMA "home" page

With vCMA installed and the proper credentials (and vSphere license) you can manage VM migration from your mobile phone, MID, etc – anything that supports HTML and forms processing. Here’s an example of vCMA in action performing a VM migration in SOLORI’s DRS lab:

SOLORI's vCMA virtual machine migration example.

VMware’s vCMA is not the most secure appliance in the world, but it is not intended to be. vCMA is intended to be a light-weight layer between vCenter and web-only devices like cell phone (iPhone, Android, etc) and provide an API translation layer for more “optimized” visualization tools (i.e. Web 2.0+ application, native phone/tablet apps, etc.). Consider the “/vim” application a proof-of-concept as it has not changed much in its two years of existence.

vCMA and Cached Credentials

For convenience and security, the “/vim” web application allows for four levels of credential caching:

1. None
2. Server name only
3. Server and Username only
4. Server, Username and User Password

The caching control is contained in the “client-config.xml” file for the “/vim” application. To edit this file, login to the vCMA – as root – using SSH (or putty.exe, etc.) and do the following:

[root@vcma ~]# cd /usr/lib/vmware/mobile/tomcat
[root@vcma tomcat]# ls
apache-tomcat-6.0.28
[root@vcma tomcat]# cd apache-tomcat-6.0.28/webapps/vim/WEB-INF/classes
[root@vcma classes]# vi client-config.xml

Note, the folder “apache-tomcat-6.0.28″ may be different depending on the vCMA version, so “ls” to whichever “apache” folder is inside the “tomcat” directory. When editing the XML file, look for the “credentialCacheMode” tags. The default section currently looks like this:

<!--
 The supported values of Credential cache mode are:
 CACHE_NONE,
 CACHE_SERVER,
 CACHE_SERVER_USERNAME, or
 CACHE_SERVER_USERNAME_PASSWORD.
 -->
 <credentialCacheMode>CACHE_SERVER_USERNAME</credentialCacheMode>

Note that the current mode is “CACHE_SERVER_USERNAME” (option 3). The other modes are listed in the text above the tag section. Change the current mode by replacing the value within the tags to the value that matches the caching mode you wish to use.

Securing vCMA

Being HTTP-only, vCMA doesn’t lend itself to secure computing over the public Internet or untrusted intranet. Instead, it is designed to work with security layer(s) in front of it. While it IS possible to add HTTPS to the Apache/Tomcat server delivering its web application, vCMA is meant to be deployed as-is and updated as-is – it’s an appliance. Therefore, the following recommendations are made if deployed beyond the lab:

1. Place vCMA in a DMZ between with specific policies for vCenter(s)/hosts it is allowed to manage;
2. Access vCMA via VPN for external hosts or through HTTPS proxy for the “/vim” level and below;
3. Protect the management ports, SSH and Tomcat layers;
4. Use the CACHE_NONE option for the “/vim” web application to limit masquerading;

vCMA Quirks

The major complaint I’ve had with vCMA is with DPM clusters. In the latest version, it recognizes that a host is in “sleep mode” but only when view that host’s “details” page. From the inventory or search list, the host appears solely as “(NotResponding)” and fails to show the familiar “sleeping” icon – see below:

vCMA host inventory showing host in running, standby and disconnected states. Note that disconnected state shows as the familiar "maintenance" icon and standby shows as the familiar "disconnected" icon.

The worst aspect of this particular quirk is that vCMA actually allows you to place a DPM host to sleep. The catch is that once it’s asleep, it doesn’t know how to wake it up. This is confirmed by looking at the “action-config.xml” and “client-config.xml” files for “/vim” that lists the potential host actions for “/vim” as follows:

<!--  Host operations configuration from client-config.xml -->
 <feature id="9" name="host" entity="HostSystem">
 <operation id="shutdownHost_Task" enabled="true" />
 <operation id="rebootHost_Task" enabled="true" />
 <operation id="standByHost" enabled="true" />
 <operation id="enterMaintenanceMode_Task" enabled="true" />
 <operation id="exitMaintenanceMode_Task" enabled="true" />
 <operation id="connection" enabled="false" />
 </feature>

<!--  HostSystem Actions from action-config.xml -->
 <action name="hostsnclusters"
 type="com.vmware.vim.mobile.action.HostsAndClustersAction">
 </action>
 <action name="shutdownHost" type="com.vmware.vim.mobile.action.HostOperationAction"
 parameter="shutdownHost">
 </action>
 <action name="rebootHost" type="com.vmware.vim.mobile.action.HostOperationAction"
 parameter="rebootHost">
 </action>
 <action name="standByHost" type="com.vmware.vim.mobile.action.HostOperationAction"
 parameter="standByHost">
 </action>
 <action name="enterMaintenanceMode" type="com.vmware.vim.mobile.action.HostOperationAction"
 parameter="enterMaintenanceMode">
 </action>
 <action name="exitMaintenanceMode" type="com.vmware.vim.mobile.action.HostOperationAction"
 parameter="exitMaintenanceMode">
 </action>

Note that while both configuration files have instances for “standByHost” – the host standby operation that has been tested to work – neither have reference to waking the host. In “Version 1.0″ of the VMware vCenter Mobile Access Installation and User Guide the manual shows the following about removing hosts from standby:

Host operations as listed in the Installation and User Guide

Note that the Guide indicates that the standby function “either takes the host out of standby mode or puts the host in standby mode” depending on the current state. Not only does this not happen, it appears to be omitted from the vCMA appliance’s capabilities altogether. In fact, when looking at the HTML source of host details for a sleeping host, there is no action connected to the “standby” icon. While this is a big deal only for DPM users, the ability to “sleep” the host with no reciprocal ability to “wake” the host is a problem for them.

However, I just didn’t stop there for DPM. I looked at the URL for the standby function and noticed that a running host has an active standby icon (action linked to the icon) in its details page, but a host in standby had no action connected to the icon. Naturally, I looked at a running host’s standby URL and attempted to reformatted it to specify the sleeping host:

http://vcma/vim/action.do?id=HostSystem|host-835&action=standByHost

This action would be consistent with the documentation’s representation of the “resume” function. However, this approach produced an error within vCenter complaining that the operation was not allowed in the current state (about what you would have predicted):

Can't standby a host in standby...

Digging deeper, it is clear from the XML configuration files that the java class directing host standby operations is available to us based on the following class descriptor:

com.vmware.vim.mobile.action.HostOperationAction

That gives us a place to look for a possible for a match to enable the host to “wake” from standby. Taking the class and performing a strings search, I found a “powerUp” token that wasn’t matched to an action declared in the configuration files. I also identified a task called “powerUpHostFromStandBy_Task” which seemed to indicate that the capability was coded into the class, just not enabled in the client configuration.

Heading down the rabbit hole, I added a new action and matching client configuration to the “/vim” application that would pass the “powerUp” token upon execution. This was a hack at best but still worth the effort just to see if this was a GUI omission or an incomplete function. Just to see if it was a possibility, I reconfigured the “standByHost” action with the parameter “powerUp” (matching the parameter in the decoded action event) and re-sent the “standByHost” command manually. No joy… guess it will need to wait for the next version. In the meantime, I have provided the details of this issue to VMware for follow-up.

Conclusion

There are plenty of things to like about vCMA: it’s light-weight, stupid-easy to deploy and functional enough to get primary, non-VM-console operations handled. There are some interestingly named hooks I discovered in the action class that I will investigate further in a future blog. Beware of the DPM/sleep black hole – you won’t be able to wake-up hosts that have been successfully put to sleep with vCMA, however you can maintenance mode a host as well as restart one. Suffice to say that – limitations and all – vCMA should have a place in your lab and potentially in your enterprise stack.

To download vCMA, see VMware’s “fling” page on the appliance.