Generating unique VM names during provisioning

In our environment, we don’t want end users to be able to provide their own names for VMs provisioned as part of service catalog items.

I’ve modified the vm_name method to handle this case, where it generates a number to be in each name based on the number of vms and/or highest vm number currently in use. BUT, there is an issue if the user requests provisioning of multiple services simultaneously, both service provision requests generate an identical VM name in multiple services.

Is there a way to determine how many in progress provisioning requests for the user there are, and do something like a active_requests.find_index(current_prov_id), to try to get unique modifier for the number?

I’ve thought about trying to store the highest VM number on the user, but I don’t see how to do that, and I don’t think it would solve the problem, since both naming calls could be reading the variable simultaneously.

I’ve seen the $n rails value referenced in the original naming, but that seems focused on the case of someone creating a single service with multiple VMs to create an index, whereas my case is multiple services with single VMs.

The challenge for automated VM naming from a service catalog provision is that the normal naming methods have already run by the time your service provision state machine runs. The easiest way to get around this is to hand-roll a VM naming check, and use the new update_vm_name method during the VM provision state machine to set the derived name.

You could use something like this to find a name based on vm_prefix, function and suffix variable parts:

for i in (1..999)
  new_vm_name = "#{vm_prefix}#{function}#{i.to_s.rjust(2, "0")}#{suffix}"
  break if $evm.vmdb('vm_or_template').find_by_name(new_vm_name).blank?

and then something like this to set the name:

prov = $evm.root['miq_provision']
prov.update_vm_name("#{new_vm_name}", :update_request => false)

Unfortunately the little discovery loop isn’t immune to race conditions from multiple simultaneous users, or even external users requesting the same VM name from the vCenter.

Checking in-flight provisioning requests is possible, I think the quota methods do this.

Hope this helps

For utter simplicity, for now I’m going to use the as the unique number for every VM. Not quite as convenient as an independent sequence for each user, but given my track record so far with breaking things, I’m not comfortable trying to add a rename step into the VM State Machine just now.

I did find a prior thread where a similar solution was proposed, including a link to some useful looking methods in this github project.

Thanks for your help, once again, pemcg

Good idea, but you might want to consider using the task ID rather than request ID, as one request might be for several VMs, each of which would have their own provisioning task.