Frustration with Lab Manager

A large part of my new job has been helping with architect a large VMware Lab Manager 4 implementation.  This has proven to be fairly annoying when deploying Lab Manager in a big way.  It is important to keep in mind that the main design challenge and constraint of nearly all virtualization solutions is the back end disk, configured in VMware as “Datastores.” Some of the main frustrations we are currently facing:

  • Lab Manager blatantly disregards VMwares own best practices when it comes to disk allocation – we are talking about 2TB LUNS as a minimum and facing the issue of using VMFS extents.  Horrible!  You are almost forced to use NFS, which brings more support complications to the table as you can no longer rely on calling VMware as the primary support vendor.   How this can be when VMware sells and and supports it?  You would think VMFS would be the recommended file system for any VMware solution until they provide the ability to create and maintain NFS Datastores from within vCenter.
  • You can’t use thin provisioning in Lab Manager. Arguably, this would be more useful than Linked Clones, which just create more management headaches than they are worth in a bigger deployment.  I am not alone here in thinking this.  We are deploying unique VM’s with ~200-500GB of auxiliary disk.  Having this all thick provisioned upfront is harmful, especially as users have the ability to make clones of these – or even worse, check them into the library where they would take up that space again and be *required* to be on the same Datastore.
  • Even though Lab Manager devs are well aware of how they are bound by datastore limitations and know full well the way that vSphere overcomes many of those challenges, they don’t provide a way to seamlessly use storage vMotion either within Lab Manager or external to it.
  • Lab Manager could provide for automatic load balancing for Datastores and Networks, but it doesn’t.  Instead we have to trust users to do this for themselves.  That’s just silly, the users don’t care about these things and therefore no amount of training will get them to do this on a consistent basis.  I’ve already mentioned that we can’t fix overloaded Datastores without user impact, and Lab Manager doesn’t even help us preempt it.
  • It would be great if we could take actions on flags, for example once a datastore reaches 70% full we disable to the ability to create VM’s on it.  That would help keep us away from the situation where a LUN drops offline because it is packed to the gills.
  • Disable Linked Clones all together.  They make it more complicated than its worth with 100′ s of self provisioning users and tens of Datastores.  It also incredibly inhibits VM mobility.
  • A way to have a centralized template store that admins can put VM’s on but no one else can.

The items above are really inhibiting our ability to make good use of Lab Manager.  It is clear that this piece of software was not built with large scale deployment in mind.  It also features too many design compromises that hamper the overall value of running vSphere as a whole.  This is epitomized in a conversation I just had with my boss.  When talking about Lab Manager, we are constantly talking about the problems it is causing us.  With vSphere, we are talking about how the technology allows us to over come challenges.

We need a solution not a constraint, dammit.


1 thought on “Frustration with Lab Manager

  1. Ian

    Hi Nat – I just noticed your post. If you want to think about a cloud service to augment or replace an in-house deployment, drop me a line at We see customers struggle with storage all the time and then switch to Skytap to avoid these headaches



Leave a Reply

Your email address will not be published. Required fields are marked *