Resource Reservations in a Virtual Lab

A virtual lab management solution allows end users to access centralized lab infrastructure to create and deploy multi-virtual machine configurations in an on-demand and self service manner. In this context, do resource reservations in virtual labs help?

Resource Reservations Hinder the On-Demand and Self-Service Model of Virtual Labs

Here are some considerations as you think about resource reservations and their relevance in your virtual lab:

  • Reservations encumber the end users – Virtual lab management solutions are geared towards solving volatile and on-demand lab infrastructure needs of end users. For example, a QA engineer discovers a bug and needs to pass to the developer – who can then run the configuration to evaluate and fix the bug. Or, a technical support engineer who needs to spin up a configuration as they are speaking to the customer on the phone.  Imagine if the developer or the technical support engineer had to reserve resources prior to running the configurations! How troublesome would that be?
  • Reservations can be easily misused – Users in your virtual lab can easily reserve resources “just in case” it is required. Are resources freed up/delegated to others at the right time to avoid a skewed view of the lab capacity due to over-reservations?
  • Reservations are typically useful for a hosted virtual lab service provider – Reservations of a resource imply scarcity of the resource. So, if you are with a hosted virtual lab provider, it is likely they are going to ask you to reserve resources – because as a provider they have SLAs to meet and don’t want to end up in situations where a sales engineer walked into a client to find that s/he is second in line to deploy a configuration. Or an instructor ready to start a training class with paying students is made to wait by a hosted virtual lab provider. Net-net, it is a feature that the hosting provider primarily benefits from and asks its users/subscribers to live with it.
  • Thoughts about Resource Reservations from Andrew Binstock – Andrew Binstock some time ago (around 2.5+ years ago) wrote about the downsides of resource reservations in virtual labs in this article. He writes:

…And because the reservation system is unforgiving, it is more of a pain in lab contexts than a benefit. Moreover, given the low price of hardware these days, most sites will choose to add a few boxes to their virtualization platforms if they don’t have enough capacity, rather than impose a reservation system.

  • Thoughts about Resource Reservations from VMwareThis post references VMware’s thoughts on resource reservations in virtual lab systems and refers to it as a bug being made to look like a feature.

James Phillips, VMware’s senior director of lifecycle solutions, responded to this criticism by saying that Surgient’s scheduling requirement is “a classic case of a vendor trying to make a bug look like a feature. … Surgient requires scheduling lab time because it takes forever to deploy a Surgient configuration to the server pool.”

“Instead of having users wait around for up to an hour for a Surgient configuration to be ready to use, Surgient requires that they schedule a time for the configuration to be deployed. This way, the configuration is ready when the user’s time comes,” Phillips said. “This is great if you are running a training class tomorrow, not great at all if you just built a software system and need to run a quick test on it.”

At VMLogix we have chosen consciously not to build lab reservations as a feature into our LabManager product – simply because we did not believe that it was the right design decision. I suspect the same thought process was held at VMware as well – since their competing product kept away from burdening users with this capability. Instead, we have chosen to spend our time and energies on building tremendous flexibility into the deployment and scheduling of jobs.

As a Virtual Lab User, You’re Not Looking for Reservations – You need Flexibility in Job Deployment and Scheduling

With VMLogix LabManager, we have built the following capabilities and flexibility for end users to schedule and deploy their jobs:

  • Job deployment with priority: A deployment job with high priority will be given preference over one of lower priority at deployment time if both are queued
  • Easily launch multiple deployments: With a simple slider movement, a user can deploy a job configuration multiple times (e.g., if multiple testers need to run their test cases on the same environment, the admin can give all testers access to their own environments easily)
  • Job deployment at a specific date and time: Users can specify a date and time when the job deployment is to occur (by default they can deploy it immediately for on-demand, self serve provisioning)
  • Job deployment lease time: Users can specify the job deployment lease time (i.e., a deployment job cannot continue to run longer than a certain period of time) and this can be configured for every job deployed. Users can also specify the action to be taken upon job lease expiry
  • Job queuing: Users can queue a job in LabManager so that the job runs as soon as the resources it needs become free/available
  • Job Auto Completion and Action on Error: User can specify that LabManager release the guest VM roles once all the job operations are completed. Also, users can specify the action to be taken in case there is an error in the job
  • Job deployment on specific hosts: Administrators can reserve hosts exclusively for certain users/teams

Several customers have found the job deployment and scheduling flexibility in VMLogix LabManager as a powerful and valuable differentiator.

Job deployment leases in VMLogix LabManager

Job deployment leases in VMLogix LabManager

Job scheduling in VMLogix LabManager

Job scheduling in VMLogix LabManager

Reservations and The Trend Towards Adoption of the Cloud: Cloud computing is the emerging trend of the future. The premise of public cloud computing is to provide users with dynamic, scalable, elastic and graded access to IT resources (compute, storage and networking). The concept of reservations are fundamentally negated in this cloud scenario — e.g., it is not hard to imagine a customer tapping the cloud for overflow/burst capacity. If one doesn’t believe this reservation feature to be constraining now (as VMware and VMLogix do), it’s hard to argue that it won’t be obsolete as the Public Clouds get adopted for overflow demand in the future.

Bookmark and Share

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: