Support new disk creation during RHEV-M VM provision


As part of infrastructure provision there are times when adding or configuring disks for the template being used is required. There is support for adding new disks to VMware, but this same feature is not supported for RHEV-M VM provision requests.

Two possible ways to support this feature with the exist provisioning state-machines in automate are:

  1. Follow the same pattern used for VMware provisioning as defined in “Defining new disks during provisioning” from the CFME Integration Services Guide.
  2. Allow an exit point after the VM has been provisioned but before any additional changes to the VM have been performed. This could be achieve a two ways:
  • Always call the automate provisioning profile with a specific message, like what is done for VM naming.
  • Honor a new provision options key that would accept an automate URI that would be called.

These two options are not mutually exclusive.

The first is focused purely on disks and requires that the model be updated to support collecting and processing the disk options. While much of this can be handled generically there may be some special processing or checks required, but the caller does not have to be concerned with direct interaction with the provider system.

The second option is more open-ended and the caller would be required to interact and perform task through the RHEV-M Restful API.


@gmccullough I do like option 2 because of the flexibility it provides the user since they would not be limited to only adding disks. If some other change is needed in the future they would also be able to leverage this callback. I think it would be great if this could be implemented in a generic enough way to allow the user a callback before any state in the internal state machine. I know other people have had to implement some tricks to get the desired outcome, so this would be a great addition.

To also support option 1, I feel that if we offer this feature for VMware, we should support it on other providers as well. We already have a similar feature for adding NICs to the VM at this stage and we already have the disk creation methods in our RHEVM API library. Currently we have some logic to add new disks to a VM (in our RHEVM API library) during the VM creation. I believe this should be moved into the state machine where it is needed (RHEVM PXE & ISO provisioning) then we can consume input similar to what is available for VMware to add extra disks during the provision.

@gmccullough What do you think of those ideas?


@bdunne I think these are really great ideas.

For option 1 I agree that we should get to parity with our VMware support for this feature. However, moving the disk logic out of our library and into the state machine would make it harder for other callers to consume this API as they would likely expect the disks would be created as part of the call. Also, native cloning would require knowledge of the disk change information which I do not think it goes through the same path to create the disk as PXE/ISO. We should investigate the options here further.

For exit points it should be relatively easy to implement a naming convention so exit points can be dynamically added to the provision task options and run at the beginning of each state. I would think the obvious implementation would be to use the name of the state as part of the options key.

It may also be useful to support pre/post exit points. The difference being that at the being of signaling a new state we check the current state value for the record and if it is different we run the post state. For example when transitioning from customize_destination to boot_from_cdrom you could run the post_customize_destination and then the pre_boot_from_cdrom. The use case being that on a re-entrant state you would not run the “post” exit point the second time, but you would run the “pre” state.

I would suggest using a prefix like “ae_pre_” and “ae_post_” for the options values.
Example: Options key “ae_pre_customize_destination” could contain an automate entry point run before the start of the customize_destination state.


  1. My main concern here is that any change to the state names would inadvertently break this functionality.
  2. Understanding the states available will require a knowledge of the internal state-machine structure which is currently spread across several files and logic can be overridden by sub-classes.


@gmccullough & @bdunne -
option 1: I concur that we should have parity here.

option 2: I was thinking of a prov option like (:userctrl => true). So that when the task is executed we could insert a method in front of the check_provisioned method that would allow us to power the VM when we are done with our customizations. Basically letting the state machine power on the VM instead of the task.