VMware ESXi and vSphere Cluster Management

Understanding vCenter Server Inventory Hierarchy

Learn how vCenter Server organizes datacenters, folders, ESXi hosts, clusters, VMs, networks, datastores, and resource pools.

The vCenter Server inventory is the hierarchical organizational model that vCenter Server uses to represent and manage a VMware vSphere environment. It gives administrators a structured view of datacenters, ESXi hosts, clusters, virtual machines, templates, networks, datastores, and resource pools.

A well-designed inventory is more than a convenient list. It improves navigation, supports delegated administration, clarifies ownership, and helps administrators apply resource-management and availability policies to the correct objects.

What the vCenter Server inventory represents

The inventory contains two broad kinds of objects:

• Organizational containers hold or group other objects. Examples include the vCenter Server root, datacenters, and folders.
• Managed infrastructure and workload objects perform or represent actual computing functions. Examples include ESXi hosts, clusters, virtual machines, networks, datastores, templates, and resource pools.

Folders do not turn a virtual machine into a different type of object, and placing a host in a folder does not create a cluster. Containers make objects easier to find and administer; the objects themselves retain their operational roles.

Inventory design can support:

• Administration: Administrators can find related systems and perform tasks against a logical group.
• Delegation: Permissions can be planned around sites, teams, customers, or workloads. See assigning permissions for the security side of this design.
• Visibility: Consistent names and folders make ownership, environment, and lifecycle easier to identify.
• Resource management: Clusters and resource pools provide operational controls that folders alone cannot provide.

Inventory hierarchy and the root object

Every vCenter Server inventory begins with a root object. The root is the highest-level object representing that vCenter Server instance. It is created as part of the vCenter environment and cannot be removed.

Objects are arranged beneath the root through datacenters and object-specific folders. A simplified structure looks like this:

vCenter Server root
├── Datacenter - London
│   ├── VM folders
│   │   ├── Production
│   │   └── Development
│   ├── Host folders
│   │   └── Intel Generation B
│   │       └── Cluster - London Production
│   │           ├── ESXi host 01
│   │           ├── ESXi host 02
│   │           └── Resource pool - Application Team
│   ├── Networks
│   ├── Datastores
│   └── VM templates
└── Datacenter - New York
    ├── VM folders
    ├── Host folders
    ├── Networks
    └── Datastores

The exact display and available folder types depend on the vSphere Client view and version, but the central idea remains the same: the root contains datacenters, and datacenters provide the principal containers for related infrastructure and workloads.

Datacenter objects

A datacenter object is a primary logical container in vCenter Server. An ESXi host must be added beneath a datacenter before it can be managed by vCenter Server. The word “datacenter” can describe a physical location, but it can also represent an administrative or operational boundary.

A datacenter can contain related:

• ESXi hosts and host folders
• Clusters
• Virtual machines and VM folders
• VM templates
• Networks and connectivity objects
• Datastores and storage-related objects
• Resource pools and other resource-management objects

One vCenter Server can contain multiple datacenters. Separate datacenters may be appropriate for:

• Geographic sites such as London, New York, and Singapore
• Business units such as Finance and Engineering
• Separate customers or tenants
• Customer environments with distinct operational ownership
• Infrastructure operated by independent administrator teams
• Environments requiring a clear management or resource boundary

A datacenter should not be created merely because a folder name feels inconvenient. It is a meaningful boundary that can affect resource relationships and migration planning.

vCenter inventory objects and their roles

Clusters and resource pools

Clusters

A cluster groups ESXi hosts so they can be managed as a shared compute domain. Clusters are commonly used with capabilities such as vSphere High Availability (HA), Distributed Resource Scheduler (DRS), and Enhanced vMotion Compatibility when the required configuration and licensing are present.

HA can restart affected virtual machines after a host failure when configured appropriately. Fault Tolerance (FT) provides continued operation for supported workloads through host failure using its own requirements and limitations. Adding a host to inventory does not automatically enable either feature.

Before configuring HA or FT, verify cluster membership, host compatibility, networking, storage, licensing, and feature-specific settings. Relevant procedures include creating clusters, enabling vSphere HA, and enabling vSphere FT.

Resource pools

A resource pool is a logical subdivision of CPU and memory resources from a host or cluster. It can be used to allocate, reserve, limit, or prioritize compute capacity for a group of workloads or a delegated team.

Resource pools affect resource scheduling and allocation. A folder does not. Use a resource pool when the requirement concerns compute capacity; use a folder when the requirement concerns organization or navigation. See how resource pools work and creating a resource pool.

Folders and organizational design

Folders group compatible inventory objects so administrators can navigate and manage them consistently. vSphere uses separate organizational contexts for different object categories, so a VM folder and a host folder should be designed independently even when they use similar naming ideas.

Example VM folder structure

Virtual Machines
├── Production
│   ├── Web
│   └── Databases
├── Development
├── Testing
├── Infrastructure
└── Archived Workloads

VM folders can be organized by application, business function, environment, customer, site, or lifecycle stage. For example, an organization might place production workloads in Production, non-production workloads in Development and Testing, and management appliances in Infrastructure.

Example host folder structure

Hosts and Clusters
├── Intel Generation A
│   └── Legacy Cluster
├── Intel Generation B
│   └── Production Cluster
└── AMD Hosts
    └── General Purpose Cluster

Host folders may be organized by CPU generation, platform family, lifecycle group, site, or administrator ownership. Hardware-based folders can help administrators identify compatibility and replacement groups quickly, but they do not replace cluster compatibility checks or CPU compatibility configuration.

Folder design rules

• Choose a naming standard that identifies purpose, site, environment, or ownership consistently.
• Keep folder trees shallow enough that administrators can reach common objects quickly.
• Use the same vocabulary across VM, host, and network naming where that improves recognition.
• Do not use folders as a substitute for clusters, resource pools, permissions, network segmentation, or storage design.
• Design around operational workflows rather than attempting to model every detail of the physical organization.

Datacenter versus folder

Inventory placement and vSphere features

An ESXi host must be added to vCenter Server inventory before vCenter-managed capabilities can be used for that host. A typical preparation sequence is:

1. Create or select the appropriate datacenter.
2. Add the ESXi host to vCenter Server inventory.
3. Place compatible hosts in a cluster when shared cluster services are required.
4. Configure networking, storage, licensing, and feature-specific settings.
5. Enable and validate capabilities such as HA, FT, DRS, or vMotion as appropriate.

Inventory placement supports management, but placement alone does not enable every feature. For example, HA requires an appropriate cluster configuration, and FT has workload, host, network, storage, and licensing requirements. Similarly, vMotion depends on host compatibility, networking, storage access or migration design, and other configuration details. Review CPU compatibility for vMotion and Enhanced vMotion when planning migrations.

Datacenter boundaries and migration limitations

A datacenter is an important management and resource boundary. Objects in separate datacenters do not behave as though they belong to one large shared migration domain. Their interaction is limited compared with objects that share the same datacenter.

For ordinary vMotion planning, assume that a running virtual machine moves between compatible hosts within the same vCenter datacenter. A VM on a host in the London datacenter should not be assumed to move directly by standard vMotion to a host placed in the New York datacenter. Migration features and supported cross-boundary workflows can vary by vSphere version and configuration, so any exception requires explicit validation rather than relying on inventory placement alone.

Sample inventory design by geographic site

This design is appropriate when each site has its own infrastructure, support team, workloads, and operating boundaries. If the sites need frequent workload mobility and shared administration, assess the consequences of separate datacenters before implementing the design.

Planning an inventory structure

Plan the inventory before onboarding a large number of hosts and VMs. Consider the following boundaries:

• Geographic: Are sites physically or operationally independent?
• Administrative: Which teams own and support the infrastructure?
• Customer or tenant: Must customers or environments be clearly separated?
• Organizational: Do business units require distinct ownership or reporting?
• Hardware: Do CPU families, host generations, or platform types affect compatibility and lifecycle management?
• Workload: Should production, development, testing, infrastructure, and archived workloads be easy to distinguish?
• Growth: Will the structure remain understandable as hosts, clusters, VMs, networks, and datastores increase?

Use a separate datacenter when the site or group needs a durable management and resource boundary. Use folders within an existing datacenter when the difference is primarily classification, navigation, or workflow. For example, London, New York, and Singapore may justify separate datacenters when they operate independently. Production, Development, and Testing commonly work better as VM folders within the appropriate datacenter.

Inventory planning decisions

Creating inventory objects in the vSphere Client

Create an inventory datacenter

1. In the vSphere Client, select the vCenter Server inventory root.
2. Start the command to create a datacenter object.
3. Assign a meaningful name based on the approved design.
4. Use the datacenter as the parent container for hosts, clusters, virtual machines, networks, and related resources.

Add an ESXi host to inventory

1. Select the intended datacenter or an appropriate host folder.
2. Start the Add Host workflow.
3. Provide the ESXi host management address and administrator credentials.
4. Review the host security information and complete the workflow.
5. Place the host into a cluster if it will participate in cluster-based services.

For connection and onboarding considerations, see communication between vCenter Server and ESXi.

Create organizational folders

1. Select the relevant inventory view and object category.
2. Create folders based on the agreed taxonomy.
3. Move compatible inventory objects into the appropriate folder.
4. Apply consistent names and verify that permissions and operational procedures still match the new placement.

Recommended sequence:
1. Define datacenter boundaries.
2. Define folder categories and naming rules.
3. Create datacenters and folders.
4. Add hosts and create clusters.
5. Add networks, datastores, templates, and VMs.
6. Apply permissions and validate administrator workflows.

Troubleshooting inventory design problems

The Add Host option is unavailable

Likely cause: No suitable datacenter has been created or selected.

Resolution: Create or select the correct datacenter before beginning host onboarding. Confirm that you are working in the host-and-clusters inventory view and have the required permissions.

A VM cannot be live-migrated as expected

Likely cause: The source and destination hosts are separated by different vCenter datacenter objects, or another vMotion prerequisite is missing.

Resolution: Review the inventory boundary and plan ordinary vMotion between eligible hosts in the same datacenter. Then validate CPU compatibility, networking, storage access, licensing, permissions, and other migration requirements.

The inventory is difficult to navigate

Likely cause: Folder names and object names do not follow a consistent model, or the folder tree is too deep.

Resolution: Define a taxonomy based on workload function, environment, customer, site, hardware, or lifecycle. Consolidate unnecessary levels and apply the standard consistently.

HA or FT is unavailable after adding a host

Likely cause: Adding a host to inventory does not satisfy all feature prerequisites.

Resolution: Verify cluster membership, host compatibility, networking, storage, licensing, and feature-specific configuration. Review HA admission control and the relevant HA or FT configuration procedures.

Exam-relevant notes

• The root object is the highest-level inventory object representing the vCenter Server system and is not removable.
• An ESXi host must be placed in a datacenter before it can be added to vCenter Server inventory.
• A datacenter is a primary logical container and an important management and resource boundary.
• Folders organize objects; they do not change object type or provide the resource controls of clusters and resource pools.
• Clusters group hosts for shared compute management and can support features such as HA, DRS, and FT when prerequisites are met.
• Resource pools allocate and prioritize compute capacity; folders do not.
• Standard vMotion planning should treat separate inventory datacenters as separate migration boundaries.
• Inventory placement alone does not enable HA, FT, vMotion, or other advanced capabilities.

Summary

The vCenter Server inventory is a hierarchy that starts at the non-removable vCenter Server root and extends through datacenters, folders, and managed infrastructure objects. Datacenters provide major logical and operational boundaries, while folders provide flexible organization within those boundaries.

Use clusters for shared host management and availability features, resource pools for compute allocation and prioritization, and folders for navigation and classification. Before creating datacenters, evaluate geographic location, administration, customers, hardware, workloads, migration needs, and future growth. A structure that reflects real operational boundaries will remain easier to manage than one based only on physical labels or arbitrary categories.