How to Automate VM Provisioning for SCVMM and VMware vCenter in 20 Minutes using Service Manager and Opalis
Jim and Travis put together a great ‘how-to’ video on getting a good workflow going with Service Manager and SCVMM using Opalis. They show you step-by-step how to configure each object and how to configure Service Manager – including creating the management pack using the Service Manager Authoring Tool (you can download this HERE).
I was able to get this up and running in my lab – works great and is an effective demo on how to integrate SCSM, Opalis and SCVMM.
I wanted to take it a step further though. How would you do this if you had a VMware vSphere environment?
Well, the good news is - it's not that hard. :) Here’s a link to a video I recorded that shows the entire process of provisioning using VMware.
1) Go back and watch the video on the Service Manager Blog. In my case, instead of using "VM" in the templates, forms, lists, etc..., I used "VMware". You'll essentially re-create that entire CR process - but you'll do it for VMware.
2) Copy and paste your Opalis workflow (just use the mouse and select all the objects) to a new policy. In a little bit, you'll see which SCVMM objects you'll need to replace with those from the VMware vSphere Integration Pack.
3) You’ll need to make sure that you have the VMware vSphere Integration Pack installed on your Opalis Action Server and you’ll see it in the Opalis Client:
4) You'll also want to go ahead and create the VM's (using Jim and Travis' example - SMCLONE-SMALL, SMCLONE-MEDIUM and SMCLONE-LARGE) on your ESX hosts. For time sakes, I created a blank VMDK so that the cloning process takes a matter of seconds instead of minutes (or more) for fully installed VM's.
For reference – here’s the differences between the two workflow’s. The first is the one that Jim and Travis show you in the video. The second shows the objects you can use to do the exact same thing in your VMware environment.
In my case, I have a 4.0 cluster using vCenter.
Now with VMware:
As you can see, you’ll need to replace the three VM related objects with the appropriate ones from the VMware IP.
Here’s what my settings look like for those 3 objects:
The “GET VM LIST” is pulling published data from the bus – same as the GET VM in the SCVMM workflow:
The “CLONE WINDOWS VM” is a little different from the CREATE VM FROM VM – it’s pretty straightforward, but a few more things to consider. Yours won’t look like mine – it will be unique to your environment – but a couple things you need to consider:
1) In the “Source VM/Template Path” you’ll need to use published data from “MAP PUBLISHED DATA” to grab the VM Image Name. This ensures that you are in the path for the appropriate template.
2) In the “New Virtual Machine Name” field – you’ll want to use a prefix and (in my case) use an underscore and then pull a unique field from somewhere in the bus to uniquely identify the VM you are creating. In my case, I’m pulling the VM ID from the MONITOR OBJECT.
Finally, for the “ADD VM DISK” object, you’ll want to pull “New Virtual Machine Name” from the bus from the “CLONE WINDOWS VM” object.
The DiskSize comes from the original MONITOR OBJECT and is the value that was defined originally in the Service Manager change request form.
The last step, if you did a copy/paste from your SCVMM workflow and just replaced these 3 objects to work with VMware is to go back through the final 3 objects to make sure that any data that was pulled from the bus is accurate. If you have data being pulled from any of the objects that were deleted or changed names – your workflow isn’t going to work.
Final Result. I stuck with the same naming convention that Jim and Travis used in their demo, so each new VM that’s created starts with DEMOVM_ and then is appended with the CR# in Service Manager. I like using that, as it makes it easy to correlate the change request with the VM. Of course, another option here is to modify the orignial CR form in Service Manager to include the VM Name (as well as any other paramters that Opalis can modify on a VM, incuding things like RAM and Network Adapters, etc...). In this case, the only other form option was the size of the VM Disk we were going to add. That could certainly be optional and you could branch the workflow if the requestor didn't want/need an additional VM Disk attached.
The “ADD VM DISK” worked flawlessly as well.
This is a great example of the power of System Center - regardless of which hypervisor you choose!
Finally, Don't forget to check out the Opalis Survival Guide - everything you need to know to get up and running with Opalis!
Good luck and enjoy!