Short answer: Zabbix monitors vSphere agentlessly through the vCenter (or ESXi) SDK. First enable VMware collectors on the Zabbix server with StartVMwareCollectors and restart it. Then create one host linked to the VMware or VMware FQDN template and set {$VMWARE.URL} to https://<vcenter>/sdk, plus the username and password macros. Low-level discovery then creates hosts for hypervisors and VMs automatically.
How Zabbix VMware monitoring works
Zabbix needs no agent on ESXi hosts. Dedicated vmware collector processes in the Zabbix server (or proxy) log in to the vSphere Web Services API, cache configuration and performance counters in shared memory, and serve that cache to vmware.* items. According to the Zabbix VMware monitoring manual, the server must be built with --with-libcurl --with-libxml2. Official Zabbix packages already include both.
Step 1: enable VMware collectors on the Zabbix server
By default no collectors run. Edit /etc/zabbix/zabbix_server.conf (or the proxy config if a proxy monitors vCenter):
StartVMwareCollectors=2
# optional tuning, see the zabbix_server.conf reference
# VMwareCacheSize=
# VMwareFrequency=
# VMwarePerfFrequency=
# VMwareTimeout=systemctl restart zabbix-serverZabbix recommends running more collectors than monitored VMware services, and no more than twice as many. With too few, slow configuration retrieval on large vCenters delays performance data. VMwareCacheSize holds the shared memory for VMware data, so size it to the number of hosts and VMs you monitor. Use Zabbix internal monitoring to see how full the cache is and how busy the collectors are.
| Parameter | Meaning |
|---|---|
| StartVMwareCollectors | Number of pre-forked VMware collector processes |
| VMwareCacheSize | Shared memory for VMware data |
| VMwareFrequency | Seconds between configuration data gathering from one VMware service |
| VMwarePerfFrequency | Seconds between performance counter retrievals |
| VMwareTimeout | Maximum wait for a response from the VMware service |
Step 2: prepare a vCenter service account
The Zabbix guide uses administrator@vsphere.local as an example. In production, use a dedicated SSO user with the Read-only role, propagated from the vCenter root object. Monitoring only reads inventory, events and counters. Zabbix does not document a minimum privilege set, so if some items stay unsupported, check permissions before anything else.
For datastore capacity metrics, the Zabbix docs require the vCenter advanced setting vpxd.stats.maxQueryMetrics to be at least 64.
Step 3: create the vCenter host and macros in Zabbix
- Data collection > Hosts > Create host, for example VMware environment, host group VMware. No interface is needed.
- Link the template VMware FQDN or VMware (see below).
- On the Macros tab set the three macros, using a secret text type for the password.
{$VMWARE.URL} = https://vcenter.example.local/sdk
{$VMWARE.USERNAME} = svc-zabbix@vsphere.local
{$VMWARE.PASSWORD} = ********Discovery rules such as vmware.hv.discovery[{$VMWARE.URL}] then create hypervisor hosts (template VMware Hypervisor) and VM hosts (template VMware Guest) from host prototypes. Check the results in Monitoring > Hosts > Latest data.
VMware vs VMware FQDN template
The template documentation explains that the difference is naming. VMware names discovered VM hosts from vCenter data (UUID-based macros, VM names as shown in vCenter). VMware FQDN uses the guest FQDN. That requires VMware Tools and a unique, FQDN-compliant OS name in each VM. It also avoids duplicate hosts when the same VMs also run a Zabbix agent that auto-registers under its hostname. Do not link VMware Guest manually: it is meant only for discovery.
Template macros worth changing
Beyond the three connection macros, the VMware template (Zabbix 7.0 and 7.4) has macros that decide how noisy and how large the setup gets. Set them on the vCenter host:
| Macro | Default | Why change it |
|---|---|---|
{$VMWARE.VM.POWERSTATE} | poweredOn|poweredOff|suspended | Set to poweredOn to stop discovering templates and powered-off VMs. That cuts host count and VMware cache use on large vCenters. |
{$VMWARE.DATASTORE.SPACE.WARN} / .CRIT | 20 / 10 (% free) | Match your storage team’s thresholds, so Zabbix and vCenter alarms agree. |
{$VMWARE.HV.SENSOR.DISCOVERY} | false | Set to true to get hardware sensors (fans, PSUs, temperatures) of each ESX host. Narrow it with {$VMWARE.HV.SENSOR.DISCOVERY.NAME.MATCHES} / .NOT_MATCHES. |
{$VMWARE.PROXY} | empty | HTTP proxy for the template’s script items, if the Zabbix server reaches vCenter only through a proxy. |
The template also discovers vCenter alarms (vmware.alarms.get and the “VMware alarm discovery” rule). Each triggered vCenter alarm becomes a Zabbix problem, so certificate, HA or vSAN health alarms show up next to your other monitoring. Expect some noise at first, and tune the alarms in vCenter rather than suppressing them in Zabbix.
ESX and vCenter 9: the template README for Zabbix 7.0 and 7.4 lists VMware 6.0, 6.7, 7.0 and 8.0 as tested versions. 9.x is not listed yet. The vSphere API that Zabbix uses is the same, but validate discovery and the performance counters in a test before you rely on it for VCF 9 production.
Troubleshooting Zabbix vCenter monitoring
- “No vmware collector processes started”:
StartVMwareCollectorsis 0 on the server or proxy that actually polls the host. - Items “Not supported” on datastores: the performance counter is not enabled or collected in vCenter, or
maxQueryMetricsis too low. - Login errors after certificate or password changes: check the URL ends in
/sdkand the service account has not expired. See vCenter password expiration fix. - Deep debugging: raise the log level for vmware collectors only (debug level 5), as described in the Zabbix manual.
Further reading
- Original post: Monitoring VMware vSphere with Zabbix (vMattroman)
- Zabbix manual: Monitor VMware with Zabbix
- Zabbix manual: VMware monitoring
- Zabbix manual: zabbix_server.conf parameters
- Zabbix VMware template README (7.0): full macro, item and trigger list
