Why teams model data center racks in GLPI and what the module covers
A team that tracks its servers in GLPI but cannot say which rack holds a given device, how much power that rack can draw or which PDU feeds it has an inventory without a physical model. The GLPI data center module closes that gap by treating the server room as structured data. According to the GLPI racks documentation, a rack is an object for organizing and tracking equipment installed in a data center or technical room, and it carries fields for the data center position, location, number of units, height, maximum power in watts and maximum weight. Those fields let you check whether a planned installation fits before anyone lifts a chassis into place.
The module is broader than racks. The GLPI asset documentation lists enclosures, PDUs, passive devices and cables alongside racks as asset types, so a model can show the chassis that sit in a rack, the power distribution that feeds them, the patch panels and cable runs between them and the equipment that connects to each. The GLPI 11.0.0 changelog adds a per-room data center grid size setting, which determines how the room layout is drawn and therefore how racks are placed relative to each other. Confirm the exact grid behavior in your GLPI version before you size rooms, because the grid defines the coordinate space your layout will use.
Teams usually run this as its own workstream rather than a side task of the general inventory rollout. The work involves agreeing on unit numbering, power and weight data from facilities teams, deciding which passive items are tracked, and deciding who keeps the physical view current when equipment moves. Ask who owns each of those decisions before the first rack is entered, because a model that drifts from the floor loses its value quickly.
What GLPI's data center objects record
GLPI models a server room as a set of linked objects: the room itself, the racks inside it, and the power and cabling equipment that feeds them. Each object type holds different fields, so the physical view is only as accurate as the records you enter for each one.
Racks and their physical limits
A rack record holds its data center position, location, number of units, height, maximum power in watts and maximum weight. These fields define the capacity you plan against, so enter the rated values from the hardware label or the vendor datasheet rather than estimates. Before you load equipment, confirm which fields your GLPI version exposes and whether the unit count drives any placement checks.
Enclosures and chassis
Enclosures are the asset type for multi-slot chassis that hold blades or other modular equipment inside a rack. Recording the enclosure separately from the rack lets you show which unit space a chassis occupies and which modules sit inside it. Confirm how your GLPI version links enclosure records to the hosted equipment they contain before you rely on that relationship for capacity reports.
PDUs and power feeds
Power distribution units are tracked as their own asset type, which is where the power side of a rack record gets its real source. A PDU record tells you what feeds a rack and how much load the rack can draw. Check that every PDU is associated with the rack it powers, and that your maximum power value on the rack matches what the PDU and upstream circuit can actually supply.
Passive devices and patch panels
Passive devices cover equipment with no power draw, such as patch panels and cable managers, which still occupy unit space and affect airflow and cabling layout. Track them so the rack's unit count reflects what is physically mounted, not only the powered servers. Confirm with your team whether passive devices count toward the unit total in your installation.
Cables and connections
Cable records document the physical runs between devices, panels and PDUs. Without them, a rack view shows equipment but not how it is connected, which is the detail technicians need during a fault or a move. Decide early who owns cable entries and how they are updated when a patch is changed, because stale cable records are harder to spot than stale equipment records.
Data center and room structure
The data center object is the parent that places racks in a room or technical area. GLPI 11.0.0 added a per-room grid size setting, so the layout you see depends on the grid you configure for each room. Confirm the grid dimensions with the room's real floor plan before you position racks, because a wrong grid makes every later position record misleading.
Which modeling choices to settle before loading data
This table compares the modeling decisions that shape a GLPI data center model, with the options each one offers and when each fits. Read each row as a choice to make with your facilities and asset owners before any racks or devices are imported. The main takeaway is that data center objects, unit conventions and entity boundaries are costly to change once equipment records depend on them.
| Decision | Options | Trade-off | When to choose it |
|---|---|---|---|
| Data center granularity | One data center object per site, or one per room or hall | A site object is simpler to report on, but rooms owned by different teams or with different power feeds are harder to separate | One object per site for small estates; one per room where rooms have distinct owners, power or cooling |
| Rack unit and height convention | Count units from the bottom or top, and record the number of units and height per rack | Mixed conventions across sites make position and capacity checks unreliable | Pick one convention for the whole estate and document it before importing positions |
| Per-room grid size setting | Use the 11.0.0 per-room grid size setting to match each room's layout, or keep the default | A per-room grid keeps the physical view accurate for each room but adds one more setting to maintain | Use it where rooms have different rack arrangements that staff need to see on screen |
| PDU modeling | Model PDUs as separate assets linked to racks, or record power only as rack attributes | Separate PDU records show feeds and outlets, but add data entry and upkeep | Separate records when power capacity planning or feed redundancy checks are required |
| Cable and passive device modeling | Record patch panels, cables and passive devices individually, or only as summary notes | Detailed records support tracing, but they multiply records that must stay current | Detailed records where connectivity tracing is a documented operational need |
| Rack power and weight limits | Enter maximum power and maximum weight per rack from site design data | Accurate limits support planning, but values drawn from memory cause false confidence | Enter them from engineering records and confirm with facilities before using them for placement decisions |
| Entity boundaries | One entity for the whole estate, or separate entities per owning team or site | Separate entities restrict visibility and ownership, but cross-team reporting needs more setup | Separate entities where teams must not edit each other's rooms or racks |
| Source of truth for placement | GLPI as the record, or a separate DCIM tool synced into GLPI | Single-tool records are simpler to govern, but a dedicated DCIM may already hold accurate layouts | Use GLPI when it is the inventory of record; confirm integration needs before choosing a sync |
How a data center model moves from spreadsheets to a live physical view
The sequence turns a spreadsheet or walkthrough notes into GLPI records for rooms, racks, power and equipment positions, then puts a change process in place so the physical view stays accurate after go-live.
Agree the room and rack inventory
The client's facilities or data center lead and the GLPI owner list every server room, technical room and rack in scope, along with the equipment expected in each. Sources usually include existing spreadsheets, floor plans, asset exports and site walkthrough notes. The step is done when both sides sign off a single list of rooms and racks with the owner of each, and everything not yet documented is marked as a gap to close during the walkthroughs.
Define rack and unit conventions
Before any record is created, agree how units are numbered (for example, whether unit 1 sits at the bottom or the top of the rack), how rack-mounted and zero-U items are counted, how half-depth and rear-mounted equipment are recorded, and which naming pattern identifies rooms and racks. GLPI stores a unit count, height, maximum power in watts and maximum weight for each rack, so the team should confirm which values come from manufacturer data and which come from site measurements. The output is a short written convention that the walkthrough team and the GLPI administrators both follow.
Create data center and rack records
The GLPI administrator creates the data center and room structure first, then the racks inside each room, using the agreed names and unit counts. The room grid size setting introduced in GLPI 11.0.0 should be set per room so that rack positions on the layout match the physical floor. Confirm each rack's data center position, location, height, power and weight limits against the convention sheet. The step is done when every room and rack in the agreed list exists in GLPI and a second person has checked the values against the source.
Add PDUs, enclosures and passive devices
Power distribution units, enclosures such as chassis or blade frames, and passive devices like patch panels and cable managers are added as their own asset records and placed in their racks. Cables are recorded where the team needs to trace connections, which usually means power feeds and critical network links. Agree beforehand which of these items need separate records and which can stay as notes, because each record adds upkeep. The output is a rack that shows its power and passive infrastructure, not only its servers.
Position equipment in racks
Each server, network device and storage unit is linked to its rack and assigned its starting unit position, with orientation and depth recorded where the convention requires it. Work rack by rack, starting with the highest-risk racks such as those carrying core network or database systems. Check that no two items claim the same unit and that the total unit count does not exceed the rack height. The step produces a rack view that matches the physical layout the walkthrough team recorded.
Validate against physical walkthroughs
A technician walks each room with the GLPI rack view and compares it with the racks in front of them, checking unit positions, device labels, PDU and cable records, and any items found that are missing from GLPI. Discrepancies are logged with the rack, unit and the source of the correct value, then corrected by the GLPI owner. The walkthrough should be repeated for any room where differences are large. The step is done when the walkthrough log shows no open discrepancies, or each open item has an owner and a date to close it.
Set an ongoing change process
Agree who may change rack records, when a change must be recorded before the equipment moves, and how decommissioned or relocated items are removed from racks. Many teams tie these steps to GLPI change management or to their existing change workflow, so that a hardware move creates a record instead of a memory. Schedule periodic walkthroughs to catch drift. The output is a written process, the named role owners and a first walkthrough date, so that the physical view stays in step with the inventory after the project closes.
How equipment placement stays in step with the inventory
The physical view in GLPI is only as accurate as the process that updates it. Inventory agents and imports are good at bringing in device facts such as hardware, serial numbers, operating system and network details, but they do not know which rack unit a server sits in or which PDU feeds it. Rack position is usually a decision made by a person during installation, move or decommissioning, so it needs a controlled workflow, not an assumption that discovery will fill it in. Decide early who owns placement changes, whether they are raised as tickets, and who must confirm a device has physically moved before the record changes.
Drift is the main risk. A server is racked and powered but its record still shows an old room, an empty unit or no rack at all, and capacity figures such as remaining units, power or weight quietly become wrong. A reconciliation routine should compare what agents report with what the racks show. Check for assets with a known network identity but no rack position, rack positions that overlap or exceed the unit count, devices linked to a PDU or enclosure that no longer matches their rack, and decommissioned items still occupying space. Run it on a fixed schedule and record who resolved each exception.
Confirm before go-live which placement fields your GLPI version exposes on each asset type, whether they are editable through the interface, the API and imports, and how an import treats an empty placement value: whether it clears the existing position or leaves it alone. Test this on a copy of your data with a few racked devices that have been moved. The GLPI racks documentation at GLPI documentation: Racks is the natural starting point for the field list, but verify behavior against the version you run, because a wrong import assumption can silently overwrite correct positions.
What drives the effort of a rack model
This table lists the main drivers of effort when modeling server rooms in GLPI, with how to keep each one down and how one-time setup differs from ongoing upkeep. Read it before scoping, so the quote reflects the state of your source data and the number of people who will edit the model.
| Driver | Why it changes effort | How to keep it down | One-time or recurring |
|---|---|---|---|
| Number of rooms and racks | Each room needs its own data center and grid settings, and each rack needs position, unit count, power and weight limits recorded. | Start with the rooms that hold production equipment, then add secondary rooms in a later phase. | One-time build, then recurring when racks are added or retired |
| Quality of existing spreadsheets or DCIM exports | Inconsistent rack names, unit numbering or missing power figures force manual reconciliation before any import. | Agree naming and unit conventions first, clean one room as a pilot, and map columns to GLPI fields before loading. | One-time cleanup, with a small recurring share for new exports |
| PDUs, enclosures and passive devices | Each power strip, enclosure or patch panel is a separate asset that needs its own rack position and, for PDUs, its link to supplied circuits. | Load PDUs and passive devices from a standard template and record only the placements that matter for capacity or change work. | One-time for existing hardware, recurring for every new installation |
| Cable runs to record | Cable records multiply quickly and each run needs two endpoints kept accurate, which is the most error-prone part of the model. | Decide which cables are recorded (power, network uplinks, fiber trunks) and document the rule before entry begins. | Mostly one-time, with recurring changes after every recabling |
| Equipment already inventoried by GLPI Agent | When devices already report to GLPI through inventory, the model can link existing asset records instead of creating duplicates. | Confirm which hosts report to GLPI, then match rack positions to inventoried items instead of retyping hardware details. | One-time matching, then mostly automatic for hardware data |
| Physical view kept in step with inventory | Rack positions drift when hardware is moved without an update, so the physical view and the inventory disagree. | Make rack position updates part of the change and decommission steps, and review discrepancies on a fixed schedule. | Recurring, usually the largest long-term effort |
| Number of teams with edit rights | More editors mean more naming variants, more conflicting updates and more profile and entity rules to maintain. | Limit edit rights to a few facilities or infrastructure owners and let others read the physical view. | One-time profile design, recurring access reviews |
How the rack model connects to inventory, changes and monitoring
Does GLPI Agent automatically place servers into racks?
No. GLPI Agent collects hardware and software inventory and sends it to GLPI, which creates or updates the computer records. The rack position, unit placement and power draw are not part of what the agent reports on a standard inventory, so the physical layout still needs to be recorded by your team or through an import you design. Confirm with your own agent version and inventory settings which fields reach GLPI in your environment, then decide which rack attributes stay manual. The GLPI Agent documentation describes what the agent collects and sends.
How should inventoried devices be matched to rack items?
Match them by a stable identifier such as serial number or asset tag, then link the matched computer to the rack position. Inventory data can create duplicate records when a machine is reinstalled, renamed or replaced, so define which record is authoritative before you start linking. Decide who resolves conflicts and how often the physical walk-down is repeated. Your team should test the matching rules on a sample of racks before applying them across all data centers.
Which asset records must agree with the rack model?
The rack model is only useful if the asset records around it agree with it. Check that each racked device has a location, an owner, a status and a link to the data center and room it occupies. Review the asset types GLPI documents for physical equipment, including racks, enclosures, PDUs, passive devices and cables, and confirm which of them your team will track. Keep a short list of mandatory fields so that a device cannot be marked as installed without a rack position.
How does a rack change feed into change management?
Moving, adding or removing equipment in a rack should be raised as a change so that the impact is reviewed before work starts. Link the change to the affected racks and devices, record the planned power and weight effect, and close the change only after the rack record has been updated. The change management workstream covers approvals and plans in detail. Confirm with your change board which rack moves count as standard changes and which need approval.
Can impact analysis show which services a rack supports?
Impact analysis depends on the links you record between items, not on the rack view alone. A rack shows where a device sits, but the business service it supports is only visible when the device is linked to a service through dependencies or appliances. Document which relationships your team will model before building them, because a rack with incomplete links can understate the effect of a power or network outage. Check the impact analysis documentation for the asset types it supports in your GLPI version.
How do hardware contracts link to racked equipment?
Contracts for hardware, such as maintenance and support agreements, can be linked to the assets they cover, including racked devices. Link each contract to the specific items it applies to so that renewal and end-of-contract notices reach the right owner. A rack view does not replace contract records, so make sure the rack model identifies the devices that a support contract depends on. Confirm which contract types your organization uses and whether they cover racks, PDUs or cabling.
Which monitoring tools need rack data, and how is it shared?
Monitoring tools need rack data mainly for location context, such as which rack a failed host sits in and which circuit feeds it. Whether a given monitoring tool can read this from GLPI depends on the integration you configure, so confirm the supported integration path and the fields it exposes in your environment before designing the flow. Some teams keep rack and power attributes in the monitoring system instead and reference the GLPI asset identifier. Decide which system is the source of truth for each attribute and write that decision down.
How DeployOpen scopes and delivers GLPI rack modeling
DeployOpen starts with a written scope built from the room inventory, not from the GLPI menu. Before any object is created, we walk through each server room or technical room with your facilities and data center staff and record the rooms, the racks in each one, the unit counts and the rated power and weight limits that the site actually enforces. We then list the data sources that will feed the model, such as existing spreadsheets, a DCIM or floor plan export, the discovery and inventory data from GLPI Agent, and any monitoring system that already knows where a power feed lands. Each source is marked as authoritative for a given field, so the team knows which system wins when two disagree. The scope document also states which integrations are in and which are out, and it names who approves the rack naming and numbering conventions. Because the work is fixed scope, the deliverables and the acceptance checks are agreed in writing before the build starts.
Delivery happens inside your own GLPI instance and your own infrastructure, using your entities, profiles and change process. DeployOpen builds the data center, room and rack records, then the enclosures, PDUs, passive devices and cables, and places equipment in rack positions with the orientation and unit occupancy you have confirmed. The build is verified by comparing a sample of racks against the physical site, checking that power and weight totals do not exceed the recorded limits, and confirming that the access rights let the right teams edit the physical view. Your team receives a short convention guide covering naming, position rules, how to record a move or decommission, and who updates which field. Ongoing support, periodic reconciliation against the inventory and upgrades for future GLPI releases can be covered by a retainer. Ask any provider to confirm in writing how they handle access to your environment, which accounts they use and how changes are logged.
