How Zabbix VMware vSphere monitoring works without an agent on every host
Zabbix queries vCenter through its built-in VMware collector, so no agent is needed on each ESXi host. The collector runs as part of the Zabbix server and polls the vCenter API for hosts, datastores, clusters and virtual machines, which leaves the ESXi fleet untouched and lets one monitoring system cover the whole virtual infrastructure. This section explains how that model works and the decisions it creates. The setup covers collector sizing, polling settings, the vCenter and ESXi templates and discovery of new virtual machines as hosts.
The collector is a pool of worker processes on the Zabbix server. Zabbix advises that StartVMwareCollectors should not be below 2 and should not exceed twice the number of monitored VMware services, so the count follows the number of vCenter services you monitor. Four related settings shape the load: VMwareCacheSize, VMwareFrequency, VMwarePerfFrequency and VMwareTimeout. The cache holds collected data between polls, the frequency settings control how often configuration and performance data are requested, and the timeout bounds each call to vCenter. Confirm the current defaults and value ranges for your Zabbix version in the VMware monitoring documentation before you change them.
Templates and discovery define what gets monitored. The vCenter and ESXi templates carry the item and trigger sets for the inventory hierarchy, and discovery rules create hosts for virtual machines as they appear in vCenter. Decide early which clusters, datastores and VM folders are in scope, because discovery will otherwise create hosts that you then have to maintain and alert on. Confirm which template version ships with your Zabbix release and which discovery filters it supports, then test the virtual machine host prototype against a non-production vCenter folder before you enable it broadly.
Network paths and credentials cause most early problems. The collector account needs read access to the inventory and performance data it polls, and the Zabbix server must reach the vCenter API over the network. Ask your vSphere team which role and privileges they will grant, and confirm that your vCenter version is supported by the Zabbix release you plan to run. DeployOpen plans the collector layout, sizes it against your inventory, sets the polling values, builds and tests the templates and discovery with your team, and documents the result in your environment. The work follows a written scope, and the vCenter and ESXi access, sizing inputs and acceptance tests are agreed before the build starts.
What you need in place before connecting vCenter to Zabbix
Five items need to be settled before you add vCenter as a monitored endpoint. Together they decide whether the Zabbix server or proxy can reach the platform, authenticate with least privilege, and record data that lines up with the rest of your estate.
Zabbix server or proxy version and database
Record the Zabbix server or proxy release you run, because VMware monitoring behavior and supported components depend on it. Confirm the supported database for that exact release in the Zabbix requirements documentation before you build. For Zabbix 7.4, the documented options include MySQL or Percona, MariaDB, PostgreSQL with the TimescaleDB extension, and SQLite for proxies only. Check your server and database versions against the list for your release, and do not assume a newer database is covered.
vCenter and ESXi versions in scope
List every vCenter Server and ESXi version in the estate, including clusters that run older builds during a staged upgrade. Zabbix documents which vSphere versions its VMware monitoring supports for each release, so confirm each pairing in the Zabbix VMware monitoring documentation before you add the first endpoint. Mixed versions are common in long-lived estates, and a gap found after go-live usually means rework on templates or item keys. Record build numbers alongside the major versions.
Read-only vCenter account
Create a dedicated vCenter user for Zabbix with read-only privileges on the inventory objects it must poll, and keep it out of administrator groups. Scope the role to the datacenters, clusters and folders that Zabbix should see, so discovery cannot reach beyond them. Store the password in the Zabbix macro or secret store your team already uses, and set a rotation date. Ask your vSphere team to confirm the exact privileges the role needs for your Zabbix release, since requirements change between versions.
Network paths to vCenter and ESXi
Map the connections from the Zabbix server or each proxy to vCenter and to every ESXi host it will poll, including the port and protocol the VMware collectors use over HTTPS. Firewalls between management and monitoring zones are the most common blocker, and placing a proxy in the same segment as vCenter can reduce the number of rules needed. Test name resolution from the Zabbix host using both short and fully qualified names, because certificate validation depends on it. Confirm the path for each site or data center in scope.
Time synchronization across the stack
Synchronize clocks on the Zabbix server, every proxy, vCenter and each ESXi host against the same time source. Clock skew between the monitoring side and the platform makes performance samples and event timestamps hard to line up, and it can distort problem timing in alerts. Check the time source configured on each ESXi host, not only on vCenter, and confirm that the Zabbix server and proxies use a validated NTP or equivalent service. Record the time source in your runbook so on-call engineers and auditors can see it.
How the Zabbix VMware collector polls vCenter and ESXi
The Zabbix VMware collector is a set of processes that runs inside the Zabbix server or, when you monitor through a proxy, inside that proxy. These processes open sessions to the VMware API, send requests, parse the responses and store the results in Zabbix. The number of collector processes is set by StartVMwareCollectors. The Zabbix documentation advises that this value should not be below 2 and should not exceed twice the number of monitored VMware services. Count those services in your design before you size anything, because that count sets the upper bound. Decide early whether collection runs on the server or on a proxy, since that choice determines which host carries the API traffic and how much network latency sits between the collector and the vSphere estate.
The collector treats vCenter as the primary polling target and adds individual ESXi hosts as targets only where you need them. A vCenter service already holds inventory and performance data for its clusters, hosts, datastores and virtual machines, so a single session can cover many objects. Polling every hypervisor directly would multiply sessions against the same estate and repeat requests that vCenter already answers. The trade-off is dependence: if vCenter is unavailable or slow, the data behind it stops, and a standalone ESXi host without vCenter needs its own target. Confirm in the documentation for your version which template items require a direct host connection and which work through vCenter, because the answer changes your target list and your credentials model.
Inventory discovery and performance data follow different paths, and treating them as one stream leads to sizing mistakes. Discovery requests list the objects in the environment, such as clusters, hosts, datastores and virtual machines, and drive the creation of hosts and items through low-level discovery. Property data describes object configuration and state, such as power state or version details, and generally changes less often than counters. Performance data consists of statistics that vSphere records over time, such as CPU, memory, disk and network counters. Zabbix requests property data at the interval set by VMwareFrequency and performance statistics at the interval set by VMwarePerfFrequency. Confirm the exact item keys, refresh behavior and any per-object limits in the documentation for your version before you build templates on them.
Tune the collector settings as one set. VMwareCacheSize sets how much memory the collector uses to hold data it has fetched, so a cache that is too small forces repeated requests and slower updates, while a cache that is too large spends server memory on data that no one reads. VMwareTimeout limits how long a request waits for a response from vCenter or a host, and a value that is too short produces gaps during busy periods. Test the combination in a non-production copy with the real object count, then watch the Zabbix server's own health data and the load that polling places on vCenter. Ask your implementation team to document the chosen values, the service count they assumed and the change process, because each increase in virtual machine count will require these numbers to be revisited.
Configuring the VMware collector and the vCenter host in Zabbix
This sequence turns a running Zabbix server into a working vCenter monitor: the VMware collectors start, one vCenter host polls the API, and discovery creates the ESXi hosts, datastores and virtual machines that the templates then populate with values.
Confirm the server or proxy can reach vCenter
Before touching Zabbix configuration, the Zabbix administrator confirms that the server or the proxy that will poll vCenter can open an HTTPS connection to the vCenter API endpoint, and that a read-only monitoring account exists in vCenter with the privileges the Zabbix documentation lists for VMware monitoring. Ask the vSphere team to confirm the account's scope in writing. The check is done when a test connection from the polling host succeeds and the account logs in without a password change prompt or lockout. Failing here is cheaper to fix than debugging an empty host later.
Enable the VMware collectors in the configuration
The Zabbix administrator sets the StartVMwareCollectors parameter in the server or proxy configuration file, along with the related VMware cache, frequency and timeout settings. The Zabbix VMware monitoring documentation advises that StartVMwareCollectors should not be below 2 and should not exceed twice the number of monitored VMware services, so size the value against the number of vCenters and services you plan to poll. Restart the service and check the server log for collector processes starting without errors. The step is complete when the log shows the VMware collectors running and no configuration warnings remain.
Create the vCenter host with its credentials
In the Zabbix frontend, the administrator creates a host representing the vCenter instance and assigns it to the appropriate proxy if one is used. The URL of the vCenter SDK or API endpoint and the monitoring account credentials are stored in the host's macros or interface fields, with the password kept in a protected macro rather than typed into plain text where your Zabbix version supports it. Confirm the naming convention and host group with your monitoring owners before creating it. The check is that the host is created, enabled, and shows no configuration error in its interface status.
Attach the vCenter template to the vCenter host
The administrator links the official vCenter template to the vCenter host. This template holds the discovery rules that find ESXi hosts, datastores and virtual machines through the API. Review the template's macros, especially the discovery filters, before linking, because they decide which objects become hosts. Check the template's item list after linking. The step is done when the vCenter host lists the template and its discovery rules are enabled and showing no unsupported items.
Run discovery and confirm datastores and hosts appear
Trigger the vCenter discovery rules manually or wait for the scheduled run, then check the discovered objects in the host's discovery view. The expected result is a list of datastores and ESXi hosts that matches what your vSphere team sees in vCenter. If datastores are missing, review the discovery filters and the monitoring account's visibility before changing collector settings. The check is complete when the first run returns the datastores and ESXi hosts you expect and no discovery errors appear in the log.
Attach the ESXi template to discovered hosts
Discovered ESXi hosts are created as Zabbix hosts. Link the official ESXi template to them, either through the prototype settings in the vCenter template or by a controlled bulk update, so each host gets its hardware, datastore and performance items. Confirm the template version matches your Zabbix server version before linking. The check is that each ESXi host shows the template linked and its interface reporting as available.
Verify that items are receiving values
Open the latest data view for the vCenter host and one ESXi host and confirm that items show recent values rather than unsupported or empty states. Check at least one datastore capacity item and one host CPU or memory item against values shown in vSphere. If items are unsupported, the log usually names the cause, such as a timeout or a missing privilege. Adjust the timeout or cache settings only after the cause is confirmed. The step is done when values arrive on the expected schedule for the vCenter and at least one ESXi host.
Confirm the sequence holds after a collector restart
Restart the Zabbix server or proxy once in a test window and confirm that the VMware collectors come back, the vCenter host reports the same status, and items resume receiving values without manual intervention. Record the discovered object counts before and after so that later changes to filters or permissions are easy to spot. The step is complete when the counts match and the collectors reach a steady state in the log. Repeat this check after each upgrade of Zabbix or the vCenter template.
Sizing StartVMwareCollectors, cache and polling intervals
Zabbix advises that StartVMwareCollectors should not be set below 2 and should not exceed twice the number of monitored VMware services. Treat these as boundaries for your starting point, not as a target to reach. The floor keeps polling from depending on a single collector process, and the ceiling stops you from starting more collectors than the monitored services can use. Before you apply the rule, count the services your configuration actually monitors, since that count sets the ceiling. Confirm in the Zabbix VMware monitoring documentation how services are counted for your version and for your mix of vCenter and ESXi targets, because a count taken from the host list alone may not match what the collectors process.
The other four settings interact with the collector count. VMwareCacheSize sets how much collected VMware data Zabbix keeps in memory between polls. VMwareFrequency controls how often inventory and general item data are polled, and VMwarePerfFrequency controls how often performance counters are polled. A larger inventory and shorter intervals both increase the number of requests each collector sends to vCenter and the amount of data the cache must hold, so a change to one setting often requires a check of the others. As an illustrative case, adding a cluster of hosts to a configuration that already runs close to its cache limit can exhaust the cache even though no interval was changed. Confirm the current default value for each setting in your Zabbix version before you change it.
VMwareTimeout is the setting that tells you most about vCenter health. When collectors hit it, the request to vCenter did not complete in time, which usually points to slow API responses, a busy vCenter, a congested management network or too many concurrent requests from your collectors. Raising the timeout can hide the symptom without removing the cause, so treat repeated timeouts as a signal to examine vCenter performance and the network path first. Lowering the polling frequency may reduce pressure on vCenter, but it also delays problem detection, so agree that trade-off with the teams that depend on the alerts.
Tune these settings in a test environment that mirrors your inventory size and vCenter version, and change one setting at a time. After each change, check the Zabbix server internal metrics that report VMware cache usage and VMware collector busy time, and compare them with a baseline captured before the change. Record the inventory count, the setting values and the observed metrics in a change log, so that a later increase in host count can be matched to a known configuration. Repeat the check after adding a large number of monitored objects, after a vCenter upgrade and after any change to the network path between Zabbix and vCenter. Confirm the exact internal item keys and their meaning for your version in the Zabbix documentation.
Which vSphere objects map to Zabbix hosts, items and triggers
This table shows which Zabbix object represents each vSphere object, how that object is created and the identifier to check after onboarding. Read it from the top down: the vCenter host anchors discovery of ESXi hosts and virtual machines, while datastores are usually collected as items on that anchor. Confirm every template, discovery rule and macro name against the Zabbix version you run before importing anything.
| vSphere object | Zabbix object | How it is created | Key identifier to check |
|---|---|---|---|
| vCenter Server | One host that anchors the VMware connection and holds the vCenter template | Created manually, then linked to the vCenter template | Connection URL macro and the vCenter host name used in discovery |
| ESXi host | One host per hypervisor, with the hypervisor template applied | Discovered from vCenter by low-level discovery rules and host prototypes | Hypervisor name as reported by vCenter, matched against existing hosts |
| Datastore | Item and trigger sets on the vCenter host, one set per datastore | Discovered by a datastore discovery rule with item prototypes | Datastore name, checked for duplicates when several hosts share storage |
| Virtual machine | One host per VM, with the guest template applied | Discovered by a VM discovery rule, optionally filtered by name, folder or power state | VM instance UUID or name, plus the filter macros in use |
| Cluster and folder placement | Host groups or tags that separate hosts by vCenter, cluster or environment | Set by group and tag prototypes on the discovered host | Group and tag values on each host, matched to your ownership model |
| Performance counters | Items fed by vCenter performance statistics, with update intervals set by global macros | Defined in the templates and governed by collection settings | Collection interval and cache settings, sized against the number of VMware collectors |
| Items and triggers | Items and triggers defined by templates and copied to each discovered host | Created from template items and discovery prototypes | Item keys in Latest data and trigger expressions in your version |
| Collector capacity | Background VMware collector processes on the Zabbix server | Set in the server configuration file | StartVMwareCollectors, which Zabbix advises keeping at 2 or higher and at no more than twice the number of monitored VMware services |
How new virtual machines become Zabbix hosts through discovery
New virtual machines become Zabbix hosts through low-level discovery (LLD). The vCenter monitoring template carries discovery rules that query the vCenter for VMs, datastores and ESXi hosts. Each rule produces discovered resources, and host prototypes on that rule turn each one into a host, with its group, name and linked templates set in advance. The practical decision is which resources should become hosts at all. Read the discovery rules in your release's vCenter template before you enable them, and confirm the rule names and the prototypes each one creates, because these differ between versions.
Discovery filters decide what gets created. A filter compares a discovered macro, such as a VM name or another property the rule exposes, against a condition, and only matching resources proceed to host creation. Filters can be used to include a set of VMs, such as a naming pattern for a production tier, or to exclude test templates and appliances. Filter syntax, including whether conditions are regular expressions and which properties are available for matching, depends on the release. Confirm both against the Zabbix VMware monitoring documentation for your version and test each filter on a copy of your inventory before enabling it across the whole vCenter.
Discovery frequency and removal are controlled on the discovery rule itself. The update interval sets how often the rule queries vCenter, and it competes with the rest of the VMware workload for collector capacity. Zabbix's VMware guidance says StartVMwareCollectors should not be below 2 and should not exceed twice the number of monitored VMware services, alongside the cache, frequency and timeout settings. When a VM disappears from discovery results, the rule's lost resources setting determines how long its host remains before Zabbix disables or removes it. Confirm the default values and the available actions for your release, and agree on them with the team that retires VMs.
Renames and moves are where duplicate hosts usually appear. If a host name is built from a display name, a renamed VM can look like a new resource to discovery while the old host lingers until the lost resources period expires. Choose host name and visible name prototypes deliberately, and check which VMware identifiers the rule exposes for use in names. Before go-live, rename and move a test VM in a non-production vCenter and check the host list, the problem queue and the discovery results. Record the result as an acceptance test, because the behavior depends on your release and on how the prototypes were written.
Securing the vCenter account, credentials and collector traffic
The vCenter account, its secrets, the network path from Zabbix to vCenter and the people who can see the resulting hosts form one trust chain. A compromised monitoring account or an unverified certificate exposes the virtual infrastructure, so decide each control before the first collector connects.
Read-only vCenter monitoring role
Create a dedicated vCenter account for Zabbix and bind it to a role that grants read access only. Assign the role to the datacenter or cluster objects Zabbix needs to discover, so the account cannot change VMs, snapshots or permissions. Ask the VMware documentation which privileges your Zabbix version and templates require, then test the account before handing it to the monitoring team. Record who owns the account and when its password will rotate.
Secret macros for vCenter credentials
Store the vCenter username and password in Zabbix secret user macros on the host or host group that uses the VMware templates, so the values are masked in the frontend after saving. Confirm that your Zabbix version supports the secret store your organization has approved, and check how those macros appear in exports, API responses and audit logs. Limit who can edit host macros, since users with host edit rights may be able to change or expose credential values depending on configuration. Make credential rotation a runbook step that updates the macro and tests the connection.
Restrict collector access to the API port
Allow connections to the vCenter API port only from the Zabbix server and the proxies that poll VMware, and deny all other sources at the firewall or network policy layer. If you use proxy groups, every member that can receive redistributed hosts needs the same allowance, so include the full group in the rule set and update it when proxies change. Confirm the port your vCenter listens on, then verify the path with a connection test from each collector. Name a rule owner so network changes do not silently break monitoring.
Validate the vCenter TLS certificate
Keep certificate verification enabled between each collector and vCenter, and make sure every Zabbix server and proxy trusts the issuing certificate authority. Internal certificate chains must be installed in the trust store of each collector host, not only on an administrator workstation. Confirm that the certificate name matches the address Zabbix uses, since a name mismatch usually shows up as a failed login. Add certificate expiry to your renewal calendar, because a lapsed certificate stops all VMware polling at once.
Frontend roles for VMware hosts
Decide who can view VMware hosts and who can edit them, then map those decisions to Zabbix user groups, roles and host group permissions. Keep read access broad enough for operators to see problems and narrow enough that only the monitoring team can change host macros, templates and discovery rules. Apply the same restriction to hosts that carry vCenter credential macros as you apply to the credentials themselves. Review group membership on a fixed schedule and remove access for people who have changed teams.
LDAP or SAML sign-in with provisioning
Zabbix supports internal, HTTP, LDAP, SAML and MFA authentication for the frontend. If your organization already runs a directory or identity provider, use LDAP or SAML so access follows your joiner and leaver process, and enable just-in-time provisioning to create accounts on first login. Confirm how directory groups map to Zabbix user groups and roles, because an incorrect mapping grants the wrong access from the first sign-in. Decide whether local accounts remain for emergency administration, and keep them under separate control.
Why vSphere data stops appearing in Zabbix and how to fix it
This table lists the most common reasons vSphere data disappears from Zabbix, the likely cause of each, the first fix to try and the item or log message to check first. Work down the rows in order, because collector sizing and timeouts often explain several symptoms at once. Confirm exact log text and item states in your Zabbix version before you change settings.
| Symptom | Likely cause | Fix | Check first |
|---|---|---|---|
| Collector timeouts against a slow vCenter | VMwareTimeout is too short for vCenter response times, or VMwareCacheSize is too small for the inventory, so collectors keep re-querying | Raise VMwareTimeout, size VMwareCacheSize for the inventory and review VMwareFrequency and VMwarePerfFrequency for large environments | Zabbix server log entries from the VMware collector that report timeouts |
| Too few collectors for the monitored services | StartVMwareCollectors is below 2, or too low for the number of monitored VMware services | Set StartVMwareCollectors to at least 2 and no more than twice the number of monitored VMware services | Server log entries about VMware collector load, and the collector utilization item in your version |
| Certificate validation errors | The Zabbix server does not trust the vCenter certificate, or the certificate chain is incomplete | Install the issuing CA chain on the Zabbix server and confirm the vCenter certificate matches the configured host name | Server log entries from the VMware collector that cite certificate verification |
| Missing data for some objects | The read-only monitoring role lacks read permissions on some objects such as datastores, clusters or VMs | Grant read-only privileges at the right inventory level, propagate them to child objects and rerun discovery | Discovery results and datastore or VM items that show no data for the affected objects |
| Duplicate hosts created by discovery | Discovery keys hosts on names that change or repeat, or the same VM is found through more than one path | Use a stable unique identifier for host naming, review the host prototypes and remove the duplicate hosts | The host inventory filtered by VM name and the discovery events for the affected VMs |
| Items unsupported after a vCenter upgrade | The vCenter API or metric names changed, or the imported template does not match the Zabbix release | Match the template version to your Zabbix release, reimport it and update or disable the items that remain unsupported | Items in the Unsupported state and the error text shown on each item |
Zabbix VMware vSphere monitoring questions buyers ask before hiring help
What does a Zabbix vSphere monitoring project cost?
Zabbix itself has no license fee, no device limits and no feature gates, so the cost of a project is the work around the software. Who is paid for what: planning, build, testing and handover, whether by your team or a partner, plus the infrastructure that runs Zabbix and any paid support subscription you choose. DeployOpen does not publish a price list. A quote follows a written scope that lists the vCenters, ESXi hosts and virtual machines in scope, the discovery rules, the alerting design, the proxies or collectors, and whether the work extends a Zabbix platform you already run. Ask the quote to separate one-time build effort from ongoing support and upgrades, because those recur on different schedules.
Which factors make VMware monitoring with Zabbix take more effort?
Scope size drives effort more than any single setting. Number of vCenters: each one adds connection, permission and collector planning. ESXi hosts and VMs: more objects increase discovery volume, polling load and the number of hosts Zabbix manages. Discovery rules: the filters that decide which VMs become hosts must be tested against your naming conventions and folder structure. Alerting design: owners, severities, escalation and suppression often take longer than importing templates. Shared Zabbix platform: if the server, database and proxies already serve other teams, changes need coordination and a change window. Ask for an estimate that shows how each factor affects the work.
How long does a Zabbix vSphere monitoring engagement take?
Duration depends on the written scope, and no single timeline fits every vSphere environment. A single vCenter with a modest host count and a standard alerting model is a much smaller piece of work than several vCenters with multiple discovery rules, custom alerting and an existing Zabbix cluster that needs changes. Typical phases are discovery of your environment, a test build, validation of polling and alerts, a production change window and handover. Ask for the phases in writing, along with the dependencies on your team, such as access approvals, change windows and alert owners. Delays in those inputs often last longer than the technical work.
What access and inputs must we provide for vCenter monitoring?
Provide a monitoring account for vCenter with the permissions the Zabbix documentation specifies, and have your vSphere administrators confirm the role before it is created. Also supply a list of vCenters, clusters and datacenters in scope, network paths from Zabbix server or collectors to vCenter and ESXi, a change window for production, and a test environment or lab vCenter where templates and settings can be checked first. Name an owner for each alert category who will accept tickets or pages. Share the naming and folder conventions used for discovery filters, and confirm how certificates are handled. Missing alert owners is a common blocker, so settle that before the build starts.
Can our own team set up Zabbix VMware monitoring alone?
Yes, a team with Zabbix and VMware skills can build and run this without a partner, because the software is open source with no license fee or device limits. The question is capacity and risk. Building templates, tuning collector settings, designing discovery and alert routing, and testing failover take sustained effort. Consider whether you have someone who owns the Zabbix platform, can test against vCenter without affecting production, and can keep the setup current after handover. Paid Zabbix support subscriptions are available if you want vendor-backed response commitments. DeployOpen can take on the full build or specific parts, such as collector design or the alert model, under a written scope.
Does DeployOpen provide compliance evidence for vSphere monitoring?
DeployOpen prepares systems, configuration, documentation and evidence for compliance assessments, such as records of what is monitored, alert procedures and change records. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Before scoping, identify which control requirements your assessor expects monitoring to support, and ask the assessor what evidence format they accept. For vSphere monitoring, evidence typically covers the monitored scope, who receives alerts, how incidents are handled and how configuration changes are recorded. List those artifacts in the written scope so the deliverables match what your assessor will ask for.
How many StartVMwareCollectors should we configure for vCenter monitoring?
Zabbix guidance sets StartVMwareCollectors to no lower than 2 and no higher than twice the number of monitored VMware services. Use that range as a guardrail, and choose a value based on the number of vCenters and services you monitor and the load the collectors carry. Tune it together with VMwareCacheSize, VMwareFrequency, VMwarePerfFrequency and VMwareTimeout, because polling intervals and cache size change how many collector processes are useful. Change one setting at a time, watch the internal VMware collector metrics on your Zabbix server, and record the final values in your build documentation. Confirm the settings against the documentation for your Zabbix version before any production change.
How does discovery of new virtual machines as hosts work?
Zabbix creates hosts for discovered virtual machines through discovery rules and host prototypes in the vCenter and ESXi templates. Filters decide which VMs qualify, so they must match your naming, folder and tag conventions. Test the filters on a sample of VMs, then check how host names, host groups and templates are assigned. Decide in advance how removed VMs are handled, because disabled or deleted hosts can leave alerts or history behind. In shared environments, agree who approves new hosts, so monitoring coverage does not grow faster than the owners who respond to its alerts. Confirm the exact prototype and filter options in the documentation for your Zabbix version.
How DeployOpen scopes, delivers and supports Zabbix VMware monitoring
DeployOpen plans, builds, documents and supports Zabbix VMware vSphere monitoring inside your own infrastructure, including your vCenter, ESXi hosts and datastores. Most engagements are fixed-scope, and ongoing support and upgrades are available as a retainer after handover.
How we scope
- The written scope names the vCenter instances, ESXi hosts, datastores and VM groups to be monitored.
- We record the expected number of VMware services and polling intervals before any collector is sized.
- Discovery rules for new VMs, and which ones become Zabbix hosts, are agreed in the scope.
How we build
- Configure the VMware collector processes, cache size, polling frequencies and timeouts, and document each value.
- Set the StartVMwareCollectors count within Zabbix guidance: at least 2, and no more than twice the monitored VMware services.
- Import the vCenter and ESXi templates, then test discovery of new VMs against a non-production vCenter first.
How we hand over
- Written documentation covers the collector settings, template changes, discovery filters and the reasons behind each value.
- Your team walks through problem triggers, discovery results and host onboarding steps before handover is signed off.
- Your team receives the configuration files and template exports needed to rebuild the setup in your environment.
How we support
- Ongoing support is available as a retainer, covering collector tuning, template updates and troubleshooting.
- Zabbix version upgrades are planned against the support windows in Zabbix's life cycle policy for your LTS line.
- Zabbix offers paid technical support tiers, which you can weigh alongside a DeployOpen retainer when planning escalation paths.
