Self-Service with CloudForms & RHEV pt2

Hi folks, we’re following up our previous post on RHEV and CloudForms configuration with getting some actual work done. Specifically, we’re going to build a catalog item for our self-service catalog. In order to keep the posts and demos short, the examples are fairly basic, but don’t let that fool you. You can do some crazy and complicated automation.

Let’s get busy with our first example: a single VM.

Ok, I admit it, a single VM doesn’t sound very exciting on it’s own. However, we have to start somewhere and it’s a real use case. People ask for a single VM all the time. Besides, how many “single VMs” do you have in your environment right now that need to be cleaned up??? We can take care of that as part of the automation too. (Foreshadowing!)

For the uninitiated, the self-service portal really helps streamline operations. For everyone. End users can simply click a button to request new resources. And those resources can be tied to quotas, compliance policies, security policies, and even time-to-live for the resources. Administrators only have to set things up once for the self-service portal, then periodically update things as opposed to recreate the VMs over and over again. Or respond to tickets. And in the case of CloudForms, CloudForms can respond to the tickets. But that’s a different discussion..

Ok, so what’s in the demo this week? Well, we log in as admin, and go straight to “Compute” -> “Services” -> “Catalogs”. In the existing environment, there are already a ton of catalog items that include single VM items as well as multi item “bundles” (upcoming post!). We’ll click on “Configuration” to add a new item, and select “RHEV” as our “type” (provider). Then things get interesting. Name and description are self-explanatory. Check the box for “display in catalog” so that it shows up in a catalog, then use the drop down menu to select which catalog. Select a dialog box to go with the catalog item; a dialog is one or more data fields (service names, host names, etc) at creation time. Then we get to “state machines”. State machines are chunks of code that do the lifting behind the scenes. In this case, we’re selecting one for initialization and one for retirement.

After that, all of the information that you enter and select is data that you would have selected as if you were creating the VM from scratch. The VM template, VM name, what hypervisor(s) it will run on, data stores, CPU & memory, disk allocation, networks, any customization, and as I suggested above – the ability to specify when the VM is to be retired.

This is actually very important. For non-production VMs, if everyone knows that the VMs will be cleaned up and folded back into the resource pool, then there is no excuse. “Oh, but there might be code on that VM or a script..” Nope, stop that now. Put it “git” or some other central place.

Ok, so once the catalog item is created, we can see it listed with the other items under “Catalog Items” as well as under “Service Catalogs”. Checking that box for “display in catalog” allowed us to see it here in “Service Catalogs” under “RHEV Provisioning”. (If you pay attention in the demo, you can see there is also VMware provisioning and Multi-cloud provisioning as well…) We’ll actually see and use the self-service portal in an upcoming post, after we create the multi-item bundle.

Let’s check out the demo (best viewed in fullscreen):

That’s really it. In the next piece, we’ll check out the multi-item bundle, then tie up the series with the self-service portal. My hope is that you see how straightforward it is to get automation up and running in your own data center.

Hope this helps,

Captain KVM

Agree? Disagree? Something to add to the conversation?