Goodbye Mr. Herrod

SearchserverVirtualization published an article today called “Experts weigh in on CTO Herrod’s departure, future of VMware” where I have been quoted in regard to Steve Herrod’s departure from VMware.

While the quote itself is correct, I feel that there is a need to further expand on what I said, in the context it was given in.

So here it is, my entire response:

My reaction to Steve Herrods departure is probably on par with just about everyone else’s, one of surprise. While I cannot comment on the internal workings of VMware, Mr. Herrods impact and influence on their public image has been immense and his shoes will be very hard to fill. That being said, I cannot imagine that VMware does not have a plan in place for this new post-Herrod era, it may be news to us, but I’m certain that this is something that has been known internally for quite some time.

Mr. Herrod has been very vocal, and influential, and replacing him is not something VMware should treat lightly. Steve put much emphasis on the T in CTO, and whoever is to replace him needs to be on par with the technical level of his predecessor, after all that’s where mr. Herrod excelled. He knows the tech, and knows how to market it both to executives and techies alike, no small feat in itself.

On the other hand, VMware does have as a very passionate and vocal community, and I’m sure that there is someone lurking in the shadows just waiting for the opportunity to step up into the light and move VMware forward. Each time high profile executives has left VMware, and there has been a few, VMware has excelled and not looked back.

I hope, and believe that the same will be true this time around, after all VMware is driven by engineers not marketing or executive level positions. The tech is at heart, at least that’s my impression.

Lastly, I would like to thank Steve Herrod for his tenure at VMware. He´s been a leading light and a reliable voice in an ever changing world. I wish him the best of luck in his future endeavors, not that I think he’ll need it, people of Steve´s calibre seldom needs luck.

(yes, yes, I know. It should have been Dr. Herrod)

vCenter Operations Manager and vCenter Deployment Dependency

In order to be able to deploy vCenter Operations Manager, the ESXi host it is deployed to needs to be managed by a vCenter. At first glance, that seems like a fair and pretty straight forward requirement, right? But, is it?

While I can see the need for a vCenter in the environment that vCenter Operations Manager is supposed to monitor, I don´t understand why the host you want to deploy the vApp on has to be managed by a vCenter instance as well?

I encountered this exact scenario at a client site today; What do you do if you want to deploy vCenter Operations Manager on a standalone ESXi host, and have it monitor a production vSphere environment, which has a running vCenter installation?

The vCenter Operations Manager 5 Deployment and Configuration Guide  clearly states that in order to deploy and run the vCenter Operations vApp vCenter Server 4.0 U2 or later is required:

vCenter Server and ESX Requirements:
The vCenter Operations Manager vApp requires the following vSphere environment.
vCenter Operations Manager is compatible with:

  • System that serves as the target of data collection: VMware vCenter Server 4.0 U2 or later
  • System running the vApp: VMware vCenter Server 4.0 U2 or later
  • Host running the vApp: ESX/ESXi 4.0 or higher

And in the Deploy the vCenter Operations Manager vApp section of the same document:

  • Do not deploy vCenter Operations from an ESX host. Deploy only from vCenter Server.

The reason why the client wanted to deploy vCenter Operations on a standalone, unmanaged host, was pretty simple; They are experiencing some rather serious performance issues, and wanted to use vCenter Operations Manager to help identify the bottlenecks and document them, but did not want vCenter Operations Manager itself to influence the performance of the production cluster(s).

I was able to “work around” the issue by temporarily setting up a vCSA, in trial mode, register the ESXi host, deploy the vCenter Operations Manager vApp to the new vCSA, configure it and then subsequently shut it down again. In fact, there is even an option in the configuration to not monitor the vCenter instance it´s deployed on, so someone else must have had some mildly similar thoughts at one point.

While this will work, its not ideal having to go through loops like this to deploy a management solution. I´ll happily admit that this is a fringe case, and not the most common deployment scenario, but I would still like to see VMware do something about the vCenter requirement for the host the vApp is deployed on.

Requiring vCenter for the hosts and cluster it´s monitoring is fine, and expected, but why does the host it´s deployed on require it?



Dell (VKernel) vOPS Server Explorer 6.3 Released

vOPS 6.3 Environment Explorer
vOPS 6.3 Environment Explorer

Yesterday fellow vExpert Mattias Sundling gave me a little pre-release briefing of the new Dell/VKernel vOPS Server Explorer 6.3 release.

While I don´t normally do press release posts like these, I´m willing to make an exception in this case.

Not only is vOPS Server Explorer 6.3 available in a free version, with the familiar tools from previous versions, the new release also comes armed with a couple of new interesting tools in the suite:

  • Storage Explorer 
    • Extensive storage performance and capacity views across datastores and VMs
    • Identifies critical datastore issues such as overcommitment, low capacity, high latency, VMFS version mismatch
    • Identifies critical VM issues such as low available disk space, high latency and throughput
    • Allows user to sort on any metric to find specific issues relevant to them

  • Change Explorerchange-explorer
    • Lists all changes that occurred to datacenters, clusters, resource pools, hosts, datastores and VMs within the last seven days with associated risk impact
    • Allows user to filter on object name, user and type to find specific changes
    • Number of changes also represented graphically over time to be able to see when they are occurring

Both of these are new tools in v6.3 of the vOPS Suite, and incredible value for a free product.

The familiar tools from previous versions are still available too:

  • Environment Explorer
    • Identify critical VM configuration errors such as memory limits and old snapshots
    • Recognize performance bottlenecks
    • Detect inefficiency/waste created by VMs with resource over-allocation
    • Find available capacity expressed as the number of additional VMs that can be deployed

  • vScope Explorer
    • Visualize performance issues in VMs and hosts across the environment
    • Assess environment-wide host capacity
    • Spot inefficient datastores and VMs
    • See all VMs, hosts and datastores across many vCenters and data centers on one screen

  • SearchMyVM Explorer
    • Search for VMs, hosts, clusters and resource pools in an environment
    • Create and save advanced searches
    • Export search results in XML, CSV and PDF format


In addition to the new tools, vOPS™ can connect to and monitor Hyper-V (Requires System Center) and RedHat hypervisors from a single appliance deployed once in your infrastructure.

The vOPS minimum requirements are also not that bad compared with other monitoring solutions on the market:

  • 2 vCPUs
  • 4 GB of memory
  • 64 GB of storage space
  • VMware ESX 3.0 or vCenter 2.5 or higher
  • Microsoft SCOM 2007 R2 or higher + SCVMM 2008 R2 or higher
  • Red Hat Enterprise Virtualization Manager 3.0 or higher

Watch the videos above, and if this is something you find interesting, head on over to the vOPS™ Server Explorer site and download your free copy now!