VMware ESXi and vSphere Cluster Management

Virtual Machine Hardware in VMware ESXi

Learn how VMware ESXi presents virtual hardware to guests, including vCPUs, memory, disks, controllers, NICs, hardware versions, compatibility, VM files, and configuration limits.

Virtual machine hardware is the collection of virtual devices and resource settings presented to a guest operating system. In VMware ESXi, this hardware includes processors, memory, storage controllers, virtual disks, network adapters, firmware, and removable devices.

An ESXi host is the physical server running the VMware hypervisor. A guest operating system is the operating system installed inside a virtual machine (VM). The guest normally interacts with the virtual hardware model rather than directly with the host's physical CPU, memory, storage, or network adapters.

How Virtual Machine Hardware Works

ESXi presents a standardized set of devices to the guest. Some devices are emulated, meaning ESXi reproduces the behavior of a known physical device. Others are paravirtualized or otherwise optimized so that the guest and hypervisor can cooperate more efficiently.

During installation, the guest operating system detects virtual processors, virtual RAM, virtual disks, storage controllers, network adapters, firmware, and other devices much as it would detect hardware in a physical computer. The guest generally does not need to know which physical server model is underneath it.

This separation provides portability. A VM can often be registered, powered on, cloned, or migrated between compatible VMware platforms without reinstalling the guest operating system. Portability is conditional: the destination host must support the VM's virtual hardware version, configured devices, storage, networking, and guest requirements.

Common Virtual Hardware Devices

Virtual CPUs and CPU topology

A vCPU is a virtual processor assigned to a VM. The guest sees one or more processors according to the VM's CPU configuration. CPU topology settings can determine how vCPUs are presented as sockets and cores. Use a topology that matches the guest operating system and application licensing requirements.

Do not assign vCPUs solely because the ESXi host has many physical cores. Excessive vCPU allocation can increase scheduling overhead and make it harder for a busy host to provide CPU time to every VM. Begin with the workload's actual requirements and increase allocation only when monitoring shows a need.

Virtual memory

Virtual memory is the amount of RAM configured for the guest. ESXi maps this memory to physical memory and may use memory-management techniques when host demand is high. A VM can also have a host-side VM swap file, which is used for VM memory management and normally requires datastore space.

Memory sizing should account for the guest operating system, applications, workload peaks, host contention, and any reservations or limits. Host capacity alone is not a reason to allocate maximum memory to every VM.

Virtual disks and controllers

A virtual disk is commonly stored as a VMDK, VMware's virtual disk file format. The VMDK is attached to a virtual SCSI controller, which exposes a device node to the guest. The guest operating system then detects that node as a disk and can partition, format, and mount it.

Controller selection matters before installation or migration. A guest may need a suitable driver for the selected controller. Changing controllers later can alter device identification or prevent the guest from booting until drivers and configuration are corrected.

ESXi supports multiple virtual SCSI controller types, depending on the VM hardware version, ESXi release, and guest operating system. Use a controller supported by both the target VMware environment and the guest.

Virtual networking

A virtual NIC is a network interface presented to the guest. Its connection is associated with a port group, a virtual networking connection point on a standard or distributed switch. The port group determines the virtual network to which the NIC connects, including relevant VLAN and security settings.

Select the intended port group and an adapter model supported by the guest. After adding or replacing a NIC, validate the guest driver, link state, interface identity, IP address, routes, firewall rules, and application connectivity.

Removable and additional devices

• CD/DVD drive: Connect it to an ISO image stored in a datastore, host media where supported, or disconnect it. ISO attachment is commonly used to install a guest operating system.
• USB controller: Provides virtual USB support. A physical USB device can be assigned through USB passthrough when it is connected to the ESXi host running the VM.
• Floppy drive: A legacy device that may be available for older operating systems or specialized workflows.
• Graphics adapter: Provides virtual display functions; advanced graphics options depend on the environment and hardware version.
• Serial and parallel ports: Useful for selected legacy or appliance workloads when supported.
• TPM device: Provides virtualized trusted-platform functionality when supported by the ESXi release, VM compatibility level, and guest.
• PCI devices: May be assigned through passthrough or related mechanisms, subject to host hardware and mobility restrictions.
• Boot firmware: BIOS or EFI/UEFI controls how the VM starts. Firmware choice should match the guest installation and boot configuration.

Virtual Machine Hardware Version

The virtual hardware version is the compatibility level assigned to a VM. It defines which virtual devices, features, resource maximums, and platform capabilities are available to that VM. VMware management interfaces may describe the same concept as VM compatibility or hardware compatibility.

Compatibility depends on several layers:

• The VM hardware version must be supported by every ESXi host on which the VM may run.
• The vCenter Server and vSphere client or host client must be able to display and configure the selected compatibility level.
• The guest operating system must support the virtual devices selected.
• Configured features such as USB, PCI, TPM, graphics, and storage controllers may have additional host requirements.

New VMs normally use the newest compatibility level selected by the administrator and supported by the target environment. A VM with an older hardware version can often run on a newer ESXi host, but it does not automatically gain newer virtual devices, features, or higher limits.

Upgrading compatibility is generally a one-way change in normal workflows. Before upgrading, identify every host that may run the VM, verify support, review backup and rollback options, and consider migration requirements. The VM is typically powered off before changing its virtual hardware compatibility level.

Historical ESXi/vSphere virtual hardware compatibility

The following table is a historical course-era example, not a current product-limit table. Administrative client capabilities affected whether a particular version could be selected or configured.

Do not treat these historical maximums as current ESXi limits. For a deployed release, check the applicable VMware compatibility documentation and the capabilities of the installed management tools.

Historical VM Configuration Maximums: ESXi 5.5 Context

These figures are release-specific examples from the ESXi 5.5 lesson context. They are not universal values for every virtual hardware version, ESXi release, guest, datastore, or controller configuration.

Virtual Disks and VM Files on a Datastore

A datastore is the storage location for VM configuration, disks, logs, swap, firmware, and snapshot-related data. A VM commonly has a folder containing several files rather than one single monolithic object.

Disk provisioning affects datastore consumption. With thin provisioning, a virtual disk initially consumes space as data is written, although metadata and growth requirements still matter. With thick provisioning, capacity is reserved according to the selected thick format. Monitor free space in either case.

Plan for the virtual disk's configured capacity, thin-disk growth, thick reservations, snapshots, VM swap, logs, and datastore overhead. A datastore that fills can interrupt disk growth, snapshots, swap creation, or normal VM operation.

Safe Workflow for Configuring VM Hardware

1. Identify requirements: Determine guest CPU, memory, storage, network, firmware, removable-device, and application needs.
2. Check compatibility: Verify the target ESXi host, cluster members, management client, guest drivers, datastore, and desired hardware version.
3. Check power state: Determine whether the change supports hot-add or hot-plug. Power off the VM when required, especially for hardware compatibility changes and many device edits.
4. Open hardware settings: In the vSphere Client or ESXi Host Client, open the VM's Edit Settings or equivalent hardware configuration view.
5. Add or edit devices: Adjust CPU and memory, add a disk and controller, select a NIC and port group, or configure CD/DVD, USB, and other supported devices.
6. Review before saving: Check controller placement, disk provisioning, boot order, connection state, port group, and compatibility level.
7. Save and start: Apply the change, power on the VM if it was shut down, and watch for host or VM compatibility errors.
8. Validate inside the guest: Confirm CPU and memory recognition, network driver and connectivity, storage visibility, controller drivers, and CD/DVD or USB detection.

CPU and memory hot-add, NIC hot-plug, and some disk operations may be available only when enabled in advance and supported by the guest, hardware version, ESXi release, and licensing or configuration. Do not assume that every device can be changed while powered on.

Example: basic application-server VM

1. Assign a modest number of vCPUs and an appropriate memory allocation based on the application requirements.
2. Add a virtual SCSI controller and a virtual disk on a datastore with sufficient free space.
3. Add a virtual NIC and connect it to the application network port group.
4. Attach an ISO through the virtual CD/DVD drive for guest installation.
5. Install the guest operating system and verify that it sees the expected CPU, memory, disk, and network hardware.

For guest installation procedures, see Install a Guest Operating System.

Example: adding a data disk

1. Confirm datastore capacity and the VM's power-state requirements.
2. Add a new VMDK to an existing or additional supported SCSI controller.
3. Start the VM or rescan storage in the guest as appropriate.
4. Initialize, partition, format, and mount the disk inside the guest.
5. Verify that the disk remains attached to the intended controller after a reboot.

Increasing an existing virtual disk's capacity is a separate operation; review dynamically increasing virtual disk size before changing production storage.

Example: upgrading hardware compatibility

1. List every ESXi host on which the VM may run.
2. Confirm that all destination hosts support the target hardware version.
3. Review backups, snapshots, application recovery, and rollback options.
4. Power off the VM and apply the compatibility upgrade.
5. Power on the VM and validate guest drivers, storage, networking, firmware, and application behavior.

Example: attaching a USB device

1. Verify that the USB device is physically connected to the ESXi host currently running the VM.
2. Add or enable the required virtual USB controller.
3. Connect the selected host USB device to the VM.
4. Confirm that the guest detects the device and loads a suitable driver.
5. Plan host affinity because the VM may need to remain on that host while the device is in use.

Compatibility, Portability, and Operational Cautions

• A VM's portability depends on destination hosts supporting its hardware version and every configured device.
• Upgrading compatibility can prevent the VM from running on older hosts. Plan migrations and rollback before the change.
• A newly added device may not function if the guest lacks a compatible driver.
• USB passthrough ties the device to the host where it is physically connected and can interfere with automated migration or failover.
• Changing a storage controller can change guest disk identity or cause boot failure.
• Changing a NIC model can create a new guest interface identity, requiring IP configuration or driver updates.
• Boot firmware and boot-device order must match the guest installation. An incorrect order can make a healthy disk appear unbootable.

VMware features such as Enhanced vMotion and EVC address particular migration compatibility concerns, but they do not remove the need to verify virtual hardware, devices, storage, and guest support.

Troubleshooting Virtual Hardware

The VM cannot power on after moving to another host

Likely causes include an unsupported VM hardware version or a device that the destination host cannot provide. Compare the VM compatibility level and device configuration with every destination host. Move the VM to a compatible host, or choose a planned compatibility strategy after assessing recovery and downgrade limitations.

The guest does not see a new virtual disk

Check that the disk is attached to the expected controller and that the controller is enabled. Rescan storage in the guest, confirm that the guest has the required controller driver, and complete guest-side initialization, partitioning, formatting, and mounting.

Network connectivity fails after changing the virtual NIC

Verify the vSwitch and port group assignment, the NIC connection and link state, and guest driver support for the adapter model. Then review the guest's interface identity, IP address, routes, firewall, and application settings.

A desired hardware option is unavailable

The VM may use an older hardware version, the ESXi host or management client may not support the feature, or the VM may be powered on. Check the VM compatibility level, ESXi release, client capabilities, and power state. A planned shutdown and compatibility upgrade may be required.

A USB device cannot be connected

Confirm that the device is attached to the ESXi host running the VM, that a supported virtual USB controller is configured, and that another VM or host process has not claimed the device. Account for the resulting host-affinity and migration limitations.

Datastore space is unexpectedly exhausted

Inspect VM file usage and datastore capacity. Thin-provisioned disks may have expanded, snapshots may have grown, or swap and log files may consume space. Review provisioning and snapshot state, then reclaim or expand capacity using approved operational procedures. Snapshot operations should be planned; see consolidating snapshots.

Exam-Relevant Notes

• Virtual machine hardware is what the guest sees; it is not a direct copy of the physical server's devices.
• A VMDK is attached through a virtual controller, and the guest must have a compatible controller driver.
• A virtual NIC connects to a port group, not directly to a physical switch port.
• An older hardware-version VM may run on a newer host without receiving newer hardware features.
• Hardware compatibility upgrades are generally one-way and should be planned around the oldest host that may run the VM.
• Power-state requirements, guest drivers, datastore capacity, boot order, and host portability are part of safe hardware planning.
• Historical limits such as 64 vCPUs, 1 TB RAM, four virtual SCSI adapters, 60 virtual disks, and 62 TB per virtual disk belong to the specified ESXi 5.5 context, not all current releases.