VM Snapshot Inventory Not Updating in a Timely Manner

[stevenbright1]

I'm having an issue where it appears that inventory related information is not updated in a timely fashion. Where I am seeing this issue is when making use of the getAllSnapshotsOfVM action that comes with vCenter Orchestrator. The behavior I'm encountering is that even after I delete all the snapshots for a VM, I can run this action manually and it will return the same array of snapshots for the VM that it returned before I deleted the snapshots.

I have a workflow that executes this action repeatedly every 5 minutes while checking for the count of the snapshots to reach a certain threshold. Each time the action executes, the same result is returned every time (even after all the snapshots have been removed). The only thing that I've found that appears to cause the action to return a new value is if I go to the Inventory view within Orchestrator and I drill down to that VM. Once I do that, it shows that no snapshots exist in the Inventory. I can then go back to the running work flow and magically, the snapshots no longer exist and the workflow executes as expected. Anyone have any ideas?

I'm running the following versions:

vCenter 5.0.0 build 755629

vCenter Orchestrator Appliance version 4.2.1 build 555

vCenter Orchestration vCenter Server Plugin 5.0.1.232

[tschoergez]

Hi!

That indeed is unexpected. Can you post some of your examples so that we can reproduce?

(I had no problems with that Action, but still on vCO 4.1/vCenter 4.1)

You might also open a support ticket with VMware....

Cheers,

Joerg

[admin]

Sounds like the vCO inventory cache is not updating for some reason, I've seen this with vCD but for vCenter it should automatically update if you initiate the action from vCO, try forcing a refresh of the vCO inventory using updateInternalState() method on the changed object or parent object.

[cdecanini_]

The newer versions of the vCenter plug-in rely on the query service to populate / update the inventory whereas the older versions were using the property collector filters. If something is not updating this is likely a bug that need to be reported to GSS so the plug-in can be updated.

Christophe.

[igorstoyanov]

The first thing to be checked in this case if the vCenter Inventory Service is working and configured properly. In the vCO log file, you can check whether there is warning about vCenter Inventory Service not available. Yes, probably opening an Service Request with the workflow and the log file attached should help to identify the issue.

[stevenbright1]

Below is a screenshot of the logic sequence (small portion of the overall workflow) that is failing due to the fact that the getAllSnapshotsOfVM action is repeatedly returning an array with a snapshot listed (even though the snapshot no longer exists). The "Max Snapshots?" decision checks the length of the array and compares it to a predefined numerical value. The "Max Retries" decision checks an counter against a predefined maximum numerical value.

When reviewing the DEBUG logs on the Orchestrator server, it appears that from the Orchestrator server, it really believes the snapshot still exists:

2012-09-11 14:28:10.535-0400 DEBUG [WorkflowTokenStackHelper] --Attribute 'existingSnapshots'='#{#VC:VirtualMachineSnapshot#dunes://service.dunes.ch/CustomSDKObject?id='vcenter_hostname/snapshot-5622'&dunesName='VC:VirtualMachineSnapshot'#}#'

I also have a workflow I'm using for testing that consists only of the getAllSnapshotsOfVM action and returns the array. The first time I run the workflow, the presentation forces me to view the inventory and find the VM, so that appears to force the inventory update. However during subsequent runs, the VM is already defined in the presentation of the workflow, so I do not have to browse the inventory. It is on the subsequent runs that I see the same behavior as I do in my larger workflow.

I have checked the Orchestrator log for error/warning messages regarding the VMware Inventory service and do not see any issues. The vCenter server also reports that the Inventory Service is running as expected.

To mittell: Are you suggesting that I run the updateInternalState() action against the VM object within my workflows as a work around to the issue?

[cdecanini_]

I think Alex M was confused when he replied since updateInternalState method is for flushing a cached object in the vCloud plug-in.

Christophe.

[stevenbright1]

I decided that I would test the same workflow on the Windows based version of Orchestrator. For the test, I used the version of Orchestrator that was installed on the vCenter server that I have been using for the testing. The Orchestrator version number is the same as the Orchestrator appliance. The vCenter plug-in version is also the same as the one in use on the Orchestrator appliance. So the only difference between the two scenarios is Windows-based versus the virtual appliance based Orchestrator.

The result...everything works as expected. The array of existing snapshots is updated correct, and the workflow executes as expected. So it appears that the issue only relates to the virtual appliance based Orchestrator which probably rules out the vCenter plug-in.

[tschoergez]

Now this is indeed a strange thing.

Can you compare the versions of the vCenter plugin used on both installations? (configuration tool / Plugins)

It might also be helpful to check the server.log on the appliance for some errors (maybe the root cause is somtheing completely different, and not getting the current state of inventory objects is just an impact of that)

Cheers,

Joerg

[igorstoyanov]

Based on the description in this thread: http://communities.vmware.com/message/2114644#2114644 the issue might be related to different times on the vCO server machine and the machine where the vCO client is.

[stevenbright1]

Unfortunately, the time is in sync on both systems as they are both using the same NTP source.

I finally gave up on this and have since upgraded the appliance from 4.2.1 to 5.1. The problem appears to no longer exist on the upgraded version.