Question: How often is the VirtualMachineRuntimeInfo.ConsolidationNeeded value updated?

[atc0005]

I created a Nagios plugin to monitor the state of the consolidationNeeded property for VirtualMachine objects. I don't have any VMs within our environment that have this value set, but I've received a bug report from a user that indicates that even after they've consolidated disks for affected VMs the plugin is still reporting that the VMs require disk consolidation. This is even after affected VMs have been power cycled.

The Triggered Alarm in their environment has cleared to indicate that the issue is no more, but the plugin still "sees" the consolidationNeeded property as set. The plugin operates as a "one shot" app, starting up, retrieving properties and then giving a report (pass/fail) before exiting. No state is retained directly by the plugin between executions. I'm using a view to retrieve the properties.

I found this in the vSphere Web Services SDK Programming Guide:

Important You can use API methods to operate on managed objects in the vSphere inventory. A method that updates properties in one managed object may also update properties in other managed objects. The Server performs asynchronous updates to the inventory. There is no guarantee that the inventory will be completely updated when the method returns to the caller. Use the PropertyCollector method WaitForUpdatesEx to obtain property changes.

This seems to suggest that data retrieved from a view may not be the most current at the time of retrieval, but that it eventually will be.

Not really knowing the internals all that well, this feels almost like the view data is being cached somewhere. Do I need to somehow force a refresh of the inventory in order to retrieve current property values?

Thanks in advance for any pointers you may have!

[embano1]

I'm not very familiar with that particular property, but I would suggest using the WaitFor routine as indicated by the API to receive such state changes without making timing assumptions and avoiding continuous poll. WDYT?

[atc0005]

@embano1

Thanks for the feedback.

Nagios executes various service checks on a schedule, relaunching plugins (scripts, etc) to confirm the status of a specific service/host. In this case, the plugin reads the value of the property (maintained in the Runtime property (e.g., vm.Runtime.ConsolidationNeeded) and emits a pass/fail result.

The total execution of the plugin is very brief.

Should I use the WaitFor routine before trusting that properties (in general) are recent, even for "one shot" property retrievals, or is that advice mostly for applications which run for an extended period of time (and likely make multiple queries against the property)?

[embano1]

Should I use the WaitFor routine before trusting that properties (in general) are recent, even for "one shot" property retrievals, or is that advice mostly for applications which run for an extended period of time (and likely make multiple queries against the property)?

Yes, I'd use WaitFor methods in the context of long-running processes, i.e. not "one-offs".

[atc0005]

Thanks for confirming. Perhaps my concerns regarding caching of the property remain relevant then.

Are you familiar with how the Runtime property is maintained for VirtualMachine objects? Are there any cases where power cycling the VMs is not sufficient to update the property, but defined Alarms are able to determine that no unconsolidated disks are present (and thus not a problem)?

[embano1]

Sorry, I have no background in that area :/

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

@github-actions /remove-lifecycle stale

[atc0005]

@dougm Do you know whether client code should force a refresh of the Runtime property before considering the value current, or should a power cycle of a VM be sufficient to refresh the status of the property?

refs #2503 (comment), #2503 (comment)

[dougm]

I've not seen the ConsolidationNeeded property before, but took a quick look at the source.. this property is maintained on the ESX side and does not get updated often afiact. I can see it gets updated during some vMotion and FT related methods, when a VM is first added to inventory, when a VM is reloaded.. in which case you can try using govc object.reload to trigger updating it.

[atc0005]

@dougm Thanks for looking into it, I appreciate it! I'll look at govc object.reload as you suggest.

[atc0005]

@dougm

I looked at the code here:

govmomi/govc/object/reload.go

Lines 76 to 85 in d99e995

	for _, obj := range objs {
	req := types.Reload{
	This: obj,
	}
	_, err = methods.Reload(ctx, c, &req)
	if err != nil {
	return err
	}
	}

and used methods.Reload() as indicated. This reloads the virtual machine as intended and is logged as a recent task in the Tasks and Events listing.

How expensive would you say this operation is? Aside from the Recent Tasks chatter, is there a notable impact on a cluster to frequently reload VMs (e.g., every 5-10 minutes)? Is this a fairly common operation from client code, or do you think this is best configured as a routine job on the cluster itself?

Thanks for your help with this.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

[atc0005]

/remove-lifecycle stale