Is it possible to deploy from a Pool of VMs

[marlounb]

Hey guys,

We are on VRA/VRO 7.3.

I'm wondering if anyone has ever tried deploying from a pool of VMs already created, for new requests.

Today (in a nutshell), it basically takes about 40 minutes or so to clone a VM because of the workflows it runs through in VRO. This is exacerbated by the software components it runs after this. We have an idea to basically pull a pre-made VM, and just run whatever software component on top of it. This way, we basically bypass the ~40 minutes it takes to clone, and run the workflows. If there are no workflows, then the idea is then the app owners then have their machines in a couple mins, at the quickest, and really the contention of time, is based on the software component they run. This also ensures us the VM is already set up and ready to go, as opposed to it failing somewhere in the workflow pipeline, and ultimately failing the build in it's entirety.

Basically, our customers (like I'm sure, many of yours), want their VMs... NOW!! Even if we didn't have a set of workflows to run, the clone process in itself, takes us about 15 mins. Also, because of the abundance of complex workflows we run, we also increase the risk, of workflow failures. By having the pool we provision from, would bypass any failures that the customer would experience themselves.

Does what I say make sense?

I'd also be interested to hear what other have done to expedite the processes to providing VMs in VRA.

[daphnissov]

Yes, this makes sense, but what you have in mind won't work. It's just not something vRA was designed to do and you have numerous problems with trying to accomplish it. So instead of trying to figure out a way to hack this into submission, I'll give you some tips that may help speed things up.

• If your clones are taking upwards of 15 minutes, you need to check a few things
  • Is VAAI in use on your array? It should be if it's block. If not, (like if it's NFS), then you may want to address this at the storage level.
  • Are you cloning a template across clusters? If so, you need to ensure that storage is presented to all hosts, because otherwise a template in one cluster will traverse the management vmkernel ports to land on the other cluster. This dramatically increases cloning times.
  • Are linked clones an option for some of your blueprints? For development deployments especially, linked clones may be fine. The clone time is basically instantaneous. This may not be the best idea for workloads which are production and must stick around for long periods of time. Lots of caveats here.
• A point on the time it takes to address complaints from users.
  • I've heard this complaint before, but one thing they need to be reminded of is that 40 minutes spent in automated phases is not 40 minutes of their time. It's 40 minutes they can spend doing other valuable tasks. So, yes, it takes them a while to receive their machine, but if they're sitting at their desks twiddling their thumbs while waiting for their resources to be delivered, they're not doing their jobs, and that's the whole reason for using a CMP in the first place–so they don't have to do this stuff manually any longer.
• Software components may be optimized
  • Often times, you can dramatically speed provisioning when using software components by writing them in a more resilient way and ensuring that any ordering you're doing is absolutely required.
  • Can't really say more unless I see what you're invoking.

These are some tips that I've used with multiple customers in the past and regardless if they're helpful, they're good things to keep in mind.