New Orchestrator user - how to accurately destroy THEN rebuild VM with same name?

[rharland2013]

Hello!

I'll preface this question with an admission of how basic it is - take it a little easy if you can (I'm just getting started).

My desired scenario is to build a workflow or series of workflows that will periodically refresh a small group of clones to match a certain master.

Chronologically, here's what happens:

1. Master VM is in desired state.

2. Clones 1-3 are created to match this master.

3. Done!

Here's the part that's getting bumpy for me - the second refresh.

Our desired behavior is this:

1. Old machines are destroyed and removed from disk.

2. New clones 1-3 created from updated master.

3. Done!

I want this to be automated as possible - that is, no other touching than kicking off a workflow.

The sticky part is when the first destruction is done. As a by-product of the outcome of that destruction workflow, the defined attribute (the box I want to destroy prior to rebuild) gets taken out of the workflow, so the next time I want to run it, shows 'not found' in the attribute.

Is there any way around this one?

Thanks for any info!

[carl1]

I am not sure if this will be possible.  The issue (as far as I understand it) is that the VM is not tracked by it's name but by it's uuid (you can have several VMs with the same name in different folders).  When you delete and re-create the VM, the new one will have a different uuid and thus vCAC will correctly see it as a completely different VM.  The part I am not sure about (but I doubt that you can) is:  can you update the vCAC uuid to point to the new VM -or- can you set the uuid of the new VM in vCenter to match the old VM.

Better minds than I may have a solution though.

Carl L.

[ivand]

You can design scheduled workflow with vm name instead of the vm object. This way you will have consistency. Every time you create new clone just set same name.

[rharland2013]

The creation part's working fine, and I'm doing precisely that. The problem I'm encountering is that when the destruction workflow processes and completes, the vm gets stripped out of the customized destruction workflow - because it's been deleted from disk and inventory and cannot be found.

[qc4vmware]

Can you post your workflow here?  I am having a hard time following just exactly what is failing.  What information is it you need from the original clone if, as you say, you are going to be creating new vm's from a new master?  It seems like all you should need is a name.  If there is other configuration information you need from the pre-existing clones you'll either need to capture it before destroying or have a definition sitting somewhere like a configuration element or defined in your workflow like you do vm name.

[rharland2013]

Sure - attached please find the problematic piece.

I'm beginning to see where I'm getting it wrong here, since that 'vm' attribute seems to be the sticker - it can't find it because each iteration of the workflow destroys it.

What I need to do is just tell the workflow how to find a vm with the name that I want.

Like I said - total newb.

Thanks.

[Chris_VirtualFa]

Did anyone ever find a solution to this? I'm having exactly the same problem - once the VM has been deleted, the value gets stripped out of the attribute.