Before developing a service catalog item to provision a virtual machine, test that an interactive provision (Infrastructure → Virtual Machines → Lifecycle → Provision VMs) from the same virtual machine template, using the same virtual machine settings, works successfully.

This should include the same placement type (auto or manually selected), and the same CPU count and memory size ranges that will be offered from the service dialog.

Troubleshooting a failing interactive VM provision is simpler than troubleshooting a failing service order.

If any changes are made to the template that would result in a new internal template ID, then the service catalog item must be re-created (even if the new template has the same name as the old). The new template will be represented by a new object in the VMDB, so the service provision request template will need to be re-created with the new template ID.

There are times when an out-of-the-box service provision state machine does not provide the flexibility that we need to create the service that we require. An example of this would be wishing to present a service dialog offering a selection of VM templates to provision the new VM from (by default this is selected and fixed when the catalog item is created). Fortunately we are not constrained to use the as-supplied state machines.

When we create a new service catalog item, we are presented with a drop-down list of catalog item types to choose from (see Selection of Catalog Item Type).

​

As Selection of Catalog Item Type shows there’s a Generic selection that we can use. If we select this catalog item type, we can create our own custom instance of the ServiceProvision_Template state machine class. This can handle the parsing of any service catalog elements, and assemble arguments for a call to $evm.execute('create_provision_request') to complete the VM provision. (see Creating Programming Requests Programmatically).

By hand-rolling the arguments to create_provision_request in this way, we have complete control over the VM provision request. We could easily prompt the user for the template name to provision from, or the number of VMs to provision with the request for example.^[1]

This chapter has shown us three simple tips to consider when working with services. Generic services, in particular, are useful if we wish to create a single service catalog item to provision a new virtual machine into a choice of providers (such as VMware or OpenStack). With a traditional service catalog item, we must select a template first, and this decides the destination provider. With a Generic service type, we can present our users with a list of VMware templates or OpenStack Glance images to choose from at runtime. Depending on the template or image selected, we can then supply the appropriate provider-specific arguments to $evm.execute('create_provision_request') in order to complete the request.