Just add this custom property: Extensibility.Lifecycle.Error.Event.VMPSMasterWorkflow32.Requested with value: Destroy
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
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
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-extensibility.pdf
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.