VMware ESX host inventory in GLPI

How GLPI inventories VMware ESX hosts remotely

GLPI Agent can inventory VMware ESX hosts remotely, and the GLPI Inventory plugin brings those results into GLPI as asset records. This matters when hosts and their virtual machines are missing from the asset register or are out of date, and when a change or outage review needs to know which virtual machines run on which host. Without current host-to-VM relationships, impact analysis depends on people remembering where workloads sit. The remote ESX capability is one of several functions the GLPI Agent documentation describes, alongside its hardware and software inventory and network discovery.

The remote ESX feature sits alongside the agent-based inventory that GLPI Agent performs on Windows, macOS and Linux machines. That inventory runs on the machines themselves, while the ESX capability reaches the hypervisor hosts from outside. GLPI Agent is the successor of FusionInventory Agent, so teams that already run FusionInventory will recognize much of the model. Confirm in the GLPI Agent documentation exactly which host data and virtual machine attributes are collected, which credentials the ESX queries need, and which network paths must be open from the agent to the hosts before you plan the rollout.

Before you start, decide which agent host will run the ESX queries, who owns the read-only VMware account it uses, and how often the data should refresh. Then compare the first results with your existing register to find duplicate, orphaned or misnamed host records before the import rules create new assets. Check that virtual machines link to their hosts in GLPI, since that relationship is what makes outage and change impact analysis work. Document the account scope and the network rules so the security team can review them with the rest of your inventory design.

Choosing where and how the ESX inventory runs

This table compares three ways to run remote ESX inventory in GLPI: a dedicated collector on a management network, an existing management host, and an agent on each ESX host where that is possible. Read each row against your own network segmentation and credential policy, then use the last row to plan how many collectors a large estate needs. The main takeaway is that the placement choice sets your failure domain and maintenance load more than it sets the inventory data itself.

Factor	Dedicated collector on management network	Existing management host	Agent on each ESX host
Network reach needed	Reaches vCenter and ESX management interfaces on the management VLAN, plus the GLPI server over HTTPS	Depends on what the host already reaches. Confirm it can open the ESX and vCenter management ports and reach GLPI	Needs agent-to-GLPI connectivity only if the agent can run on the host itself; confirm support for your ESX version first
Credential handling	A read-only service account stored on one tightly controlled host, with access limited to that collector	Credentials sit on a host that often serves other purposes, so the account and its secrets need wider review	Credentials are held per host or per configuration, which multiplies places to rotate and audit
Failure domain if collector is down	Inventory for all hosts it covers stops until it recovers. Stale data is visible in GLPI	Outage of the shared host also stops unrelated services, so inventory failure is less visible	Only the affected host loses reporting, which limits impact but leaves more gaps to track
Maintenance load	One agent or service to patch, monitor and update, plus its certificate and account lifecycle	Lowest install effort, but changes to the host's patch cycle or role can break inventory without warning	Highest ongoing effort: upgrades, configuration and credential changes must be repeated across every host
Suitability for large estates	Scales by adding collectors per management segment, which keeps credentials and traffic scoped	Usually suits small estates or a pilot, as one host becomes a bottleneck	Practical only where hosts can run the agent and support staff can manage the volume of installations
Collectors needed for a large estate	Plan one per management network or site, then size by host and VM count measured in your test environment	Often one per segment, but only after confirming load on the shared host	Not a collector count question. Confirm the approach works for your hosts before scaling it

Linking virtual machines to hosts for impact analysis

The reason to model the host-to-VM relationship is impact analysis. When an ESX host needs patching, a firmware fix or an emergency reboot, or when it fails outright, the team needs to see every virtual machine running on it, who owns each one and which services depend on it before anyone touches the host. A flat list of hosts and a separate list of VMs does not answer that question. The link between the two asset types does, and it is only as good as the data behind it. Treat the relationship as a control you verify, not a column that appears on its own.

Before you build any impact report, confirm in your own GLPI version how the inventory creates and connects the records. Check which asset types the ESX collection writes (the host as a computer-type record and each guest as its own record, or another arrangement), which relation type joins them and whether that relation is visible from the host page, the VM page or both. Then test the lifecycle with a known VM: migrate it to another host through vMotion, power it off, delete it and watch what GLPI does on the next inventory run. Record whether the old relation is removed, retained as history or left pointing at a stale host. Confirm these behaviors against the GLPI and GLPI Inventory plugin documentation for your release and in a test instance before relying on them.

The most common data-quality problem is duplication. A VM that is collected through the hypervisor and also reports through its own GLPI Agent can appear twice, once as a guest linked to the host and once as a standalone computer with a different owner or no relation at all. An impact query then undercounts or overcounts affected systems. Decide up front which source is authoritative for each VM, use the GLPI rule engine to match on a stable identifier such as the VM UUID or serial rather than the display name, and set a review step for unmatched records. Write down the expected count of VMs per host from the hypervisor and compare it with GLPI after each collection cycle.

Design decisions that shape a VMware inventory project

Remote ESX inventory touches identity on the hypervisor, network paths, GLPI's data rules and the load on your management layer. Settle these five questions in writing before the first collection runs, because each one changes what GLPI records and how much work the next change will be.

Account and privileges on ESX

Decide which account GLPI Agent uses to query each ESX host or vCenter, and what that account is allowed to read. The question is whether a read-only account with the minimum inventory rights is enough for the data your team needs. Ask your VMware administrators to create a dedicated account, not reuse a personal or administrative login, and record who owns its password rotation. A narrow account limits damage if the credential leaks, but it can return incomplete VM data if rights are missing, so test one host before rolling out to the cluster.

Collector placement and network path

Decide which machine runs the agent that talks to the ESX hosts or vCenter, and whether it sits in the same network zone. The question is which firewall rules must open between that collector and the management interfaces. A collector close to the hypervisors keeps traffic inside the management network, while a central collector is easier to patch but needs a permitted path through segmentation. Confirm the agent version and the protocol your VMware version supports with the GLPI Agent documentation before you commit to a placement.

Entity and asset rules for received data

Decide which GLPI entity receives hosts and virtual machines, and which rules assign them to the right entity, location and asset type. The question is who should see each host, since entity and profile settings control visibility in GLPI. Without rules, ESX hosts may land in a default entity or mix with physical workstations. Write the matching criteria down, such as vCenter name or cluster, and test them with a small set of hosts so that later changes do not reshuffle existing assets.

Inventory frequency and hypervisor load

Decide how often inventory runs against each host or vCenter. The question is how fresh the data must be for impact analysis versus how much query load the management layer can absorb. Frequent runs across large clusters raise load on vCenter and the ESX hosts, and they also grow the GLPI database. Start with a slower schedule, observe the effect on management response times, and tighten it only where a team has a documented need. Stagger tasks so that all hosts are not queried at the same moment.

Avoiding duplicate VM assets

Decide how a virtual machine that also runs GLPI Agent is matched to one asset rather than two. The question is which identifier GLPI uses to merge records, such as serial, UUID or name, and how the rule engine handles conflicts. A VM reported once by the hypervisor and once by its own agent can appear twice if identifiers differ, which breaks counts and impact analysis. Review the matching rules with a sample of VMs that have both sources, and decide which source wins for each attribute before the first full run.

Setting up remote ESX inventory in GLPI

This sequence takes a team from an unconfigured GLPI instance to a scheduled, staged inventory of VMware ESX hosts and their virtual machines. Each step closes with a check, so problems surface on one host before the rest of the estate is added.

Confirm GLPI and plugin versions
Record the GLPI core version and the GLPI Inventory plugin version running on your server, then confirm in the plugin's documentation and release notes that the pairing supports remote ESX inventory. Check the GLPI version against the requirements for PHP and the database before you touch the agent. Done means you have a written version pair and a note of any gaps you need to close, such as a plugin that must be upgraded first. Note that GLPI 11 suspends plugins after a new version is detected, so reactivate and test the plugin after any core upgrade.
Deploy GLPI Agent on the collector
Choose a Windows, macOS or Linux machine that can reach both the ESX management interface and your GLPI server, and install GLPI Agent on it. Point the agent at your GLPI server URL during installation or in its configuration. The agent performs remote ESX inventory, so the collector is the machine that talks to the hosts, not the hosts themselves. Verification: run the agent manually once and confirm it reports a successful connection to GLPI in its log, without yet involving any ESX host.
Create a read-only ESX account
Ask your virtualization team to create a dedicated account on the ESX host or vCenter used for inventory, with read-only permissions limited to the objects the agent needs to query. Do not reuse an administrator account or a shared service account from another tool. Record who owns the account, where its password is stored, and the rotation process. Verification: log in with the new account through the ESX interface or a standard client and confirm it can view host and VM properties but cannot change configuration. Confirm the exact permission set with your VMware administrator and the plugin documentation.
Configure the ESX target and credentials
In the GLPI Inventory plugin, add the ESX host or vCenter as a remote inventory target, enter the read-only account, and assign the target to the correct entity so imported records land in the right place. Store the credential as the plugin expects and limit who can view it in GLPI. Verification: use the plugin's test or connection check for this one target, and confirm the target status shows a successful login before you schedule anything.
Run a first inventory task on one host
Create an inventory task that covers a single, non-critical ESX host and run it manually from GLPI. Choose a host whose VMs you can check independently, so you can compare the results with what the hypervisor shows. Watch the task log for errors such as authentication failures, timeouts or unreachable hosts. Verification: the task finishes without errors and the log lists the host and its guests as processed. If it fails, fix the cause on this one host before adding any others.
Check host and VM records and relations
Open the imported host record in GLPI and compare its hardware, model, serial number, and resource details with the ESX console. Then open the VM records and confirm that each VM is linked to its parent host. Check that names, power state, CPU and memory values match the hypervisor. Verification: pick at least three VMs, confirm each appears once, and confirm each relation points to the correct host. If VMs appear as duplicates or unlinked devices, review the import rules before continuing, since they control how the agent data is matched and assigned.
Schedule inventory and expand in stages
Once the single-host test is clean, schedule the inventory task at an interval your operations team agrees on, and add hosts in batches grouped by cluster or site. After each batch, repeat the record checks from the previous step and review the task log for failures. Keep a list of hosts that are excluded and the reason for each. Verification: after each batch, the new hosts and their VMs appear once, relations are correct, and the scheduled task runs without unexplained errors across two cycles before the next batch is added.

Securing ESX credentials and inventory traffic

Remote ESX inventory means GLPI holds credentials for your hypervisors and a collector host talks to them on your behalf. The cards below cover where that trust sits and how to limit it. Confirm each control against the GLPI Agent and GLPI Inventory versions you run before you rely on it.

Protect stored ESX credentials

The ESX account details you enter for remote inventory are stored in GLPI, so they are a target. Confirm how your GLPI version stores these secrets and whether the values are encrypted at rest using the instance's encryption keys. Back up the key files alongside the database, and make sure those backups are restricted to the same people who manage the platform.

Restrict who can read and change tasks

Anyone who can edit an inventory task or its credentials can point the collector at a different host or reuse the account. Limit these rights to a small administrator profile, and check whether your version lets you separate the right to run a task from the right to view its stored secrets. Review the profile assignments after every staff change.

Use a read-only hypervisor account

The account that GLPI Agent uses against the ESX host should only read inventory data. Create a dedicated account with the read-only role and no rights to power, migrate, or reconfigure virtual machines. Confirm the exact privileges the agent needs for your ESX or vCenter version, then grant only those.

Treat the collector host as privileged

The collector holds the network path to your hypervisors and the credentials needed to query them, so compromise of that host exposes your virtualization layer. Run it on a hardened server in the management zone, patch it on your normal cycle, limit inbound access, and log administrative sessions on it. Do not reuse it for general workloads.

Encrypt collector to GLPI traffic

Inventory data moves from the collector to GLPI over HTTP or HTTPS, depending on your setup. Require HTTPS with certificate validation for that path, and handle private certificate authorities deliberately. The agent communication hardening topic in this group covers the transport settings in detail, so follow it before you enable remote tasks in production.

Audit changes and monitor failed runs

Record who created, edited, or ran an inventory task, and keep those records outside the GLPI instance if your policy requires it. Watch for repeated authentication failures against ESX, which can signal a locked account or a changed password. Set an owner for failed runs so stale or broken tasks do not quietly stop refreshing your VM records.

What to confirm for your VMware environment

When hosts sit under vCenter Server, the first question is how the GLPI Agent reaches the inventory data: through the vCenter API, directly through each host, or both. That choice determines which fields, clusters and relations arrive in GLPI and how much load lands on the management layer. Check the GLPI Agent documentation for the remote ESX inventory method you plan to use, then confirm the following in your environment:

Supported versions: Confirm the vCenter Server and ESX host builds your agent and Inventory plugin versions support, since support is tied to exact releases.
Relations collected: Verify whether host-to-VM links, cluster membership and datastore assignments arrive as linked records or only as text fields.
Clusters and datastores: Check how clusters appear in GLPI and whether a shared datastore creates one asset or duplicates across hosts.
Refresh cadence: Measure how quickly power state changes and vMotion moves reach GLPI, because the schedule belongs to your agent and task settings, not to vCenter events.
Deleted VMs: Remove a test VM in vCenter and confirm whether its GLPI record is kept, marked or left stale.

Run the collection against one cluster with a known set of VMs and compare the GLPI records with vCenter before you enable the full estate.

Questions buyers ask before inventorying VMware in GLPI

What drives the cost of inventorying VMware hosts in GLPI?

The cost follows the written scope, and the main drivers are the number of ESX hosts and virtual machines, how many network zones and vCenter or standalone host connections need to be reached, the state of existing GLPI rules, and the quality of the asset data already in GLPI. Each extra zone adds credentials, network path checks and test runs. Cleaning up duplicate or stale asset records usually takes more effort than the initial connection. The work is one-time for the build and recurs only where you choose ongoing support. Ask any provider for a quote that lists each host group, each zone, the rule work and the handover, and separates build effort from recurring operations. DeployOpen does not publish a price list, and its quotes follow from a written scope.

How long does a first VMware inventory rollout take in GLPI?

Duration depends on how quickly access and approvals arrive, how many zones must be tested, and how much data cleanup the rule set requires. A small estate with one reachable management network and clean asset data can move quickly, while a large estate split across several zones with existing duplicates takes longer because each zone needs its own validation pass. No duration is given here because none has been researched for this work. Ask for a timeline in the written scope that shows the discovery and access phase, the pilot on one host group, the full run and the rule tuning window.

What does the client team need to provide for ESX inventory?

The work needs four groups of input from your side:

A read-only account on each vCenter or ESX host that the inventory component can use to query host and VM details.
Network paths from the component that runs the inventory to the management interfaces of those hosts, including any firewall rules that must be opened.
Named owners for each host cluster, business unit and VM group, so that imported assets can be assigned to the right entity and contact.
A decision on which VMs are production, test or retired, because that drives how records are created and reviewed.

Confirm the exact account rights and port requirements with your VMware administrators and your security team before the pilot. Change approvals for firewall or account changes often set the schedule more than the build does.

Can an internal team inventory VMware in GLPI without a partner?

Yes, an internal team can do this if it has someone who administers the VMware estate, someone who runs GLPI and manages its plugins, and time to test rules against real data. GLPI Agent and the GLPI Inventory plugin are open source, and the GLPI Agent documentation describes remote ESX inventory as one of its functions. The harder parts are usually the access model, the rule design and the duplicate handling, which need someone who has done it before and can explain the trade-offs. A partner is most useful when the estate is large, the schedule is fixed or the internal team has no spare capacity for a pilot and review cycle. Either way, write down the access model, rule order and owners so the result can be maintained.

How does GLPI handle VMs that also have an agent installed?

A VM can be seen twice: once from the hypervisor through remote ESX inventory, and once from GLPI Agent running inside the guest operating system. Without rules, the same machine can appear as two assets with different data. Plan a matching strategy before the first full run. Typical approaches match on a stable identifier such as a serial or UUID where available, use the hostname with the entity as a secondary key, and set rule order so that agent data takes precedence for guest details while the hypervisor record supplies the host link. Test the matching on a pilot group and review the unmatched records. Confirm the exact matching options in your GLPI version's rule documentation before you commit to a design.

Does a GLPI Network subscription change how VMware inventory is built?

The inventory design stays the same whether you run self-hosted GLPI or a subscription, because the agent and plugin functions are part of the open-source stack. What changes is the support model, the licensing basis and the services included. According to the GLPI Network subscriptions page, the public cloud option costs 19 euros per user per month and the private cloud option 21 euros per user per month with a 25-user minimum, while self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). Check which tier includes the support level and marketplace plugins you need, and confirm whether agent or asset counts affect the tier you choose before you compare it with a build-only scope.

What should be ready before the first VMware inventory run?

Before the first full run, confirm that the GLPI instance is on a supported version and that its database and configuration keys are backed up, because the GLPI update procedure requires those backups and plugin activation can change after an update. Confirm the inventory plugin and agent versions are compatible with the GLPI release in use. Prepare the entity structure and the rule order on paper, define the pilot host group, and agree on who reviews unmatched or duplicate records. Ask the vendor or your own engineers to confirm the exact plugin settings for remote ESX inventory in your version, since those settings change between releases.

How DeployOpen scopes and delivers VMware inventory in GLPI

DeployOpen plans, implements, tests, documents and supports GLPI in infrastructure you control, including the remote ESX inventory and VM-to-host linking described on this page. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Written scope lists which vCenter or ESX endpoints, clusters and VM attributes are in inventory
Credential model for read-only API access is agreed with your virtualization and security teams
Entity assignment, import rules and the VM-to-host relationships expected for impact analysis are defined
Quote follows from the written scope; ask for each deliverable to be listed separately

How we build

GLPI Agent and GLPI Inventory plugin are installed and configured in your GLPI instance and network
Remote ESX inventory tasks are set up and tested against a representative set of hosts
Import rules are tuned so hosts and virtual machines land in the correct entities and asset types
Test results on host and VM linkage are recorded before the inventory is treated as ready

How we hand over

Runbook covers task schedules, agent versions, credential rotation and troubleshooting steps
Configuration is documented so your team can reproduce the setup in another environment
Knowledge transfer session walks your administrators through the inventory and linking workflow
Handover records list open items, owners and the next GLPI upgrade checks to schedule

How we support

Ongoing support, GLPI upgrades and plugin updates are available as a retainer
Retainer scope should confirm how new ESX hosts and VM changes are reviewed and recorded
Plan checks against GLPI 11 and 12 release notes before major updates, with plugin reactivation tested
Ask for response expectations and escalation paths to be written into the support agreement