I can’t wait to be able to blog about the final product.

These last two calls were unusual, not just because someone called me and they usually don’t.  Last week, an IBM representative followed up on a information request I made six months ago. He just wanted to make sure that I received what I requested.  Earlier this week, a Hitachi rep followed up on an information request I made in April, 2008 — eleven months ago.  He just wanted to answer any questions I might have had.

Times must be pretty tough for these vendors to work their way down to leads from me that are 6-11 months old.  I felt like telling them that I purchased $1,000,000 of competitive product just last week and wished they would have called a few weeks sooner.  However, these tough economic times justify a little sympathy.

When I first read the articles I thought, “Fortune doesn’t get it.  That isn’t cloud computing.”  Upon further reflection I wondered if maybe my definition is too restrictive.  Maybe cloud computing is a category that includes multiple types of computing, including SaaS.  I wonder if it is time for someone to define a cloud computing taxonomy.

The initiative is dubbed VESI(TM) and the Virtualization EcoShell product is based on the popular PowerGUI.  I have a little experience with Powershell and really like its power, extensibility, and uniform syntax.  PowerGUI provides a nice UI for it. 

I have been expecting Visioncore to leverage PowerGUI, which was developed by their parent company, Quest Software.  Managing VI with PowerShell makes so much sense.   One advantage of PowerShell is that many virtualization professionals wear a number of hats, including Windows Administrator.  PowerShell is compatible with many (most??) Microsoft enterprise products and with VMware so VI professionals can learn a single scripting language and use it many places.  Although to be fair, other scripting languages are popular, too.  Perl comes to mind, and a number of Perl scripts are available from the VMprofessional web site.  However, Microsoft hasn’t and won’t adopt Perl.

I have spoken with a number of virtualization professionals, and the trend is definitely towards scripted automation.  The term “automation” brings speed and lower costs to mind, and speed and reduced costs are certainly beneficial.  However, another key benefit is repeatability.  The easiest way to make sure VI is configured correctly is to use scripts that can be debugged once and used many times.  I think repeatability is perhaps the most important benefit. 

VESI will certainly accelerate the automation trend.  It all makes sense to me, except for one thing.  Why does VESI include a tortoise in their logo?  When I see a tortoise I think of “slow”.   In fact, one of the dictionary definitions for tortoise is “a very slow person or thing”.  (I know.  EcoShell and tortoise shell.  It still means slow to me.)

A small sample of problems that get mentioned include:

• VMs with active connections to “internal-only vSwitches
• VMs with CPU affinity set
• Clusters with DRS and/or HA disabled
• Clusters with incompatible hardware
• Old VMtool versions

I often hear comments along the lines of, “There are tons of configuration parameters, and I have to hunt and peck through lots of dialog boxes to see them.  Sometimes it is like looking for a needle in a haystack.” 

This made me wonder just how many VI configuration parameters exist.  I asked one of our engineers who is familiar with the SDK to look into it.  He told me that roughly each host has 900+ parameters, each VM has 550+ parameters, and there are 1,900+ other parameters.  This means that a relatively small installation with only two clusters, six hosts, and 60 VMs will have more than 35,000 configuration properties, and large installations can have hundreds of thousands.   

Tripwire’s ConfigCheck and OpsCheck utilities help from a security and VMotionability point of view, but the configuration overload appears to warrant a more comprehensive solution.

I have spoken with a number of VMare professionals who have spent too much time diagnosing VMotion problems.  They complained that the relevant settings are scattered about, and they need to check settings for all the applicable hosts and VMs.  This is a tedious task that is ripe for automation.  OpsCheck analyses ten of the common hostconfiguration VMotion configuration culprits and ten of the common VMVMotion configuration culprits and reports the results.  OpsCheck is so easy to use that even a caveman product manager can do it.  I ran it against one of our clusters and got the following report (with IP addresses obfuscated).  Trouble shooting guidance is available for each discovered incompatibility.

Please give OpsCheck a try and then post your comments on our community.

We are running as fast as we can, but I want to take a minute to reflect about our friends who have helped us by kicking the tires on our early release of the free utility and on our beta community.  Nearly 70 people, both inside and outside of Tripwire, have joined the community and provided invaluable feedback.  When they encountered issues they took the time to report them to us and they were patient while we made improvements.  Thanks!

You may be familiar with phrases like “go ugly early” or “fail early and fail small”.  The idea is to get early feedback from users and make lots of incremental improvements.  This depends on people who will take their time to use less-than-perfect products and provide timely feedback.  I am amazed at people’s willingness to help when asked.  We will do more of this in the future.  Mo beta is betta!

One of the challenges as a product manager is to determine how much functionality to include in afree utility without cannibalizing our commercial products.  In the case of ConfigCheck, I decided that it should test ESX host’s security compliance based on VMware’s Infrastructure 3 Security Guide.  Tens of housands of people have download and used ConfigCheck, and we frequently get feedback about its value.  Some users have requested that we enhance ConfigCheck to support CIS and DISA standards as well as VMware’s security guide.  However, I am unlikely to add CIS and DISA support  as I walk the balance between offering real value in a free utility and offering significantly more value in our commercial product, Tripwire Enterprise which supports CIS and DISA standards as well as the ability to tailor tests, manage waivers for failed tests, and more.

Next week we will launch another free virtualization utility.  Like ConfigCheck, the new utility will offer significant value.  However, I want to make sure we leave some headroom for future commercial products.  Any way you look at it, decent free utilities offer pretty good bang for the buck.

This week while researching vMotion configuration issues, I encountered a situation where a user had DRS and HA enabled on a cluster that contained six hosts.  Five of the hosts were consumed to about 40%, but one of the machines wasn’t running any VMs at all.  Additionally, the user had multiple VMs that were cloned and he had selected to be created on different hosts in the cluster.  The user expected the VMs to balance themselves across all hosts in the cluster, but clearly this wasn’t the case.

It all sounded pretty normal to me, except for the part about one host not running any VMs.  Digging in a little deeper it was discovered that the DRS Automation Level was set to manual and the cloned VMs all had attached CDROMs and serial devices.  Any of these was enough to prevent automated load balancing from working. 

I have heard of other users with vMo inhibitors.  One had a 64-bit VM that wouldn’t vMO because he had a bit set wrong in one of the host’s BIOS.  During a training class, one student confessed that he hadn’t been able to get vMo to work for more than a year.  It was a big part of his reason for taking the class.

Clearly vMotion has lots of configuration dependencies and it is can be very difficult to get them all configured correctly.  But once configured correctly, VMs can quickly move from host to host as need to balance the load.  After you get it set up the challenge is knowing where the VMs are at any point it time.