Need to extract vm href on deletion of a VM

[UofS]

I see that someone else has a similar problem but am not sure if it was solved at some point.

I have to perform cleanup tasks on DNS information when a VM is deleted.

I currently can create DNS entries and handle modifications, but am looking at the delete and realizing that the "Add move delete Vm from vApp" blocking task isnt really a "delete_request" event I was looking for, rather a recompose Vapp.  Not returning any VM data such as the href or UUID.

When I use the delete event, its already gone and I cant get the MAC IP info I need.

Any idea how I can snag this info without maintaining another separate DB of the events in order to correlate the data after the fact?  Or this a todo item I should expect in an upcoming version?

dion

[UofS]

Do I have come to the conclusion that the awsome package found here:

http://communities.vmware.com/docs/DOC-18002

Cannot be used to monitor a vm delete event as it will fail as it seems to try to get the vCloud:VM object that is being deleted instead of just returning a limited object with the name and href (data that is clearly available in the AMQP message and it doesnt have to load from the vcd server).

I was not using it with a blocking event, but I dont see why it shouldnt be able to work withnon blocking events as well...

So it appears I will have to use the notifications package for 2/3 events I watch (create and modify) and write a separate listener to handle this delete event... Unless cdecanini_ has an idea how I can handle this delete event using his package?

Dion

[cdecanini_]

The issue of the blocking task preventing to access to the object being accessed by the blocked task is something that we reported internaly months ago. Now since you are a customer and since customer requests get a particular attention and tracking I would suggest opening a SR.

The package was written in a generic way assuming this particular behavior was more of a bug than a feature and that the package serves as a base that can be modified to address requirements it does not fullfill.

For example you can create a policy for VM deletion that would run a specific workflow instead of the "workflow runner" workflow. From there you can get the VM reference name, type. Unfortunatley you cannot access to the computer name that may be of interest for what you want to do. This can be worked around by recording the VM url and VM computer name in a record you maintain when the object is not blocked (either DB or XML file in a resource element).

Christophe.

[cdecanini_]

Another way to work around this is to abort the VM deletion, get all VM info and start the delete VM workflow if the taskOwner is not the user in use by vCO (to avoid an infinitel loop), otherwise resume it.

Christophe.

[UofS]

Just to confirm with you, there is no such thing as a blocking task for VMs is there?  I have not seen this unless there is a patch or upgrade that provides this.  The only way to abort a VM deletion would be to assume that there is a blocking task available for that to abort.  Or am I out to lunch?

If this is the case, should the SR request be to add functionality for blocking tasks on Delete of VMs?

dion

[cdecanini_]

There is a "Add, Move or Delete Virtual Machines from vApp" blocking task and a "Delete vApp" blocking task.

Christophe.

[UofS]

When I tried to use the "Add, Move, Delete VM from vApp" I couldnt figure out how to tell what the use had requested as it simply caused a recompose event passing me the vApp object.

I had thought the only way to use the "Add, Move, Delete VM from vApp" was to block and store the current layout, the resume and compare.  Is there a more simple way to achieve this?  Or a way to tell which action caused the event to fire rather than the generic recompose?

Dion

[UofS]

And what exactly defines a "move" of a vm from a vApp?

Would this trigger another blocking event in another vApp where its "moving in"?

[UofS]

I decided to do as you suggested.  The create and modify VMs work well, so its just the delete that is different.

> For example you can create a policy for VM deletion that would run a  specific workflow instead of the "workflow runner" workflow.