Unit

VMware vSphere Components: Architecture, Services, and Infrastructure Roles

Learn how vSphere, ESXi, vCenter Server, clusters, storage, networking, vMotion, HA, and DRS work together.

VMware vSphere is a virtualization platform for turning physical server infrastructure into a managed pool of virtual compute, storage, and networking resources. It is not a single program. It is an ecosystem that includes the ESXi hypervisor, vCenter Server, administrative interfaces, virtual machines, datastores, virtual switches, clusters, security controls, and availability features.

This lesson explains what each major component does and how the components cooperate in a small lab or a multi-host business environment.

What Is VMware vSphere?

A hypervisor is software that creates and runs virtual machines while allocating physical hardware resources to them. VMware vSphere is VMware's virtualization platform and management ecosystem. It combines:

  • Compute: physical CPU and memory are abstracted into virtual CPUs and virtual memory.
  • Storage: physical disks and storage systems are presented through datastores and virtual disks.
  • Networking: virtual switches, port groups, VLANs, and VMkernel adapters connect workloads and host services.
  • Management: administrators configure hosts, clusters, virtual machines, permissions, templates, alarms, and policies.
  • Availability: cluster features can restart or protect workloads when infrastructure problems occur.
  • Security: authentication, roles, privileges, certificates, secure connections, and traffic separation protect the environment.

An ESXi host is one physical server running the ESXi hypervisor. vSphere is the larger platform that can manage one host or many hosts and provide services across them.

Core vSphere components

Component — Primary function — Where it runs — Provides or manages — Dependencies

ESXi — Bare-metal hypervisor — Physical server — Virtual machines and host resources — Compatible server hardware

vCenter Server — Centralized management — Appliance or supported deployment — Inventory, clusters, permissions, alarms, and policies — Network access to ESXi hosts

vSphere Client — Browser-based administration — Administrator workstation or browser — Configuration and monitoring interface — ESXi or vCenter access

Datastore — Storage container for VM files — Storage visible to ESXi — Virtual disks, configuration files, and snapshots — Storage presentation and paths

Virtual switch — Software-based network switching — ESXi host or distributed-switch control plane — VM and VMkernel connectivity — Physical uplinks and upstream network

Cluster — Group of compatible hosts — vCenter inventory — Shared capacity, HA, and DRS — Compatible networking, storage, and host hardware

ESXi: The Bare-Metal Hypervisor

ESXi is installed directly on physical server hardware, so it is called a bare-metal hypervisor. It controls access to processors, memory, storage, and network adapters and presents virtual hardware to virtual machines.

For example, a physical server may have 32 CPU cores, 256 GB of RAM, several network adapters, and storage connections. ESXi divides and schedules those resources so that multiple virtual machines can run on the same server.

Resources managed by an ESXi host

  • Physical CPU cores and processor scheduling.
  • Physical memory and memory allocation.
  • Storage adapters, storage paths, and discovered storage devices.
  • Datastores containing virtual machine files.
  • Physical network adapters, also called uplinks.
  • Standard virtual switches or connections to distributed switches.
  • VMkernel adapters for host management and specialized services.
  • Virtual machines and their virtual hardware.

A host is the physical server running ESXi. A virtual machine is a software-defined computer running on that host. The VM has a guest operating system and virtual hardware; it does not directly own the physical server's CPU, memory, disks, or NICs.

vCenter Server and Centralized Management

vCenter Server is the centralized management component for ESXi hosts, clusters, datastores, networks, and virtual machines. Instead of configuring every host separately, an administrator can manage the environment through a shared inventory.

Common vCenter Server functions include:

  • Adding and organizing ESXi hosts.
  • Creating data centers, folders, clusters, and resource pools.
  • Managing permissions, roles, and authentication.
  • Monitoring performance, events, tasks, and alarms.
  • Creating templates and deploying clones.
  • Applying policies and coordinating host configuration.
  • Enabling and coordinating vMotion, High Availability, DRS, and distributed switching.

Advanced capabilities such as vMotion, High Availability (HA), Distributed Resource Scheduler (DRS), and a vSphere Distributed Switch generally require vCenter Server. Exact feature availability also depends on product version, licensing, and configuration.

Direct ESXi management versus vCenter management

Administrative capability — Direct ESXi management — vCenter Server management — Operational impact

Host configuration — Configure one host — Configure and monitor many hosts — Centralized consistency

Virtual machine operations — Create and operate VMs on one host — Manage VMs across inventory — Easier placement and administration

Inventory — Limited to the host — Data centers, folders, clusters, and pools — Logical organization

Permissions and alarms — Host-specific controls — Centralized roles, privileges, and alarms — More scalable administration

vMotion, HA, and DRS — Not generally available as host-only operations — Coordinated across hosts — Mobility and workload resilience

Direct host management is useful in a single-host lab or during an emergency. It does not provide the same cross-host coordination as vCenter Server.

vSphere Client and Administrative Access

The vSphere Client is the browser-based interface used to administer vCenter Server and ESXi hosts. An administrator can use it to create virtual machines, inspect host health, configure networks and datastores, review performance charts, respond to alarms, and manage clusters.

Access should follow least privilege: give each user or service only the permissions required for its responsibilities. vSphere uses authentication, roles, and privileges. A role is a named collection of privileges, while an assignment connects a user or group to a role on an inventory object.

For directory-based identity integration, see vCenter Server and Active Directory. The related lesson on the vSphere graphical interface provides additional interface practice.

vCenter Server Appliance

The vCenter Server Appliance (VCSA) is the appliance-based deployment model for vCenter Server. It is delivered as a virtual appliance rather than as a service that an administrator separately installs on a general-purpose operating system.

During normal operation, the appliance runs as a virtual machine on an ESXi host. Because vCenter Server manages the environment but depends on an ESXi host for its own compute and storage, administrators should plan its placement, backup, monitoring, and recovery carefully.

Core embedded services include authentication and identity management, inventory services, certificate services, and lifecycle-related services. The appliance does not replace ESXi: vCenter Server coordinates management, while ESXi runs the virtual machines.

vSphere Inventory Hierarchy

The inventory hierarchy is a logical structure that helps administrators organize and apply permissions to objects.

Inventory object — Purpose — Contains or connects to — Example use

vCenter Server — Top-level management service — Data centers and inventory objects — Manage an entire environment

Data center — Logical container — Clusters, standalone hosts, networks, and datastores — Represent a site or administrative boundary

Folder — Organizational container — Hosts, VMs, networks, or datastores depending on folder type — Group production workloads

Cluster — Group of compatible hosts — Hosts, resource pools, and VMs — Enable HA and DRS

Host — Physical ESXi server — VMs, local resources, and connections — Supply compute resources

Resource pool — Logical CPU and memory allocation — Child pools or VMs — Prioritize or reserve capacity

Datastore — Storage container — VM configuration and disk files — Store virtual machine data

Network — Logical connectivity object — Port groups and adapters — Connect VMs or host services

Virtual machine — Software-defined computer — Virtual hardware and guest OS — Run an application workload

A data center object is logical; it does not necessarily mean one physical building. It provides a container for related inventory. Folders further organize objects, but a folder does not supply compute or storage.

A cluster groups compatible ESXi hosts so that capacity and cluster features can be managed together. Hosts should have compatible CPU capabilities, consistent network connectivity, and access to the storage required by their workloads.

For hands-on inventory creation, the basic sequence is:

  1. Connect to vCenter Server with the vSphere Client.
  2. Create a logical data center.
  3. Add ESXi hosts to vCenter Server.
  4. Create a cluster when multiple compatible hosts are available.
  5. Create folders to organize hosts, virtual machines, networks, or datastores according to administrative needs.

Clusters and Resource Management

A cluster is a managed group of ESXi hosts that contributes pooled CPU and memory capacity. If one host has unused capacity while another is busy, cluster features can help place or move workloads more effectively.

A resource pool is a logical partition of CPU and memory resources. Resource pools can contain virtual machines or child pools. Three common controls are:

  • Reservation: the guaranteed minimum CPU or memory allocation.
  • Limit: the maximum amount of CPU or memory that can be consumed.
  • Shares: a relative priority used when resources are contested.

Reservations can protect important workloads, limits can prevent a workload from consuming more than intended, and shares determine relative preference during contention. Poorly chosen limits or reservations can reduce effective cluster capacity.

Cluster design depends on more than processor compatibility. Hosts should have consistent port groups, VLAN reachability, uplinks, storage visibility, time synchronization, and management connectivity. Inconsistent design commonly prevents migration or weakens availability.

Virtual Machines and Virtual Hardware

A virtual machine (VM) is a software-defined computer with a guest operating system, applications, and virtual hardware. ESXi schedules the VM's virtual CPUs onto physical processors and maps its virtual memory, disks, and network adapters to host resources.

Common virtual hardware includes:

  • Virtual CPUs.
  • Virtual memory.
  • Virtual disks.
  • Virtual network adapters.
  • Firmware settings such as BIOS or UEFI.
  • Virtual storage and network controllers.

A VM is represented by configuration files and virtual disk files in a datastore. A snapshot records a point-in-time state for short-term rollback or testing. A snapshot is not a backup and should not be retained indefinitely.

A template is a reusable master image used to deploy consistent VMs. A clone is a copy of an existing VM. For example, an administrator can harden and configure a base operating system, convert it to a template, and deploy multiple application servers from it. Templates improve consistency; clones are copies and may be created for testing or other purposes.

For the files involved, see virtual machine files in ESXi. For snapshot operations, see reverting a snapshot.

vSphere Storage Components

A datastore is a storage container visible to ESXi hosts. It holds VM configuration files, virtual disks, snapshot data, and other VM-related files.

The storage relationship can be viewed as a chain:

Physical disks or storage system → storage adapters → storage paths → logical units or file shares → datastore → virtual disk → virtual machine.

Local storage is directly attached to one host and is usually simple to deploy, but it is not automatically available to other hosts. Shared storage is accessible by multiple hosts and is important for workload mobility and many availability workflows.

Storage type — Access method — Typical use — Mobility and availability considerations

VMFS — Block storage presented through storage adapters and logical units — Datastores on SAN or directly attached block storage — Multiple hosts can access the same datastore when storage presentation is consistent

NFS datastore — Network file share — NAS-based virtual machine storage — Requires reliable IP connectivity and correct export permissions

vSAN — Software-defined storage using local disks from participating hosts — Cluster-integrated storage — Requires appropriate cluster design, disks, networking, and host participation

Local datastore — Storage attached to one host — Labs or workloads that do not require shared access — Restricts cross-host mobility unless storage is also available elsewhere

Before relying on shared-storage workflows, verify that every participating host can see the required datastore and has healthy paths. The lessons on browsing VMFS datastores and iSCSI target discovery provide related storage practice.

vSphere Networking Components

ESXi networking has two broad purposes: connecting virtual machines to production networks and connecting the host to infrastructure services.

A VMkernel adapter is an ESXi host network interface used for management and specialized services such as vMotion, storage traffic, or Fault Tolerance. A virtual machine normally uses a virtual network adapter connected to a port group.

A standard virtual switch (vSwitch) is configured separately on each ESXi host. It connects virtual adapters to physical network adapters through uplinks. A vSphere Distributed Switch (VDS) is centrally configured through vCenter Server and can span multiple hosts, which helps maintain consistent port groups and policies.

A port group is a logical set of network settings and policies. It can be assigned to virtual machines or VMkernel adapters. A VLAN is a logical network segmentation identifier. A VLAN configured in vSphere must also be supported correctly by the physical switch path, including access or trunk behavior as appropriate.

Component — Function — Typical traffic — Relationship to physical network

Physical NIC or uplink — Carries traffic between ESXi and the physical network — All externally connected traffic — Connects to a physical switch

Standard vSwitch — Host-local software switching — VM and VMkernel traffic — Uses host uplinks

Distributed Switch — Centrally managed switching across hosts — VM and VMkernel traffic — Uses consistent host uplinks and upstream configuration

Port group — Applies network policy and VLAN settings — Management, VM, migration, or storage traffic — Maps logical traffic to switch behavior

VMkernel adapter — Provides host service connectivity — Management, vMotion, storage, or Fault Tolerance — Uses a port group and uplink path

Virtual NIC — Connects a VM to a port group — Guest application traffic — Reaches the physical network through the virtual switch

Common traffic categories should be planned separately where appropriate:

  • Management: vCenter-to-host communication and host administration.
  • Virtual machine: guest operating system and application traffic.
  • vMotion: VM memory and state transferred during live migration.
  • Storage: traffic to NFS, iSCSI, or other network storage.
  • Fault Tolerance: synchronization traffic for protected workloads.

Separating these categories with port groups, VLANs, uplinks, or physical networks can improve security, performance planning, and troubleshooting. See creating standard switches and access and trunk ports for related networking concepts.

Basic host networking walkthrough

  1. Create or identify a standard switch or distributed switch.
  2. Attach the required physical uplinks.
  3. Create port groups for management and virtual machine traffic.
  4. Create VMkernel adapters for management and vMotion or other required services.
  5. Assign VLAN identifiers only when the physical network is configured to carry those VLANs.
  6. Test reachability and confirm that each host has a consistent configuration.

vMotion and Storage vMotion

vMotion is the live migration of a running VM from one compatible ESXi host to another. It is an operational capability, not a separate physical component. The VM's execution state is transferred over a configured vMotion network while its storage remains accessible as required.

Storage vMotion relocates a VM's files between datastores. It can move storage without necessarily changing the compute host.

Typical dependencies include:

  • vCenter Server coordination.
  • Compatible source and destination hosts.
  • Functional VMkernel adapters and network reachability.
  • Suitable CPU compatibility and sufficient destination capacity.
  • Access to required datastores or a valid destination datastore.
  • Correct VLAN, MTU, uplink, and physical switch configuration.

A migration that fails should be investigated through recent tasks, events, and the exact error message rather than by assuming that the VM or datastore is defective.

Availability Features

vSphere High Availability

vSphere High Availability (HA) is a cluster feature that automatically restarts affected VMs on surviving hosts after an ESXi host failure. HA is recovery through restart; it does not keep the VM continuously running during the host failure.

HA depends conceptually on:

  • A properly configured cluster.
  • Host monitoring and healthy management connectivity.
  • Storage accessible to the destination host, unless the workload design uses another supported arrangement.
  • Enough remaining CPU and memory capacity.
  • Admission control to reserve capacity for expected host failures.

HA primarily addresses host failure. It does not guarantee protection from an application crash, a guest operating system failure, data corruption, or an application-level outage.

Fault Tolerance

Fault Tolerance (FT) is a higher-availability option for selected workloads. It maintains a synchronized secondary execution instance so that interruption can be reduced if a host fails. FT has stricter resource, compatibility, networking, and workload limitations than ordinary HA.

Availability and mobility comparison

Feature — Primary goal — Typical prerequisites — Result during failure or maintenance

vMotion — Planned live workload movement — vCenter, compatible hosts, vMotion networking, capacity — Moves a running VM before maintenance

Storage vMotion — Planned storage movement — vCenter, source and destination datastore access — Relocates VM files

HA — Recovery after host failure — Cluster, monitoring, accessible storage, admission capacity — Restarts VMs on surviving hosts

FT — Reduce interruption for selected workloads — Supported VM, hosts, storage, and dedicated synchronization design — Uses a synchronized secondary instance

DRS — Balance resource demand — Cluster capacity, vCenter, and usually vMotion — Recommends or performs placement and migration

Distributed Resource Scheduler

Distributed Resource Scheduler (DRS) monitors resource demand across a cluster. It can recommend better VM placement or automate placement and migration according to the selected automation level.

DRS uses cluster capacity, host utilization, VM demand, resource pools, reservations, limits, shares, rules, and migration capabilities. DRS does not create additional physical capacity. It makes better use of available capacity and commonly relies on vMotion to move running VMs.

Automation should match operational risk. Recommendation mode gives an administrator control over changes; more automated modes allow the platform to apply eligible placement decisions.

Host Lifecycle and Patch Management

ESXi hosts, firmware, drivers, and vCenter components require controlled updates. Lifecycle management is the planned process of maintaining versions, configuration consistency, compatibility, and compliance across the environment.

Maintenance mode is a host state used before servicing, patching, or removing a host from workload operation. Running VMs may need to be migrated with vMotion, powered off, or handled according to workload policy. A host may fail to enter maintenance mode when powered-on VMs, pinned workloads, passthrough devices, or storage dependencies prevent evacuation.

  1. Review the planned update and compatibility requirements.
  2. Verify backups, capacity, and health of the cluster.
  3. Place the host into maintenance mode.
  4. Migrate or shut down workloads as required.
  5. Apply the approved host, firmware, or vCenter update.
  6. Validate networking, storage paths, management connectivity, and alarms.
  7. Return the host to service and document the change.

Security and Operational Boundaries

Security begins with identity and access. Authentication verifies who is connecting; authorization determines what that identity may do. Roles and privileges should be assigned at the smallest practical inventory scope, following least privilege.

Certificates support trusted identities and secure management connections. Time synchronization and DNS are important because certificate validation and management services depend on consistent names and time.

Management traffic should be separated from workload traffic wherever the design and risk model require it. Storage, vMotion, and FT traffic may also need separate VLANs, uplinks, or physical networks. Network separation is not a substitute for firewalls and correct access controls, but it reduces unintended exposure and simplifies troubleshooting.

Operational protection also requires reliable backups, monitoring, alarms, log review, documentation, and change control. A healthy dashboard is not proof that guest applications are healthy, so application-level monitoring remains necessary.

End-to-End vSphere Architecture

The major relationships can be summarized as follows:

  1. An administrator uses the vSphere Client to connect to vCenter Server.
  2. vCenter Server manages data centers, folders, clusters, hosts, networks, datastores, permissions, and policies.
  3. ESXi hosts provide CPU and memory and connect to physical networks and storage systems.
  4. Virtual switches and port groups connect virtual machine adapters and VMkernel adapters to logical networks.
  5. Datastores provide locations for VM configuration files and virtual disks.
  6. Virtual machines consume compute from hosts, storage from datastores, and network connectivity from port groups.
  7. Clusters combine compatible hosts so that vMotion, HA, DRS, and related policies can operate across them.

In a two- or three-host business cluster, one vCenter Server manages multiple ESXi hosts connected to shared storage. Each host has management, vMotion, and VM networking. HA can restart VMs on surviving hosts after a host failure, while DRS can help balance workloads when demand becomes uneven.

Practical Configuration Walkthroughs

Small single-host lab

One physical server runs ESXi. Several VMs use local datastore storage and standard virtual switches. The host can be managed directly through the vSphere Client. This design is useful for learning, but it does not provide cluster-level HA, DRS, or live migration between hosts.

Prepare storage visibility

  1. Present block storage or connect to the NFS export according to the storage design.
  2. Rescan the ESXi storage adapters.
  3. Create or mount the datastore.
  4. Verify datastore visibility and healthy paths.
  5. For a cluster, confirm that every intended host can access the datastore required by the VMs.

If a datastore appears on one host but not another, check storage presentation, zoning, LUN masking, NFS permissions, network reachability, rescans, multipathing, and path status.

Prepare a cluster for mobility and availability

  1. Verify compatible host hardware and consistent network and storage design.
  2. Configure VMkernel networking for vMotion.
  3. Confirm storage access and sufficient destination capacity.
  4. Enable HA and review admission-control capacity.
  5. Optionally enable DRS and select an automation level appropriate for the environment.

Live maintenance workflow

  1. Confirm that the destination hosts are compatible, connected, and have capacity.
  2. Use vMotion to move running VMs away from the target host.
  3. Place the evacuated host into maintenance mode.
  4. Patch or service the host.
  5. Validate the host and return it to the cluster.
  6. Move workloads back only when capacity and policy require it.

PowerCLI examples

PowerCLI provides command-line access to vSphere. These examples use placeholders and require suitable permissions and feature prerequisites.

Connect-VIServer -Server <vcenter-fqdn>
Get-VMHost
Get-VM
Get-Datastore
Get-Cluster
Move-VM -VM <vm-name> -Destination <target-host>
Disconnect-VIServer -Server <vcenter-fqdn> -Confirm:$false

The migration command will not succeed merely because the syntax is correct. The hosts must be compatible, connected to the required networks, able to access required storage, and able to provide sufficient capacity.

Troubleshooting Checklist

A VM cannot be migrated with vMotion

  • Confirm both hosts are managed by the same vCenter Server and have the required licensing and configuration.
  • Verify functional vMotion VMkernel adapters.
  • Check reachability, VLAN consistency, MTU settings, and physical uplinks.
  • Confirm CPU compatibility, destination capacity, and storage access.
  • Review recent tasks, events, and the migration error message.

HA does not protect workloads as expected

  • Confirm HA is enabled on the correct cluster.
  • Check host connectivity and management network health.
  • Review admission-control settings and remaining failover capacity.
  • Confirm surviving hosts have enough resources to restart protected VMs.
  • Distinguish a host failure from a guest OS or application failure.

A host cannot enter maintenance mode

  • Identify powered-on VMs and host services preventing entry.
  • Determine whether workloads can be migrated, powered off, or temporarily exempted.
  • Check destination capacity and migration prerequisites.
  • Review dependencies such as vSAN, hardware passthrough, or pinned workloads.

VMs have no network connectivity

  • Confirm the virtual NIC is connected and assigned to the intended port group.
  • Check VLAN settings and upstream switch trunking.
  • Verify physical uplink status and virtual switch configuration.
  • Check guest IP addressing, gateway, DNS, and firewall settings.

vCenter Server cannot communicate with an ESXi host

  • Verify management reachability and DNS resolution.
  • Check host connection state, credentials, certificates, and time synchronization.
  • Review firewall rules and management service status.
  • Use events and logs to classify the issue as network-, credential-, certificate-, or service-related.

Exam-Relevant Summary

  • ESXi is the bare-metal hypervisor; a host is a physical server running ESXi.
  • vCenter Server centrally manages hosts and inventory and coordinates many cross-host features.
  • The vSphere Client is the browser-based administrative interface.
  • A cluster groups compatible hosts for pooled resources, HA, and DRS.
  • A resource pool controls CPU and memory allocation using reservations, limits, and shares.
  • A datastore stores VM files; VMFS, NFS, and vSAN are common datastore types.
  • A standard vSwitch is configured per host; a distributed switch is centrally managed across hosts.
  • VMkernel adapters carry host management and specialized service traffic.
  • vMotion moves a running VM between hosts; Storage vMotion moves VM files between datastores.
  • HA restarts VMs after host failure; FT is a distinct higher-availability option for selected workloads.
  • DRS balances resource demand and commonly uses vMotion for automated movement.
  • Shared storage and consistent networking are central dependencies for mobility and availability.