VMware ESXi and vSphere Cluster Management
Virtual Machine Hardware in VMware ESXi and vSphere
Learn how VMware virtual hardware works, including vCPUs, memory, disks, controllers, NICs, hardware versions, compatibility, VM files, and ESXi 5.5 limits.
A virtual machine (VM) is an isolated, software-defined computer that runs on a hypervisor. Instead of communicating directly with a server's physical CPU, memory, storage controller, and network card, the guest operating system sees a collection of virtual hardware devices.
In VMware environments, ESXi is the bare-metal hypervisor that manages physical host resources and presents virtual hardware to VMs. vSphere is the broader VMware platform and management ecosystem used to administer ESXi hosts and virtual machines.
What Is Virtual Machine Hardware?
Virtual hardware is the set of virtual CPU, memory, storage, network, controller, and peripheral devices exposed to a VM. The guest operating system detects these devices through its normal hardware-discovery process and uses drivers to communicate with them.
For example, a guest OS may see a virtual disk as a SCSI disk, a virtual network adapter as an Ethernet adapter, and one or more virtual CPUs as processors. The guest does not need to know the exact model of the physical server underneath.
ESXi maps requests from these virtual devices to physical host resources. A request to write to a virtual disk is handled through the VM's storage configuration and datastore. A packet sent through a virtual NIC is processed through the ESXi networking stack and ultimately reaches a physical network adapter when appropriate.
Virtual hardware and physical hardware are different views
| Layer | What it contains | Who normally manages it |
|---|---|---|
| Physical host | Physical CPUs, RAM, disks, storage adapters, network adapters, and USB devices | ESXi and the hardware administrator |
| Hypervisor | Resource scheduling, device mapping, isolation, and virtual hardware presentation | ESXi |
| Virtual machine | vCPUs, virtual memory, virtual disks, virtual controllers, virtual NICs, and optional devices | VM administrator and vSphere |
| Guest operating system | Drivers, file systems, applications, and guest-visible devices | Guest OS administrator |
The guest OS normally interacts with emulated or paravirtualized devices through its own drivers. An emulated device imitates a conventional hardware device. A paravirtualized device is designed specifically for virtualization and can provide a more efficient communication path when supported by the guest.
This abstraction isolates workloads from one another and makes the VM's hardware view more consistent. A guest can often be moved to another compatible host without being reconfigured for every physical server model.
Core Configurable VM Hardware
| Device | Purpose | Typical configuration consideration |
|---|---|---|
| vCPU | Provides virtual processors to the guest OS | Assign enough processing capacity for the workload, but avoid unnecessary oversizing |
| Memory | Provides RAM to the guest OS | Base the allocation on guest and application demand and available host resources |
| Virtual disk | Presents datastore-backed storage as a guest disk | Choose capacity, datastore, provisioning behavior, and controller location |
| Virtual SCSI controller | Provides attachment paths for virtual disks and certain storage devices | Plan controller and device-node placement for compatibility and workload organization |
| Virtual NIC | Connects the guest to a virtual network | Select the correct port group and a guest-supported adapter type |
| CD/DVD drive | Provides optical media or ISO installation media | Verify the media source and boot order when installing or repairing an OS |
| Floppy drive | Provides legacy removable media support | Use only when a legacy guest or tool requires it |
| USB controller or device | Connects supported USB devices to a VM | Check host attachment, guest drivers, and migration restrictions |
Virtual CPUs
A vCPU is a virtual processor assigned to a guest operating system. ESXi schedules vCPUs on physical processing resources. Adding vCPUs does not automatically improve performance: a workload must be able to use the additional parallelism, and the host must have sufficient capacity.
Start with an allocation appropriate for the application and increase it only when monitoring shows a CPU requirement. Oversized VMs can make scheduling more difficult and may consume capacity needed by other workloads.
Virtual memory
Virtual memory is the RAM allocated to the guest OS. The guest uses it for the operating system, services, file cache, and applications. ESXi must provide or manage the corresponding host memory resources.
Assign enough memory to avoid guest-level memory pressure, but do not treat the platform maximum as a sizing recommendation. Check guest memory use, application requirements, host contention, and any configured reservations or limits.
Virtual hard disks
A virtual disk is presented to the guest as a disk but is stored as a datastore-backed file or object. A virtual disk is attached through a virtual controller, commonly a virtual SCSI controller. When adding a disk, select its capacity, datastore location, provisioning options where available, and virtual device node.
Separate operating-system and data disks can make storage growth, backup selection, and workload organization easier. Disk design must also account for datastore free space, performance requirements, snapshots, and backup behavior.
Virtual network adapters
A virtual NIC is a network adapter exposed to the guest. It connects to a virtual switch, port group, or other configured virtual network. When adding one, select the correct network, choose an adapter type supported by the guest, and decide whether it should be connected at power-on.
The guest still needs its own driver and IP configuration. Connecting a virtual NIC to the wrong port group can produce a functioning adapter with no access to the intended network.
Virtual SCSI controllers
A virtual SCSI controller provides paths between virtual disks and the guest OS. A VM can have multiple controllers, and each controller can provide multiple device locations. Controller choice and placement can matter for guest compatibility, disk organization, and some storage workloads.
Optional and Removable Devices
CD/DVD drives and ISO media
A virtual CD/DVD drive can use an ISO image stored on an accessible datastore or another supported source. It is commonly used to install a guest OS, boot a recovery environment, or apply software from installation media.
- Open the VM hardware or edit-settings view.
- Add or enable a virtual CD/DVD drive.
- Connect it to the required ISO source.
- Configure the VM to boot from the virtual optical device when necessary.
- Disconnect the media after installation or recovery to avoid unintended boots.
Floppy devices
Floppy devices are primarily relevant to legacy VM scenarios. Remove or disable them when they are not required so that the VM configuration remains simpler and does not expose unnecessary removable hardware.
USB passthrough
USB passthrough assigns a USB device physically connected to an ESXi host to a VM. Before using it, verify that the device is connected to the intended host, eligible for VM use, visible to ESXi, and supported by the guest OS.
Physical-device passthrough can create host affinity. A VM using a host-connected USB device may not be freely migrated to a host where that device is unavailable. Document this restriction when planning maintenance, failover, cloning, and disaster recovery.
Virtual Machine Hardware Versions
A virtual machine hardware version is a compatibility level that determines which virtual hardware features a VM can use. It influences supported virtual device capabilities and configuration ceilings, such as the maximum number of virtual CPUs or the maximum memory configuration for that platform release.
A newly created VM generally receives the newest hardware version supported by the creation target, unless an older compatibility level is selected. An older hardware version can usually run on a newer compatible ESXi host, but it cannot use features that require a newer virtual hardware version.
Increasing the hardware version is a compatibility change. It should be planned, tested, and normally performed while the VM is powered off. The change is not automatically reversible and can prevent the VM from running on older ESXi hosts. Keep the oldest possible destination host in mind before upgrading.
Historical vSphere and ESXi virtual hardware support
The following values apply to the historical vSphere 4.x through 5.5 scope. They are not universal rules for every VMware release. Always verify compatibility against the exact ESXi and vCenter versions in use.
| Product or ESXi version | Highest supported virtual hardware version | Management or client requirement | Compatibility notes |
|---|---|---|---|
| ESXi 5.5 with vSphere Web Client | Version 10 | Use the vSphere Web Client for version-10 configuration tasks | Provides the capabilities associated with virtual hardware version 10 |
| ESXi 5.1 and applicable ESXi 5.5 configurations | Version 9 | Verify the exact host and management configuration | Version 9 remains usable on later compatible hosts, but does not expose version-10-only capabilities |
| ESXi 5.x | Version 8 | Check the exact ESXi and vCenter release | Older virtual hardware can preserve compatibility with older hosts |
| ESXi/ESX 4.x | Version 7 | Check the exact release and management tools | Older compatibility levels may run on newer hosts with reduced feature access |
ESXi 5.5 introduced support for virtual hardware version 10 when managed through the vSphere Web Client. Older supported hardware versions remained usable on ESXi 5.5, but those VMs could not use capabilities exclusive to version 10.
Hardware version upgrade checklist
| Question | Why it matters | Recommended action |
|---|---|---|
| Can every potential destination host support the target version? | A newer version may block operation on older hosts | Compare the target version with the oldest host required for migration or recovery |
| Does the guest need a feature introduced by the newer version? | An upgrade may be unnecessary if no new capability is required | Document the feature requirement before changing compatibility |
| Is a powered-off maintenance window available? | Hardware-version changes generally require the VM to be powered off | Schedule downtime and notify application owners |
| Is a backup or tested recovery point available? | The change is not automatically reversible | Create and verify a suitable recovery point before upgrading |
| Could the VM need to return to an older host? | Upgrading can remove that option | Delay the upgrade or retain a compatible recovery copy |
VM Configuration Maximums in the Historical ESXi 5.5 Context
These documented maximums describe platform and version-specific ceilings for the historical ESXi 5.5 context. They are not recommended VM sizes. Production designs should be based on workload requirements, host capacity, performance testing, and the configuration maximums documentation for the exact vSphere release.
| Virtual hardware resource | Maximum per VM | Planning note |
|---|---|---|
| Virtual CPUs | 64 | Use only the number supported by the workload and host capacity |
| Memory | 1 TB | Size according to guest and application demand, not the ceiling |
| Swap file size | 1 TB | Reserve sufficient datastore capacity and understand the effect of host memory policies |
| Virtual SCSI adapters | 4 | Use multiple controllers when device organization or workload design requires them |
| Virtual disks | 60 | Consider manageability, guest limits, backup, and datastore layout |
| Virtual disk size | 62 TB | Verify datastore, provisioning, guest file-system, and release-specific limits |
Virtual Machine Files
A VM is represented by several files and datastore objects. The virtual hardware configuration is stored with the VM configuration; it is separate from the guest OS files inside a virtual disk.
| File or object | Role | Operational consideration |
|---|---|---|
VM configuration file, commonly .vmx | Stores VM settings such as CPU, memory, devices, and compatibility information | Include it in datastore, backup, migration, and recovery planning |
Virtual disk, commonly .vmdk | Stores or describes the guest-visible disk | Plan capacity, performance, snapshots, and backup handling |
Log files, commonly .log | Record VM and device events | Useful for troubleshooting, but not a substitute for VM backup |
Swap file, commonly .vswp | Provides a host-side swap area associated with VM memory policies | Requires datastore space and may be created or removed with VM power state |
Snapshot files and metadata, commonly -delta and .vmsd | Represent snapshot changes and snapshot inventory information | Monitor growth and remove snapshots through supported management operations |
Firmware state, commonly .nvram | Stores virtual firmware settings | Preserve it when firmware state is relevant to boot and recovery |
Datastore placement affects available capacity, performance, migration, backup, and recovery. A VM's configuration files and virtual disks must be discoverable and protected together according to the selected recovery method.
Types and Design Considerations for Virtual Disks
Virtual disks are datastore-backed files or objects presented to the guest as disks. Their apparent disk type inside the guest depends on the virtual controller and guest drivers, while their underlying storage behavior depends on datastore technology and provisioning choices.
When adding a virtual disk, consider:
- Capacity: Include current need and expected growth without treating the platform maximum as a target.
- Datastore: Confirm free capacity, performance, redundancy, and appropriate placement.
- Controller: Select a compatible virtual SCSI controller and available device node.
- Provisioning: Understand how the selected provisioning option consumes datastore space and behaves during growth.
- Snapshots: Account for additional space and performance effects while snapshots exist.
- Backup: Confirm that the backup product includes the disk and handles its provisioning and snapshot state correctly.
- Guest configuration: The guest may need a storage rescan, initialization, partitioning, formatting, or mounting.
Common Configuration Workflows
Review a VM's virtual hardware
- Select the virtual machine in the vSphere client.
- Open the VM edit-settings or hardware configuration view.
- Review CPU, memory, disks, controllers, network adapters, and removable-device entries.
- Confirm that device settings match guest requirements and host capabilities.
Create a standard application server VM
- Assign an initial number of vCPUs and memory based on the application requirement.
- Add an operating-system virtual disk.
- Add a separate data virtual disk when the workload benefits from separating application data from the OS disk.
- Attach a virtual NIC to the required port group.
- Choose a hardware version supported by every ESXi host on which the VM may need to run.
Add a virtual disk for database growth
- Open VM hardware settings and choose to add a hard disk.
- Specify the disk size, datastore location, provisioning choices where applicable, and virtual device node.
- Attach the disk to an available virtual SCSI controller location.
- Power on the VM and rescan storage in the guest OS if necessary.
- Initialize, partition, format, and mount the disk inside the guest OS.
Add a virtual network adapter
- Open VM hardware settings and add a network adapter.
- Select the required virtual network or port group.
- Choose an adapter type supported by the guest OS.
- Ensure the adapter is connected at power-on if network access is required.
- Configure IP networking inside the guest OS.
Change VM hardware compatibility
- Identify the oldest ESXi host that must be able to run the VM.
- Confirm target hardware-version support in the installed vSphere release and management client.
- Create a backup or recovery point and schedule downtime.
- Power off the VM.
- Use the compatibility or upgrade virtual hardware action to select the intended supported version.
- Power on the VM and validate guest devices, operating system behavior, and application functionality.
Pass through a host-connected USB device
- Confirm that the device is physically connected to the intended ESXi host.
- Verify that ESXi can see the device and that it is eligible for VM use.
- Add the USB device to the VM hardware configuration.
- Confirm guest driver support.
- Document host affinity and its effect on migration and recovery.
No specific command-line procedure is required for these core tasks. The historical hardware-version and device-configuration examples use the vSphere client interface.
Practical Compatibility Example
Suppose an older VM must run on a newer ESXi 5.5 host, but it may later need to return to an older host. Keep the VM at its existing older hardware version. It can run on the newer compatible host, but it cannot use capabilities introduced with hardware version 10. Upgrade only after confirming that older-host compatibility is no longer required and after testing the guest and applications.
Troubleshooting Virtual Hardware
VM cannot power on after moving to an older host
The most likely cause is that the VM's hardware version is newer than the destination host supports. Identify the VM hardware version and compare it with the destination host's compatibility level. Run the VM on a compatible newer host or restore a compatible pre-upgrade VM copy.
Hardware version 10 is unavailable in an ESXi 5.5 environment
Version 10 configuration required the historical vSphere Web Client workflow. Verify the ESXi version and management client, use the supported Web Client workflow, and confirm that the intended hosts support the selected compatibility level.
New virtual disk is missing in the guest OS
Verify that the disk was added successfully, that it is attached to the expected controller and device node, and that the VM was restarted if required. Rescan storage in the guest OS, then initialize, partition, and format the disk.
USB device cannot be attached
Check the physical connection to the ESXi host, device visibility, ownership, VM USB configuration, and guest drivers. Also determine whether the device is unsupported or already claimed and whether host affinity prevents the intended migration.
Performance worsened after increasing CPU or memory
The VM may be oversized, the host may lack sufficient resources, or the actual bottleneck may be storage, networking, or the application. Review guest and host utilization metrics, right-size vCPU and RAM, and check storage latency, network connectivity, and application-specific constraints.
Exam-Relevant Notes
- A VM sees virtual hardware; ESXi manages the physical hardware underneath.
- A virtual disk is attached through a virtual controller, commonly a virtual SCSI controller.
- A virtual NIC must be connected to the correct virtual network or port group and supported by the guest OS.
- Hardware version is a compatibility level, not merely a cosmetic VM setting.
- An older hardware version can run on a newer compatible host, but it cannot use newer-version-only features.
- Increasing hardware version should be planned, tested, backed up, and generally performed with the VM powered off.
- Hardware-version upgrades can prevent operation on older ESXi hosts and are not automatically reversible.
- Historical ESXi 5.5 version-10 configuration used the vSphere Web Client.
- Published maximums are ceilings, not sizing recommendations.
- USB passthrough can create host affinity and restrict migration options.
When reviewing a VM, start with its virtual hardware configuration, then verify the guest drivers, datastore placement, virtual network, hardware version, and destination-host compatibility. For broader context, see Virtual Machine Hardware.