An inventory answers "what do I have?". A CMDB answers "what goes down together when this fails?". The bridge between the two in GLPI is not the Connections tab, as many assume - it is impact analysis, and that is exactly where most CMDB projects stall. This guide covers the four relationship mechanisms GLPI offers, which to use for each case, and the queries we run in production support to find the blind CMDB.
Inventory vs CMDB: the difference that changes incident response
Inventory is a record: brand, model, serial number, warranty, owner. It is asset control and it is where everyone starts - with GLPI Agent automatic inventory you populate hundreds of assets in days. CMDB is what comes next: the relationship layer that answers the question that matters mid-incident - if this switch goes down, which servers, services and users stop with it?
| Aspect | Inventory | CMDB |
|---|---|---|
| Question it answers | What do I have? | What depends on what? |
| Unit | Asset (item) | Relationship between CIs |
| How it is populated | Automatic (GLPI Agent) | Manual, a modeling decision |
| Value during an incident | Find the equipment | Predict the blast radius |
The common strategic mistake is treating the CMDB as "more detailed inventory" and trying to fill in a relationship for everything. It does not scale and no one maintains it. A good CMDB is lean: only the critical CIs and the dependencies you would actually use in an impact analysis.
The four relationship mechanisms in GLPI
GLPI does not have a single "relationship field" - it has four distinct mechanisms, each in its own table, and picking the wrong one is the root of most CMDBs that do not work. In production support, mistake number 1 is building everything on the Connections tab thinking that is the CMDB, then discovering the impact analysis is empty.
| Mechanism | Table | Models | Directed? | Populated by |
|---|---|---|---|---|
| Direct connections | glpi_computers_items | Peripheral attached to a computer (monitor, printer, phone) | No | Inventory or manual |
| Network ports | glpi_networkports_networkports | Cabling between two ports (switch ↔ host) | No | SNMP/LLDP or manual |
| Appliances | glpi_appliances_items | A service/application as a CI + the infrastructure that supports it | No (grouping) | Manual |
| Impact analysis | glpi_impactrelations | Dependency graph to compute the blast radius | Yes (source → impacted) | Manual (Impact tab) |
Connections and network ports model physical links. Appliances groups the infrastructure of a service. And impact analysis - the only directed one - is the dependency graph that actually answers "what goes down together". All four coexist; the confusion comes from expecting one to do another's job.
Model the service as a CI: Appliances
The step missing from most inventories is giving the service an existence of its own. "Email", "ERP", "Customer portal" are not hardware - they are services running on top of hardware. In GLPI the right object for this is the Appliance (Assets menu), available since GLPI 9.5. An Appliance is a logical CI to which you link the items that support it:
- Create the Appliance (e.g. "Email Service").
- On the associated items tab, link the supporting CIs: the server, the core switch, the storage, the internet link. This writes to glpi_appliances_items.
- Record the technical owner, the support contract and the vendor on the Appliance itself.
From then on the service exists as a queryable entity: you open "Email Service" and see the list of infrastructure that supports it, without relying on anyone's memory.
The real CMDB: impact analysis
Grouping infrastructure in an Appliance tells you who supports what, but it does not compute the blast radius of a failure. That is the job of the Impact analysis tab (present since GLPI 9.4), which draws a directed dependency graph stored in glpi_impactrelations. Each edge has a source and a target: itemtype_source, items_id_source impacts itemtype_impacted, items_id_impacted.
Direction is the detail that separates those who understand from those who just dragged boxes around. An edge from the switch to the server means "the switch impacts the server". When the switch goes down, you follow the arrows forward and see everything that stops with it. The common mistake is drawing the arrow backwards - linking the server as impacting the switch - and then the impact analysis of the failed switch comes out empty, exactly when you need it most. Always model in the direction of the dependency flow: from the base infrastructure up to the service on top.
A field caveat: the graph is rendered in the browser and gets slow with hundreds of nodes. Do not try to draw the whole estate. Use business criticality (the Business criticity dropdown, under Setup > Dropdowns) to flag the critical CIs and put only those on the graph. A dense CMDB is an abandoned CMDB.
Diagnostic SQL: finding the blind CMDB
When a support contract starts, before discussing process, we run a coverage audit: which critical CIs are in the inventory but outside any impact relationship. Those are the points where impact analysis will lie, saying "nothing is affected" when in fact no one modeled it. The query lists computers with no edge at all - neither as source nor as target:
-- Computers with NO impact relation at all:
-- they exist in the inventory but are invisible to impact analysis.
SELECT c.id, c.name
FROM glpi_computers c
LEFT JOIN glpi_impactrelations r
ON (r.itemtype_source = 'Computer' AND r.items_id_source = c.id)
OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id)
WHERE c.is_deleted = 0
AND r.id IS NULL
ORDER BY c.name;And the other side: given a service modeled as an Appliance, which CIs it groups. Useful to check whether "Email Service" really points to the right server and switch before trusting it during a middle-of-the-night incident:
-- Items supporting a specific Appliance (service):
SELECT ai.itemtype, ai.items_id
FROM glpi_appliances_items ai
INNER JOIN glpi_appliances a ON a.id = ai.appliances_id
WHERE a.name = 'Email Service';We run these two queries straight against the database (via a read-only SQL client), never through an interface LIKE search, because we want the exact number of orphans to size the modeling effort.
Auto-discovery does not build the CMDB for you
It is worth resetting an expectation that shows up in every project: network inventory via SNMP discovers physical connections - if GLPI Agent scans the switches over SNMP and LLDP/CDP is enabled, the network ports between switch and host are populated on their own in glpi_networkports_networkports. That is great and you should not do it by hand. But the logical service dependency - "email depends on this server" - no protocol discovers. The agent does not know that a given Exchange process is your critical email service. That layer is always a human decision, and it is precisely what turns inventory into a CMDB.
Keep the graph alive or it lies
An outdated CMDB is worse than no CMDB: it gives false confidence. You swap a switch, forget to update the relationship, and at the next failure impact analysis points to equipment that no longer exists. Tie graph maintenance to the change management process - every change to a critical CI must review its impact relations before closing. Without that discipline the graph ages in weeks. It is the same principle as the knowledge base: a relationship no one maintains becomes noise.
Do you need a GLPI CMDB that supports real impact analysis, with the graph modeled on the right CIs and kept in step with changes? Discover NexTool's GLPI support and maintenance service.
Reviewed by the NexTool Solutions team.
