VMware Lab Manager vs. VMware Cloud Director:
Another Case of "Spanners" and "Hammers?"

VMUG Voice featured editorial contributor Mike Laverick, who resides in the United Kingdom and has been using VMware technologies since 2003, manages a popular blog and also writes for TechTarget and its website. In this issue, Laverick compares VMware Lab Manager and VMware Cloud Director and analyzes the implications for utilization of each.

Last year it was my great pleasure to speak for the first time at VMworld, and I spoke on a subject dear to my heart: VMware Site Recovery Manager. My theme for the session was “Spanners and Hammers,” and it was all about using the right tools for the right job. Of course, it occurred to me only about five minutes before the start of the session that my largely American audience might not have a clue what a “spanner” is. You see, as the famous writer George Bernard Shaw once noted, the United Kingdom and the United States are sometimes “separated by a common language.” So, for the uninitiated, a spanner in the UK is what Americans would call a “wrench.”

One thing I have seen time and time again in my career is that IT customers often make a kind of “category error” when it comes to selecting technologies. They often buy a technology that has a job of “X,” and then apply it to problem “Y,” for which it was never designed – just like a poor construction worker would use a hammer to tighten up a bolt or a wrench to drive home a nail into a piece of wood. In the case of VMware Site Recovery Manager, I often find customers trying to re-engineer it into a “high availability” solution, and similarly I find customers trying to stretch out a VMware HA cluster across sites and to re-engineer it to be a disaster recovery solution. It kind of reminds me of my early days of supporting end-user applications where someone would try to use a Lotus spreadsheet (yes, I really am that old!) instead of a database.

Initially, I thought the same situation was playing itself out with VMware’s Lab Manager (LM) product and its IaaS solution VMware Cloud Director (vCD). Within months of vCD’s launch, bloggers and industry watchers started to speculate that, given the apparent overlap between the two products, the long-term future of LM could be in jeopardy. Our industry thrives on such speculation so you could, if you wish, dismiss this talk as insubstantial. However, these commentators do make very compelling arguments, and I think perhaps the strongest comes from one of my fellow vExperts, Jason Boche, who worries that a lack of development investment in the LM product indicates that VMware may not be fully committed to its long-term future. (And Jason is not alone; for example; Ian Koenig of itsjustanotherlayer.com has expressed a similar though less detailed opinion on the subject.)

What really made me sit up and take notice is when customers started to email me, seeking my advice on whether they should use LM or vCD. My gut reaction was to start to get very worried. Initially, for me, it was like being asked if they should take a shotgun to catch fish. For example, here’s how one of my customers put it:

“The site I am on is contemplating a Lab Manager environment. They have not purchased it yet. If it was you, would you entertain Lab Manager at this point in time or would you go for vCloud Director? I am not fully clued up on vCloud so am not really sure if it is a direct replacement, or whether there are scenarios that would force the use of Lab Manager. What do you think?”

I think the key reason why folks are raising this question is that the looks and feels of LM and vCD are quite close. I think it’s quite similar to some of the early “confusion” surrounding VMware’s Lab Manager (LM), Lifecycle Manager (LCM) and Stage Manager (SM) products back in the Vi3 days. These management tools did have very similar uses (especially LM and SM), and occasionally customers would get one confused with the other.

The other area of overlap concerns the VM provisioning process. Both LM and vCD allow a developer or end consumer (that’s my term to describe a vCD end-user) to log in and create VMs as they need them, without recourse to accessing vCenter or needing the vSphere Client installed. So there is a certain amount of “self-service” that both products provide – and this self-service is another layer of abstraction on top of the standard virtualization provided by vSphere. Both LM and vCD enable us to isolate the developer or the end consumer from the nitty-gritty, day-to-day machinations of vCenter, Clusters, Resource Pools, and Virtual Switches – to provide a flexible, on-demand computing environment.

Technical differences remain between the two products. First, LM is a mature product that has been around from some time. It was actually a product developed by Akimbi that VMware acquired sometime ago. LM was designed from the ground up to solve the challenges of running lab or software testing/development environments. Second, LM supports “linked clones,” whereas currently vCD does not. In fact, LM has support a linked-clone feature before it was even present in technologies like VMware View. It forms the bedrock of Lab Manager that allows developers to “check in and check out” many different collections of VMs without wasting disk space. Third, the licensing requirements for LM differ considerably to vCD. You can run LM on any edition of vSphere your pocket can afford, and while it is possible to run vCD on top of a standard edition of vSphere, the recommendation from VMware is to run vCD on top of vSphere Enterprise Plus. The main reason for this recommendation is to allow vCD to leverage Distributed vSwitches, as without them portgroups would need to be created manually or by PowerCLI script on each and every ESX host in a cluster. I think it would be a major ask of VMware customers to have to upgrade to a different LM tool, and at the same time upgrade their vSphere licenses as well.

For some time, LM has solved the networking challenges by using cross-linked fencing. This is a clever piece of NAT-ing that allows VMs with the same IP address to be checked out by multiple developers on the same network – without creating IP conflicts. Theoretically, vCD could achieve similar outcome by using its implementation of vShield appliance. So there is some work to be done give vCD feature parity with LM – but in the parlance of vCD, I don’t think it will be long before people are creating “Organization Virtual DataCenters” for the test and development teams.

What really struck me in customers’ emails was that they contained no descriptions of the problems they were trying to solve. The problem seemed to be more about what technology they should buy. I don’t think you should ever commit to purchasing a product without knowing the business challenges you are trying to address – as you run the risk of purchasing the wrong technology altogether. So, given this speculation, I thought it would be interesting if I could ask the Private Cloud Product Team for its position. This is the reply:

Both vCenter Lab Manager and vCloud Director provide capabilities to pool infrastructure resources across vSphere hosts and make them available for use through standardized templates on an on-demand self-service basis. These capabilities help IT reduce the costs of operating virtual infrastructure and enable end users to consume them with greater agility.

The products differ in the targeted scope of deployment. vCenter Lab Manager is designed for functionally specific uses, like dev/test, and is limited to managing a single cluster with limited network isolation. vCloud Director, on the other hand, is designed to deliver enterprise infrastructure-as-a-service with a web-based API that enables private and public clouds to operate on the same platform. vCloud Director has been architected to manage multiple clusters and up to 10,000 VMs. vCloud Director also ships with vShield technology that enables greater network isolation and protection for multiple tenants of the cloud. This significant increase in scale and security makes vCloud Director a better choice for building enterprise hybrid clouds that may span multiple teams and may span both private and public resources.

Over time, functionally specific uses, like dev/test, are expected to be delivered on the same enterprise infrastructure-as-a-service platform as other applications that move to the cloud.

I think if you look at that last sentence we can see the real future of technologies like Lab Manager is going to be the Cloud. The only thing that VMware is holding back at the moment is when that will be. But if you think about it, we are already seeing that now, with some developers preferring to spin-up VMs as they need them from the likes of VMware’s partners like Terremark.

I personally don’t see the Private Cloud ever being able to offer the same cost savings of the free market. The economies of scale that external provider brings are likely to mean that the per-VM cost of Public Cloud VMs will be less than the price of internally supported VM in the Private Cloud. As we know when it comes to temporary development resources that are spun up on demand (particularly for scalability tests), the cost per VM is going to be pretty critical. Similarly, where security and internally guaranteed SLA/QoS is a high priority, I think most large corporations would consider an internal Private Cloud as a more suitable platform of their workloads.

Editor’s Note: Mike Laverick, a new contributor to VMUG Voice, runs a popular blog called “RTFM Education” and writes regularly for TechTarget and its SearchVMware.com site. He has written several free guides and commercial books about VMware Virtual Infrastructure3 and vSphere4. In recent years, he has diversified into VMware Site Recovery Manager and VMware View. He runs a weekly virtualization podcast called the “Chinwag” and “Vendorwag,” and if you tune each week to John Troyer’s VMware Communities Roundtable podcast, you’ll hear him there as well. He also produces a monthly round-up of news in the virtualization space called vNews.

Are you interested in reaching out to Mike Laverick and/or contributing your insights to VMUG Voice? E-mail the editor to get involved.