VMware ESXi and vSphere Cluster Management

vCenter Server Inventory Explained: Hierarchy, Datacenters, Folders, and Managed Objects

Learn how the vCenter Server inventory hierarchy uses root objects, datacenters, folders, hosts, VMs, clusters, networks, and resource pools.

The vCenter Server inventory is the hierarchical collection of objects through which vCenter Server represents, organizes, and manages virtual infrastructure. It gives administrators a consistent way to navigate infrastructure, apply management operations, delegate access, and maintain a clear operational structure.

The inventory contains both organizational container objects and managed infrastructure objects. Containers provide structure. Managed objects represent resources and workloads such as ESXi hosts, virtual machines, templates, clusters, networks, and resource pools.

Why the vCenter Server Inventory Matters

Without an organized inventory, administrators may still have working hosts and virtual machines, but locating objects and understanding their relationships becomes difficult. A planned inventory helps teams:

• Navigate large environments more quickly.
• Group infrastructure according to operational responsibilities.
• Apply permissions and administrative responsibilities consistently.
• Identify which hosts, workloads, networks, and clusters belong together.
• Plan migrations and other operations around meaningful infrastructure boundaries.
• Maintain consistent naming and lifecycle practices as the environment grows.

Folders and datacenters organize objects, but they do not perform the same function as clusters or resource pools. A folder is primarily an organizational container. A cluster groups hosts for shared management and availability-related capabilities. A resource pool provides a logical structure for allocating and controlling compute resources.

Inventory Hierarchy and the Root Object

The root object is the highest-level inventory object. It represents the vCenter Server system itself and is the starting point for the inventory hierarchy.

The root object is permanent and cannot be removed. Beneath it, administrators create one or more datacenter objects. Folders and managed objects are then organized within the applicable datacenter boundaries.

vCenter Server root object
└── Datacenter
    ├── Host folders
    │   ├── ESXi hosts
    │   └── Clusters
    ├── VM and template folders
    │   ├── Virtual machines
    │   └── Templates
    ├── Networks
    └── Resource pools

This diagram is a general model. The exact visible layout depends on the vSphere Client view and on which objects have been created. Host organization and virtual machine organization can use separate folder structures.

Inventory Object Types

Understanding whether an object is a container or a managed object makes the hierarchy easier to design.

Datacenter Objects

A datacenter object is a logical vCenter inventory container. It is not required to represent a physical building. The name may describe a location, business unit, customer environment, or administrative boundary.

At least one datacenter object must exist before an ESXi host can be added to the vCenter Server inventory. A common onboarding sequence is:

1. Create a datacenter beneath the vCenter Server root object.
2. Create useful folders for hosts, virtual machines, and templates.
3. Add ESXi hosts to the appropriate datacenter.
4. Create or place clusters, networks, resource pools, VMs, and templates according to the design.
5. Configure higher-level capabilities when their prerequisites are satisfied.

A datacenter can contain or organize hosts, virtual machines, templates, networks, folders, clusters, resource pools, and related infrastructure. Multiple datacenters can be useful when the environment needs distinct administrative or operational boundaries.

Choosing a Datacenter Design

Choose datacenter boundaries according to management and operational requirements rather than physical geography alone. Possible design bases include:

For example, separate datacenters for New York, London, and Singapore can each contain their own hosts, VMs, networks, customers, and administrator teams. A business-unit design could instead use separate datacenters for Finance, Engineering, and a managed-services customer environment.

Cross-Datacenter Limitations

Interaction between separate vCenter datacenter objects is limited. This matters when designing for workload mobility and shared operations.

The principal example is vMotion. vMotion is a vSphere capability for migrating a running virtual machine between compatible hosts within the applicable inventory boundary. A VM migration from one host to another is supported within the same vCenter datacenter, but a vMotion placement to a host in another vCenter datacenter is not supported.

If workloads must move between two groups of hosts through vMotion, place those hosts in the same datacenter object. Use folders, clusters, resource pools, permissions, and naming conventions to provide additional organization inside that boundary.

Folders and Organization Strategy

A folder is a container used to arrange inventory objects into meaningful groups within a datacenter. Folders improve navigation and administration, but they do not allocate compute resources or provide cluster-level availability functions.

Virtual Machine and Template Folders

Virtual machines can be organized by function, application, workload type, owner, or lifecycle. For example:

VMs and Templates
├── Production
├── Development
├── Infrastructure Services
├── Database Systems
├── Application Servers
└── Templates

Choose categories that match how administrators search for, support, and change workloads. A lifecycle-oriented structure might separate development, test, staging, and production. An application-oriented structure might group database systems, application servers, and infrastructure services.

Host Folders

ESXi hosts can be grouped by CPU family, hardware generation, location, vendor, or another classification that supports operations. For example:

Hosts
├── CPU Family A
├── CPU Family B
└── New Hardware Generation

Grouping hosts by CPU family or hardware generation can make compatibility and lifecycle planning easier to understand. Location and support team can also be useful when those attributes affect administration.

Naming and Consistency

Use naming and folder conventions that administrators can apply consistently. Document what each folder means, how hosts and VMs should be named, and where new objects belong. Avoid creating many one-off folders that have no clear operational purpose.

Folders are not a substitute for resource-management constructs. Put hosts into a cluster when shared cluster management or availability features are required. Use resource pools when compute allocation must be structured or controlled.

Hosts and Advanced vSphere Capabilities

An ESXi host is a physical server running the VMware hypervisor and hosting virtual machines. Managing a host directly through ESXi is different from adding it to the vCenter Server inventory.

Hosts must be added to vCenter Server inventory to use vCenter-managed advanced capabilities as intended. Examples include:

• vSphere High Availability: Supports recovery of virtual machines after host failures.
• Fault Tolerance: Is designed to provide continued VM operation during certain host failures.

The dependency sequence is important: create a datacenter, add hosts, and then organize and configure clusters or other higher-level infrastructure features as appropriate. Additional feature-specific prerequisites still apply.

Inventory Planning Workflow

1. Plan datacenter boundaries. Decide how many datacenter objects are needed and what each represents. Consider location, business ownership, customers, administrator teams, workload mobility, and shared operations.
2. Define object categories. Decide how hosts, VMs, templates, networks, clusters, and resource pools will be named and grouped.
3. Design folders. Create separate, meaningful structures for host objects and VM or template objects. Use classifications that help with daily administration.
4. Create the datacenter. Create the required datacenter object beneath the root object before attempting to onboard an ESXi host.
5. Add ESXi hosts. Add each host to the appropriate datacenter and place it in the intended host folder or cluster.
6. Organize workloads and infrastructure. Place VMs and templates into the planned folders and configure networks, clusters, and resource pools as needed.
7. Validate mobility. Confirm that hosts requiring vMotion-based workload movement belong to the same datacenter object.
8. Review the design. Check whether administrators can find objects easily and whether the boundaries support expected maintenance, availability, and management operations.

Common Troubleshooting Scenarios

Host onboarding cannot proceed as expected

Likely cause: No vCenter datacenter object has been created.

Resolution: Create at least one datacenter beneath the vCenter Server root object, then add the ESXi host beneath that inventory boundary.

vMotion cannot target a host in another datacenter

Likely cause: The source and destination hosts belong to different vCenter datacenter objects.

Resolution: Use a destination host within the same datacenter, or revisit the datacenter design if cross-host mobility is a requirement.

Administrators cannot find hosts or identify compatible hardware groups

Likely cause: The host inventory lacks a meaningful folder structure.

Resolution: Create consistent host folders based on CPU family, hardware generation, location, or another operationally useful classification.

Advanced vSphere features cannot be applied as intended

Likely cause: The ESXi host has not been added to vCenter Server inventory.

Resolution: Add the host to a datacenter in vCenter Server, then configure the applicable cluster or feature prerequisites.

Inventory Design Rules and Consequences

Exam-Relevant Notes

• The root object is the topmost inventory object, represents vCenter Server, and cannot be removed.
• A datacenter object is logical; it does not have to correspond to a physical building.
• At least one datacenter must exist before an ESXi host can be added to vCenter Server inventory.
• Folders organize objects but do not replace clusters or resource pools.
• Host folders and VM folders can use different organizational structures.
• Hosts that need vMotion-based mobility should be placed in the same vCenter datacenter.
• Adding a host to vCenter inventory is a prerequisite for using vCenter-managed advanced capabilities such as vSphere High Availability and Fault Tolerance as intended.

Summary

The vCenter Server inventory provides the hierarchy used to represent and manage virtual infrastructure. The permanent root object contains datacenter objects, which establish logical boundaries for hosts, VMs, templates, networks, and related infrastructure. Folders then provide practical organization within those boundaries.

A good design balances separation with operational flexibility. Datacenters can represent locations, business units, customers, or administrator teams, but separate datacenters limit certain cross-boundary operations. In particular, hosts that need to exchange running workloads through vMotion should remain in the same datacenter. Start with the required datacenter, add hosts, organize objects with consistent folders, and then configure clusters, resource pools, and advanced vSphere capabilities according to the operational design.

Continue with vCenter Server inventory planning and organization as a reference while designing your environment.