Would it be possible to provide larger screenshots from VMware client showing the correct status? We are talking with WMware support regarding the right place to query for hypervisor status and they are asking us for screenshots showing the host status in their client.

Larger screenshots from VMware client showing the correct status.

Larger screenshots from zabbix showing the wrong status.

Thanks, we will forward this screenshot to VMware support. I hope you won't mind if they will be asking for more details.

Thanks so much for attention and agility. I am available for any clarification.

Sorry for the delay, one question:

Do you see the status difference in the VI client only or Web Client as well? Web client uses the same API call internally as the Property Collector. Hence they requested to check the status in Web Client as well.

If this helps, using the Managed Object Browser https://<virtual center server>/mob/?moid=host-XXXX, I find the following information:

vCenter host status is yellow, but in zabbix is green. See new images.

Thanks

Again, I see in Zabbix (3.0.3), the status of a host as "gray" while vCenter and MOB show "red". So, I checked the checks_simple_vmware.c and vmware.h sources to find what is happening.

This monitor is only checking the hardware status and not any of the defined alarms (which includes hardware).
As one of my hosts has a serious issue, the "VMware Rollup Health State" shows as "Unknown" as found here: https://<virtual center server>/mob/?moid=host-XXXX&doPath=runtime%2ehealthSystemRuntime%2esystemHealthInfo%2enumericSensorInfo
or found here: https://<hypervisor>/mob/?moid=ha-host&doPath=runtime%2ehealthSystemRuntime%2esystemHealthInfo%2enumericSensorInfo

Using the Managed Object Browser https://<virtual center server>/mob/?moid=host-XXXX, I find the following information:

However, I know that for customers not using vCenter the overallStatus may not include the alarm values and TriggeredAlarms values are not available while the simple hardware health information may be available.

Perhaps, a vCenter template with a TriggeredAlarms discovery option or a simple item for overallStatus could be made available?

Thanks!

Yes, we did initially monitory HostSystem.overallStatus. However we had reports that it does not represent the real status of hypervisor. Based on provided data we switched it to Rollup Health State, as it was the only place showing the correct status (green/unknown/red/yellow). But based on reports and initial talks with VMware support it was wrong choice.

Now I'm thinking the best idea would be to revert back to HostSystem.overallStatus monitoring and add a new 'VMware Rollup Health State' item. Thanks for the idea!

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-11093

wiper Wrong branch, fix moved to the correct brach svn://svn.zabbix.com/branches/dev/ZBX-10694

Thanks!

(1) [S] Minor thing but seems like there are lots of unneeded result checks like NULL != GET_STR_RESULT(result). In the following example if get_vcenter_stat() returns SYSINFO_RET_OK the result will unconditionally contain string:

        ret = get_vcenter_stat(request, username, password, ZBX_OPT_XPATH,
                        ZBX_XPATH_HV_SENSOR_STATUS("VMware Rollup Health State"), result);

        if (SYSINFO_RET_OK == ret && NULL != GET_STR_RESULT(result))

wiper After fixing ZBXNEXT-3106 (3.0+) similar redundant check is used only in one place:

int	check_vcenter_hv_status(AGENT_REQUEST *request, const char *username, const char *password,
		AGENT_RESULT *result)
{
	const char	*__function_name = "check_vcenter_hv_status";

	int		ret;

	zabbix_log(LOG_LEVEL_DEBUG, "In %s()", __function_name);

	ret = get_vcenter_hvprop(request, username, password, ZBX_VMWARE_HVPROP_STATUS, result);

	if (SYSINFO_RET_OK == ret && NULL != GET_STR_RESULT(result))
	{
		if (0 == strcmp(result->str, "gray") || 0 == strcmp(result->str, "unknown"))
			SET_UI64_RESULT(result, 0);
		else if (0 == strcmp(result->str, "green"))
			SET_UI64_RESULT(result, 1);
		else if (0 == strcmp(result->str, "yellow"))
			SET_UI64_RESULT(result, 2);
		else if (0 == strcmp(result->str, "red"))
			SET_UI64_RESULT(result, 3);
		else
			ret = SYSINFO_RET_FAIL;

		UNSET_STR_RESULT(result);
	}

	zabbix_log(LOG_LEVEL_DEBUG, "End of %s():%s", __function_name, sysinfo_ret_string(ret));

	return ret;
}

I don't think it's worth fixing in 2.2. We might open a new ZBX or simply add it to another vmware related issues.

<dimir> I agree. CLOSED

(2) [D] Just to not forget, new key hypervisor state rollup should be added to

• vmware keys section (2.2, 3.0, 3.2, 3.4, with note about version it appeared in)
• what's new (2.2.16, 3.0.6, 3.2.2)

Probably worth also documenting different behavior of vmware.hv.status in different versions.

wiper Documantation updated:

• VMware key description:
  • https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/simple_checks/vmware_keys
  • https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/simple_checks/vmware_keys
  • https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/simple_checks/vmware_keys
  • https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/simple_checks/vmware_keys
• What's new:
  • https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew2216
  • https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew306
  • https://www.zabbix.com/documentation/3.2/manual/introduction/whatsnew322
• Zabbix templates:
  • https://www.zabbix.org/wiki/Zabbix_Templates/Official_Templates

RESOLVED

<dimir> Do we really need comments for key description in 3.4l?

wiper I believe yes. Even more - it might be better to mention older revisions too, as it's done for few other keys.

<dimir> CLOSED

Released in:

• pre-2.2.16rc1 r62971
• pre-3.0.6rc1 r62976
• pre-3.2.2rc1 r62978
• pre-3.3.0 r62980