How does a virtual machine work?
One physical host shares its computing resources between multiple independent guest systems through a hypervisor.
Simple definition
A virtual machine (VM) is a computer created in software. It has its own guest operating system, applications, disks and network adapters, but uses resources from a physical host. Multiple VMs can run on one server while remaining logically isolated: restarting one guest normally does not restart the others.
Technical definition
A hypervisor presents virtual components to each VM: CPUs (vCPUs), memory, storage controllers, disks, network interfaces and virtual BIOS or UEFI firmware. A guest operating system, often Windows or Linux, works with these devices as if they were physical. Hardware capabilities such as Intel VT-x or AMD-V assist virtualization. Real performance is still limited by the host's available CPU, RAM, network and storage capacity.
- Physical host CPU, RAM, disk and network
- Hypervisor Resource control and isolation
- Virtual resources vCPU, vRAM, vDisk, vNIC
- Guest OS Windows or Linux
- Applications Hosted services
A host failure may affect several VMs. This diagram shows one guest, but the same hypervisor can run many.
What is it used for ?
Consolidate servers, isolate business applications, build testing environments and provision services quickly. VMs commonly host domain controllers, databases, file servers and monitoring tools. Live migration and high availability are additional platform capabilities, not automatic properties of every virtual machine.
Practical example
A small company runs four VMs on one server equipped with 16 CPU cores, 128 GB RAM and redundant storage: two domain controllers, a business application and a file server. Each guest has assigned resources, yet they all depend on the same host. A physical failure can therefore stop all services if no recovery mechanism is in place.
Common issues
- Too many vCPUs assigned, causing CPU contention and increased scheduling delay.
- Memory pressure or swapping when the physical host runs short of RAM.
- Datastore capacity exhaustion, storage latency or growing snapshot delta files.
- Incorrect virtual-switch or VLAN configuration resulting in network failures.
- Insufficient backups or a single host and storage array becoming a shared point of failure.
Physical host, hypervisor and guest operating system
The host provides physical CPUs, memory, storage and network interfaces. The hypervisor allocates these resources, exposes virtual hardware and controls VM execution. Each guest retains its own accounts, services, applications and updates. This separation simplifies operations but cannot protect against every host failure or management mistake.
Type 1 hypervisors are used in dedicated virtualization platforms, such as VMware ESXi and the virtualization technology underlying Proxmox VE. Other products run VMs through a general-purpose host operating system. Securing the management plane and virtual networks is important in both cases.
Sizing virtual CPUs, RAM, disks and networks
- vCPU: a logical execution resource presented to the guest, not necessarily a permanently reserved physical CPU core.
- RAM: monitor actual memory use and any overcommitment mechanisms; guests can slow dramatically when host memory is exhausted.
- Storage: virtual disks may be files or volumes. Thin provisioning saves initial space but requires close monitoring of free capacity.
- Network: virtual NICs connect to virtual switches or bridges, often mapped to VLANs. Routing and access policies still apply.
- Capacity: plan for workload growth, backup operations and how workloads would restart after a host failure.
Snapshots, replication, cloning and backups
A snapshot preserves a reference state for rollback and often depends on delta files attached to an original disk. Cloning creates another VM or disk copy. Replication maintains a secondary version, sometimes on another host or site. These mechanisms solve different problems and do not automatically replace an independent, recoverable backup.
VM backups should support full-machine or relevant data restoration, with suitable application consistency. Plan retention, isolated or off-site copies, access controls and restore testing. Long-lived snapshots can consume large amounts of space and complicate disk consolidation.
How do VMs differ from containers?
A VM typically runs its own guest operating system and kernel on virtualized hardware. A container isolates application processes while sharing the host kernel, making it lighter for many deployment scenarios. VMs remain useful for complete systems, legacy software and workloads requiring different operating systems.
The approaches complement each other: Docker containers frequently run inside Linux VMs. Choose based on compatibility, isolation requirements, patching and availability rather than assuming that one is always better.
Related terms
Key takeaway: a VM runs a complete guest operating system on shared hardware. Virtualization aids isolation and deployment, but does not replace independent backups, capacity planning or high availability.