The virtualization layer runs CPU instructions to make sure that the virtual machines run as though accessing the physical processor on the ESXi host. Performance is paramount for CPU virtualization, and therefore will use the ESXi host physical resources whenever possible.

A virtual machine can be configured with up to 128 virtual CPUs (vCPUs) as of vSphere 6.0. The maximum vCPUs able to be allocated depends on the underlying logical cores that the physical hardware has. Another factor in the maximum vCPUs is the tier of vSphere licensing; only Enterprise Plus licensing allows for 128 vCPUs. The VMkernel includes a CPU scheduler that dynamically schedules vCPUs on the ESXi host's physical processors.

The VMkernel scheduler, when making scheduling decisions, considers socket-core-thread topology. A socket is a single, integrated circuit package that has one or more physical processor cores. Each core has one or more logical processors, also known as threads. If hyperthreading is enabled on the host, then ESXi is capable of executing two threads, or sets of instruction, simultaneously. Effectively, hyperthreading provides more logical CPUs to ESXi on which vCPUs can be scheduled, providing more scheduler throughput. However, keep in mind that hyperthreading does not double the core's power. During times of CPU contention, when VMs are competing for resources, the VMkernel time-slices the physical processor across all virtual machines to ensure that the VMs run as if having a specified number of vCPUs.

VMware Virtual Symmetric Multiprocessing (SMP) is what allows the virtual machines to be configured with up to 128 virtual CPUs, which allows a larger CPU workload to run on an ESXi host. Though most supported guest operating systems are multiprocessor aware, many guest OSs and applications do not need and are not enhanced by having multiple vCPUs. Check vendor documentation for operating system and application requirements before configuring SMP virtual machines.

In a physical architecture, an operating system assumes that it owns all physical memory in the server, which is a correct assumption. A guest operating system in a virtual architecture also makes this assumption but it does not, in fact, own all of the physical memory. A guest operating system in a virtual machine uses a contiguous virtual address space that is created by ESXi as its configured memory.

Virtual memory is a well-known technique that creates this contiguous virtual address space, allowing the hardware and operating system to handle the address translation between the physical and virtual address spaces. Since each virtual machine has its own contiguous virtual address space, this allows ESXi to run more than one virtual machine at the same time. The virtual machine's memory is protected against access from other virtual machines.

This effectively results in three layers of virtual memory in ESXi: physical memory, guest operating system physical memory, and guest operating system virtual memory. The VMkernel presents a portion of physical host memory to the virtual machine as its guest operating system physical memory. The guest operating system presents the virtual memory to the applications:

The virtual machine is configured with a set of memory; this is the sum that the guest OS is told it has available to it. A virtual machine will not necessarily use the entire memory size, it only uses what is needed at the time by the guest OS and applications. However, a VM cannot access more memory than the configured memory size. A default memory size is provided by vSphere when creating the virtual machine. It is important to know the memory needs of the application and guest operating system being virtualized so that the virtual machine's memory can be sized accordingly.

There are two key components with virtual networking: the virtual switch and virtual Ethernet adapters. A virtual machine can be configured with up to 10 virtual Ethernet adapters called vNICs. A vNIC is the virtual machine's network adapter that connects it to the port group on a virtual switch, whereas a vmnic is the physical NIC acting as an uplink on an ESXi host.

Virtual network switching is software interfacing between virtual machines at the vSwitch level until the frames hit an uplink or a physical adapter, exiting the ESXi host and entering the physical network. Virtual networks exist for virtual devices; all communication between the virtual machines and the external world (physical network) goes through vSphere standard switches or vSphere distributed switches.

Virtual networks operate on layer 2, data link, of the OSI model. A virtual switch is similar to a physical Ethernet switch in many ways. For example, virtual switches support the standard VLAN (802.1Q) implementation and have a forwarding table, like a physical switch. An ESXi host may contain more than one virtual switch. Each virtual switch is capable of binding multiple vmnics together in a Network Interface Card (NIC) team, which offers greater availability to the virtual machines using the virtual switch.

There are two connection types available on a virtual switch: a port group and a VMkernel port. Virtual machines are connected to port groups on a virtual switch, allowing access to network resources. VMkernel ports provide a network service to the ESXi host to include IP storage, management, vMotion, and so on. Each VMkernel port must be configured with its own IP address and network mask. The port groups and VMkernel ports reside on a virtual switch and connect to the physical network through the physical Ethernet adapters known as vmnics. If uplinks (vmnics) are associated with a virtual switch, then the virtual machines connected to a port group on this virtual switch will be able to access the physical network.

In a non-virtualized environment, physical servers connect directly to storage, either to an external storage array or to their internal hard disk arrays to the server chassis. The issue with this configuration is that a single server expects total ownership of the physical device, tying an entire disk drive to one server. Sharing storage resources in non-virtualized environments can require complex filesystems and migration to file-based Network Attached Storage (NAS) or Storage Area Networks (SAN), or with vSphere 6.0, Virtual SAN (VSAN) or Virtual Volumes (VVOLs).

Shared storage is a foundational technology that allows many things to happen in a virtual environment (High Availability, Distributed Resource Scheduler, and so on). Virtual machines are encapsulated in a set of discrete files stored on a datastore. This encapsulation makes the VMs portable and easy to be cloned or backed up. For each virtual machine, there is a directory on the datastore that contains all of the VM's files. A datastore is a generic term for a container that holds files as well as .iso images and floppy images. It can be formatted with VMware's Virtual Machine File System (VMFS) or can use NFS. Both datastore types can be accessed across multiple ESXi hosts.

VMFS is a high-performance, clustered filesystem devised for virtual machines, which allows a virtualization-based architecture of multiple physical servers to read and write to the same storage simultaneously. VMFS is designed, constructed, and optimized for virtualization. The newest version, VMFS-5, exclusively uses 1 MB block size, which is good for large files, while also having an 8 KB subblock allocation for writing small files such as logs. VMFS-5 can have datastores as large as 64 TB. The ESXi hosts use a locking mechanism to prevent the other ESXi hosts accessing the same storage from writing to the VMs' files. This helps prevent corruption.

Several storage protocols can be used to access and interface with VMFS datastores. These include Fibre Channel, Fibre Channel over Ethernet, iSCSI, and direct attached storage. The NFS protocol can also be used to create an NFS datastore. The VMFS datastore can be dynamically expanded, allowing the growth of the shared storage pool with no downtime.

vSphere significantly simplifies accessing storage from the guest OS of the VM. The virtual hardware presented to the guest operating system includes a set of familiar SCSI and IDE controllers; this way the guest OS sees a simple physical disk attached via a common controller. Presenting a virtualized storage view to the virtual machine's guest OS has advantages such as expanded support and access, improved efficiency, and easier storage management.

The .vmx file describes the current configuration information and hardware settings for the VM. This can contain a large variety of information regarding the virtual machine, to include its specific virtual hardware configuration (amount of RAM, NIC settings, CD-ROM information, parallel/serial port information, and so on), as well as its advanced resource and power settings, VMware tools options, and so forth. It is possible to make changes and directly edit this file; however, you should only do this at your own risk.

The .vmx file is a plain-text file that functions as the structural definition of the VM. The .vmx file can be copied from the datastore and opened using a program that supports the creation and saving of files using UTF-8 encoding, such as WordPad. The following excerpt shows an example of a .vmx file for a virtual machine named ExampleVM:

.encoding = "UTF-8" 
config.version = "8" 
virtualHW.version = "11" 
nvram = "ExampleVM.nvram" 
pciBridge0.present = "TRUE" 
svga.present = "TRUE" 
pciBridge4.present = "TRUE" 
pciBridge4.virtualDev = "pcieRootPort" 
pciBridge4.functions = "8" 
pciBridge5.present = "TRUE" 
pciBridge5.virtualDev = "pcieRootPort" 
pciBridge5.functions = "8" 
pciBridge6.present = "TRUE" 
pciBridge6.virtualDev = "pcieRootPort" 
pciBridge6.functions = "8" 
pciBridge7.present = "TRUE" 
pciBridge7.virtualDev = "pcieRootPort" 
pciBridge7.functions = "8" 
vmci0.present = "TRUE" 
hpet0.present = "TRUE" 
svga.vramSize = "8388608" 
memSize = "4096" 

sched.cpu.units = "mhz" 
sched.cpu.affinity = "all" 
sched.mem.affinity = "all" 
powerType.powerOff = "default" 
powerType.suspend = "default" 
powerType.reset = "default" 
scsi0.virtualDev = "lsisas1068" 
scsi0.present = "TRUE" 
sata0.present = "TRUE" 
scsi0:0.deviceType = "scsi-hardDisk" 
scsi0:0.fileName = "ExampleVM.vmdk" 
sched.scsi0:0.shares = "normal" 
sched.scsi0:0.throughputCap = "off" 
scsi0:0.present = "TRUE" 
ethernet0.virtualDev = "e1000e" 
ethernet0.networkName = "VM Network" 
ethernet0.addressType = "vpx" 
ethernet0.generatedAddress = "00:50:56:ac:e1:a8" 
ethernet0.present = "TRUE" 
sata0:0.startConnected = "FALSE" 
sata0:0.deviceType = "cdrom-raw" 
sata0:0.clientDevice = "TRUE" 
sata0:0.fileName = "emptyBackingString" 
sata0:0.present = "TRUE" 
floppy0.startConnected = "FALSE" 
floppy0.clientDevice = "TRUE" 
floppy0.fileName = "vmware-null-remote-floppy" 
displayName = "ExampleVM" 
guestOS = "windows8srv-64" 
disk.EnableUUID = "TRUE" 
toolScripts.afterPowerOn = "TRUE" 
toolScripts.afterResume = "TRUE" 
toolScripts.beforeSuspend = "TRUE" 
toolScripts.beforePowerOff = "TRUE" 
uuid.bios = "42 2c 9e f6 48 47 8f 8c-60 2f 5a 66 37 0a 6e 3c" 
vc.uuid = "50 2c 81 6b 04 4c 47 19-77 c9 16 97 d0 1b 33 43" 
sched.cpu.min = "0" 
sched.cpu.shares = "normal" 
sched.mem.min = "0" 
sched.mem.minSize = "0" 
sched.mem.shares = "normal" 

Reading through this file gives us important information regarding the configuration of the virtual machine. Here are a few examples:

A virtual machine's .vmx file is most commonly edited to modify the MAC address so that it matches the effective MAC address set within the guest operating system. However, this practice is becoming less and less common due to this configuration change being done more easily in the vSphere Web Client.

The .vmx file is extremely important to the virtual machine. However, keep in mind that it only structurally defines the VM's virtual hardware composition. It does not hold any actual data from the guest OS running within the VM. The virtual machine's data is stored in its virtual disk file. Here's an overview of the configuration and BIOS files:

The .vswp file is created when the virtual machine is powered on. The size of the .vswp file is equal to that of a configured memory, unless there is a reservation. When a memory reservation is configured for a VM, then the .vswp file size would equal the configured memory size minus the memory reservation. This file is used as a last resort when the hypervisor is reclaiming physical memory from its virtual machines due to contention.

Looking at the previous table, you may have noticed the vmx-<vmname>.vswp file. This file is for the overhead memory created for a VM, a new feature in vSphere 5.x. Historically, this memory overhead was not swappable. Though there was a memory reservation to back this, the entire address space did not actually have to reside in memory. This file helps to reduce the reservation requirements for virtual machines.

The following are some of the virtual disk files:

The following are the snapshot files:

Let's take a look at some other files: