We are using XaaS to request a VM blueprint to be built, with all our parameters and VM specs etc. So far we've worked mostly in vRA/vRO to build the surrounding mechanism, configuration elements, vRA Catalog Items etc, but not really sent the request to build machine. We are now starting to do so to start coding the IPAM/DNS/AD/CMDB/++ integrations and see what happens etc when a VM gets provisioned. For this we want to use the Event Subscriptions. So far so good..
Problem is we want to block/stop/fail the VM provisioning before it hits the VMPSMasterWorkflow32.BuildingMachine event so it won't actually start to clone our template. This takes some time, and with lots of code testing and request firing off it would be bad to just let the machine get built when there are no IP addresses etc to give to the VM.
So does anyone know how to stop/kill/dispose/fail the provisioning process right before BuildingMachine?
We intend to do most of the 3rd party integration in VMPSMasterWorkflow32.Requested and .VMPSMasterWorkflow32.WaitingToBuild states, which is the states before .MPSMasterWorkflow32.BuildingMachine.
Idea from SaschaMilic is quite cool.
however you might need to have a VM for later testing.
why not create a empty dummy template VM? in vcenter create new machine, assign some guest OS (dont run or install anything). attach a 10MB disk and a nic.
First of all, I've found a much simpler way 🙂
1) Create the event subscription on
VMPSMasterWorkflow32.Requested with state
Pre as blocking.
2) In your workflow, declare
var virtualMachineEvent = "BuildFailure" as an output parameter.
Bingo. After the event triggers my workflow when entering VMPSMasterWorkflow32.Requested.Pre the next step skips VMPSMasterWorkflow32.Requested.Event right to VMPSMasterWorkflow32.Requested.Post and then to
disposing. No clone or any other building methods triggered. Just as I want it while I test out code.
I never got 'Extensibility.Lifecycle.Error.Event.VMPSMasterWorkflow32.Requested with value: Destroy' to work.
Do you set it in the VM properties, or is it fine to set it on the VM with a workflow after the request?
Extensibility.Lifecycle.Error.Event.VMPSMasterWorkflow32.Requested = Destroy
Extensibility.Lifecycle.Error.Event.VMPSMasterWorkflow32.Requested = Disposing
Extensibility.Lifecycle.Error.Event.VMPSMasterWorkflow32.Requested = Finalized
Extensibility.Lifecycle.Error.State.VMPSMasterWorkflow32.Requested.PRE = Disposing (and Destroy)
in both blueprint properties and put on VM on .Request.PRE. None of them stopped the VM from starting to clone.
Third: I could of course create a small dummy template, but that is a workaround I hoped I could skip. And as you can see in my post above, I managed to make it happen.
But I would still like to understand if/how the other
Error.Event way works...?
first of all: my idea with the event custom property for the REQUEST state shouldn't be used that way, because of:
"In the requested state there is an event (OnProvisionMachine) which is triggered by vRA(each 10 seconds) and may interfere with any event you fire for failure in that state, the same goes if you want to directly change the state – so I don’t recommend doing any customizations that require error handling in that state."
So that seems the reason why it sometimes works and sometimes not...and repeating my tests it produces wired things like moving to disposing but then still starting cloning...repeating many times UnprovisionMachine and Disposing until finally the VM got destroyed again (after cloning). So Yes, the custom property way to trigger an event when vRO fails is working, but I'm stepping back from that idea using that way in the request state!
With virtualMachineEvent = "BuildFailure" there a few things to mention:
"BuildFailure is used internally by vRA, like BuildSuccess. Destroy is a better choice as it corresponds to the Day 2 operation."
"Another specific thing with the events is that if they are fired while the workflow is going through the predefined path they may get lost and not work"
"If you need to use output parameter for error behavior you have to ‘wrap’ all the WFs functionality in a try/catch block and set the error state/event in the catch (in case of error)."
Finally, getting now what you really want, the simplest way to achieve that is just using the OOTB functionality (which is anyway the best recommendation):
- Subscribe to Building.PRE (that's before the platform specific stuff like cloning, etc. is happening)
- Let your vRO workflow simply fail
So no need to set custom properties or output parameters in following states BuildingMachine.PRE, MachineProvisioned.PRE and RegisterMachine.PRE
I'm using a User Interaction in my workflow with a "fail yes/no" question to have the choice to examine some values and going on or just let it fail.
Just forgot to add following: http://pubs.vmware.com/vrealize-automation-71/topic/com.vmware.ICbase/PDF/vrealize-automation-71-ext...
Pages 40/41 are explaining the OOTB states and the way how to control additional states with custom properties.
Following another great quote from my gathering while communicating with VMware "internal" sources:
"Hard changing the state of the master workflow (by using workflowNextState or the corresponding property) is not recommended because the state transitions are ‘encoded’ in the workflow itself – it goes through pre-defined paths during the provisioning. Those paths have been tested and verified to be working. Changing the state directly may force the workflow into unpredictable paths which may not work or cause unpredictable behavior.
That’s why it is better to use events – most of them are like triggering D2O from the UI. There are some exceptions – events that are used internally by vRA, like BuildSuccess."
Thanks sascha for good information. I got it working with a blocking subscription to BuildingMachine.PRE state.
Somehow I read Requested.PRE instead of RegisterMachine.PRE and thought it was a typo.. well.. got it to stop cloning my template with my throw/fail.
Glad I found this thread here... am I the only one that thinks there are some bugs here? It seems like from the documentation we should be able to modify the behavior of the workflow error states. This will also work for me (forcing the error at the BuildingMachine.PRE state) but I don't like the fact that I have to go so far down the line.