VMware ESXi and vSphere Cluster Management

Virtual Machine Definition and Virtual Hardware in VMware ESXi

Learn how VMware ESXi virtualizes CPU, memory, storage, networking, and firmware, plus the virtual hardware models and files that define a VM.

A virtual machine (VM) is a software-defined computer. It provides virtual processors, memory, storage, networking, firmware, and other devices so that it can run a guest operating system and applications.

Unlike a physical computer, a VM does not directly own the underlying server hardware. The guest operating system interacts with virtual or emulated devices, while VMware ESXi translates and schedules those requests against the physical host resources.

VMware ESXi virtualization architecture

VMware ESXi is a bare-metal hypervisor. It is installed directly on a physical server rather than running as an application inside another operating system.

The hypervisor is the software layer between virtual machines and the physical server. ESXi creates and isolates VMs, presents virtual hardware to each guest, and allocates physical resources as workloads require them.

A typical architecture has three layers:

  1. Guest layer: Each VM contains a guest operating system and its applications.
  2. ESXi layer: The hypervisor provides virtual devices, enforces isolation, and schedules resource use.
  3. Physical layer: The host supplies processor cores, RAM, storage adapters, disks, and physical network interfaces.

ESXi schedules vCPU work onto available physical CPU resources, maps virtual memory to host memory, sends virtual disk operations through storage controllers and datastores, and connects virtual network adapters to virtual switches and physical uplinks.

VMs on the same host share hardware, but they are logically independent. A process in one VM normally cannot read the memory of another VM, and a guest operating system does not need to know which physical disk or network adapter is serving its virtual device.

For background, see ESXi installation and the VMware ESXi online course.

Core virtual hardware assigned to a VM

Virtual CPU

A vCPU is a virtual processor assigned to a VM. ESXi schedules the vCPU on physical processor resources. A VM configured with two vCPUs can present two logical processors to its guest operating system.

Adding vCPUs does not automatically make an application faster. Excessive vCPU allocation can increase scheduling overhead and make it harder for ESXi to provide timely CPU access. Assign only the number of vCPUs the workload and guest operating system need.

Virtual memory

Virtual memory is host RAM allocated to a VM and presented to the guest as physical RAM. For example, a VM configured with 8 GB of memory sees approximately 8 GB of guest-visible RAM, subject to the guest and platform configuration.

The configured amount is not the same as continuously consumed physical RAM. ESXi manages the relationship between guest memory and host memory, and actual use depends on workload activity, reservations, sharing, compression, swapping, and available capacity.

Virtual disks

A virtual disk is a datastore-backed disk device presented to the guest operating system. It normally contains the guest OS, applications, and data. The guest sees a disk and partitions it using its normal disk-management tools, while ESXi stores the disk content in virtual disk files.

Virtual disks connect through a virtual storage controller, such as a supported SCSI controller. Controller choice can affect performance, features, and whether the guest has a suitable driver.

Virtual network adapters

A vNIC is a virtual network interface card. ESXi connects it to a virtual switch or distributed switch through a port group. Physical NICs, called uplinks, then provide connectivity to the physical network when required.

Common choices include emulated adapters such as E1000 and E1000e and VMware-optimized adapters such as VMXNET3 when the guest operating system supports the required driver. See standard virtual switches and distributed switches for the networking layer.

Firmware and motherboard representation

Virtual firmware is the BIOS or UEFI firmware presented to the VM before the guest OS starts. The VM also receives a virtual motherboard and chipset representation. Firmware mode, boot order, chipset behavior, and virtual hardware compatibility can affect operating system installation and booting.

Other virtual devices

  • Virtual storage controllers: Connect virtual disks to the guest, commonly through SCSI or other supported controller models.
  • Optical drives: Present a virtual CD or DVD device that can use an ISO image or another configured source.
  • Video adapters: Provide display output through a virtual graphics device, commonly represented as standard VGA or a newer supported virtual display device.
  • Virtual motherboard devices: Supply buses, PCI devices, timers, and other platform components expected by the guest OS.

To configure these devices, use the VM settings interface or follow the procedure for adding virtual hardware to a VM.

Virtual hardware presentation and compatibility

The virtual hardware model determines which devices and capabilities a guest can use. The guest OS communicates with those devices through drivers. A device can be present in the VM configuration but still be unusable if the guest lacks a compatible driver.

A VM's virtual hardware version is a compatibility level that defines supported virtual devices and capabilities. Available device choices can vary according to the ESXi release, virtual hardware version, guest OS, and management platform. Check guest support before upgrading compatibility or changing a controller or adapter.

Historically common devices were often emulated to maximize compatibility. Current deployments frequently use newer firmware, storage-controller, and network-adapter selections where supported because optimized devices can provide better performance or capabilities.

CPU vendor presentation may show AMD or Intel characteristics that reflect the underlying host CPU family. CPU compatibility features can mask or standardize some processor features for migration, but they do not make every host CPU identical.

Physical resources and virtual resources

The following mapping helps connect the physical server view with the VM view.

Physical host resource | VM-presented resource | Purpose | Key consideration

Physical CPUs and cores | vCPUs | Execute guest instructions | More vCPUs are not always better; avoid unnecessary allocation.

Host RAM | Virtual memory | Provides guest-visible system memory | Configured memory and actual physical consumption can differ.

Datastore storage | Virtual disks | Stores guest OS and application data | Capacity, latency, provisioning, snapshots, and datastore access matter.

Physical NICs and uplinks | vNIC connectivity | Connects the guest to virtual and physical networks | Port group, VLAN, uplink, and adapter-driver settings must agree.

Physical storage adapters | Virtual storage controllers | Carry virtual disk I/O | Controller and guest-driver compatibility are important.

Host graphics hardware | Virtual video adapter | Provides guest display output | Virtual display capability is not equivalent to direct physical GPU access.

Resource sharing is central to virtualization. Several VMs can use the same physical CPU cores, memory pool, storage system, and network uplinks. Administrators should avoid excessive allocation, especially high vCPU counts and unnecessarily large memory assignments. Review reservations, limits, shares, workload demand, and contention rather than treating configured values as guaranteed dedicated hardware.

For deeper resource concepts, see memory virtualization and memory overcommitment.

Legacy default virtual hardware examples

Older ESXi environments may contain device models that were common defaults at the time. These are version-dependent historical examples, not universal recommendations for new VMs.

Device category | Example models | Typical use | Version and compatibility note

Firmware | Phoenix BIOS | Traditional VM boot firmware | Modern guests may support or require UEFI; changing firmware after installation can prevent booting.

Chipset and IDE controller | Intel motherboard representation; Intel PCI IDE controller | Presents a conventional PC platform and IDE devices | Model availability depends on virtual hardware compatibility.

Optical drive | IDE CD-ROM device | Boots installation media or reads an ISO image | The guest must have suitable storage and optical-device support.

SCSI controller | BusLogic parallel SCSI; LSI Logic parallel SCSI; LSI Logic SAS | Connects virtual disks | Older guest systems may depend on a particular controller driver.

Network adapter | Intel E1000; Intel E1000e; AMD PCnet | Provides guest network connectivity | Emulated models improve legacy compatibility; supported modern guests often use an optimized VMware adapter.

CPU vendor presentation | AMD or Intel CPU presentation | Exposes processor characteristics to the guest | The visible family can reflect the physical host and migration compatibility configuration.

Video adapter | Standard VGA | Basic guest display output | Newer guest and hardware combinations may offer newer virtual display capabilities.

Do not change a working VM's controller, firmware, or network adapter without checking the guest driver's availability, boot mode, and application requirements. For general settings, see editing virtual machine settings.

VMware virtual machine files

A VM is represented by multiple files stored in a datastore. A datastore is a storage location accessible to ESXi for VM files. A VM directory commonly contains a configuration file, virtual disk files, and optional runtime or recovery files.

Extension or file type | Role | Contains | Operational notes

.vmx configuration file | Defines the VM | Virtual hardware, device settings, boot options, compatibility, and other VM settings | It must reference the correct disks and devices. Do not edit it casually while the VM is running.

.vmdk virtual disk files | Provide virtual disk metadata and data | A descriptor file may describe the disk, while a flat or sparse data component stores disk content | A disk can consist of multiple related files; preserve the complete set.

.nvram firmware settings | Stores virtual BIOS or UEFI state | Firmware variables and settings | It may be recreated in some situations, but preserving it helps retain firmware state.

.log files | Record VM events | Startup, device, and runtime messages | Logs are useful for troubleshooting and may rotate into several files.

.vswp VM swap file | Supports ESXi memory management | A swap file associated with VM memory configuration | It is normally runtime-generated and is not guest application data.

Snapshot delta and metadata files | Track snapshot changes | Changed disk blocks and snapshot relationship information | All dependent files are required; snapshots are not a backup substitute.

Memory-state files | Preserve running or suspended state | Guest memory and device state used by suspend or applicable snapshot operations | They can be large and are needed only for the related state-preservation operation.

The .vmx file describes the virtual computer. The .vmdk files hold the virtual disk metadata and guest data. A simple VM folder might contain one .vmx file and one or more .vmdk components, along with logs and optional runtime files.

Manage VM files as a consistent set. Backup, migration, and recovery operations must account for every required disk component, snapshot dependency, configuration reference, and relevant state file. Copying only the visible configuration file or one disk component can produce an incomplete VM.

Inspecting a VM file set

Use the ESXi Host Client or datastore browser to locate the VM directory and identify its .vmx and .vmdk files. If authorized shell access is enabled, an inspection command can be used:

ls -lh /vmfs/volumes/<datastore>/<vm-folder>/

Replace the placeholders with the datastore name and VM directory. Treat the output as an inventory check, not as permission to move active files manually.

VM mobility and hardware independence

A VM is less tightly coupled to a particular physical server than a traditional operating system installation. Its guest OS continues to see the virtual hardware model while ESXi supplies that model from the current host.

Host migration can move VM execution between compatible ESXi hosts. With the required VMware features and configuration, vMotion can migrate a running VM while retaining its guest OS and virtual hardware identity.

Storage vMotion can relocate a VM's virtual disks between datastores under supported conditions. The guest normally continues to use the same virtual disk device and does not need to be reinstalled.

Mobility is conditional, not automatic. Requirements can include:

  • Appropriate licensing and vCenter Server availability.
  • Compatible CPU features, or a configured CPU compatibility method such as EVC where appropriate.
  • Destination hosts with compatible ESXi and virtual hardware support.
  • Shared storage, or a supported workflow that also transfers VM storage.
  • Equivalent virtual networking, port groups, VLAN access, and uplink connectivity.
  • Access to required datastores, devices, ISO images, and other dependencies.
  • Compatible VM settings and no unsupported host-specific device attachment.

Read about Enhanced vMotion and CPU compatibility for vMotion before planning migrations.

Practical configuration example

Suppose a small server workload is configured as follows:

  • 2 vCPUs
  • 8 GB of virtual memory
  • One 100 GB virtual disk
  • One vNIC connected to the appropriate port group
  • A supported firmware mode and virtual hardware version

The guest OS sees a small computer with two processors, 8 GB of RAM, a 100 GB disk, and a network interface. The physical ESXi host supplies the actual CPU time, RAM, datastore capacity, storage I/O, and network uplink capacity behind those devices.

Configuration fields worth checking

  • Firmware: BIOS or UEFI
  • CPU count and cores per socket
  • Memory allocation
  • SCSI controller selection
  • Network adapter model
  • Virtual disk datastore location
  • Connected virtual switch or port group
  • Boot order and virtual optical-drive connection
  • Virtual hardware compatibility level

Troubleshooting virtual hardware and VM files

Guest OS does not detect a virtual network adapter

Likely causes include a vNIC model without a guest driver, a disconnected adapter, an incorrect port group, or outdated VMware Tools and guest drivers.

  • Confirm that the adapter is connected.
  • Verify the assigned port group and VLAN design.
  • Check the guest device manager or network configuration.
  • Select a vNIC model supported by the guest OS and install the required driver.

VM cannot boot after virtual hardware changes

Changing BIOS to UEFI, changing the storage controller, altering boot order, or detaching the boot disk can prevent startup.

  • Review firmware mode, boot order, controller type, and disk attachment.
  • Confirm that the guest has a driver for the selected storage controller.
  • Revert unsupported changes where possible.
  • Validate compatibility before changing firmware or controller models.

Migration is unavailable or fails

Common causes include incompatible host CPUs, missing datastore access, inconsistent networking, and unmet feature, vCenter, or licensing requirements.

  • Confirm the migration prerequisites for the environment.
  • Verify destination access to required datastores and port groups.
  • Check CPU compatibility and review host warnings.
  • Review task events for the specific failed validation.

Copied virtual disks will not register or start

The .vmx file may be missing or may reference unavailable disks. A multi-file disk or snapshot chain may also have been copied incompletely.

  • Verify that the configuration file and every required VMDK component are present.
  • Check for snapshots and include their dependent delta and metadata files.
  • Confirm that file paths and datastore locations match the VM configuration.
  • Avoid manually moving active VM files; use supported clone, migration, export, or backup workflows.

Exam-relevant summary

  • A VM is an isolated software-based computer that runs a guest OS and applications.
  • ESXi is a bare-metal hypervisor between VMs and physical host hardware.
  • vCPUs, virtual memory, virtual disks, vNICs, firmware, controllers, optical drives, and video adapters form the VM's virtual hardware.
  • The guest OS uses drivers to communicate with virtual devices.
  • The .vmx file defines VM configuration; .vmdk files provide virtual disk metadata and data.
  • VM files must be preserved as a consistent set, especially when snapshots or multi-file disks exist.
  • Configured virtual hardware is not the same as dedicated physical hardware consumed.
  • vMotion moves VM execution between compatible hosts; Storage vMotion relocates VM storage between datastores.
  • Mobility depends on CPU, storage, networking, vCenter, licensing, compatibility, and other environmental prerequisites.