A virtual machine (VM) is a complete, software-defined computer with its own virtual CPU, memory, disks and network interfaces, running a full guest operating system on physical hardware that it shares with other VMs. In virtualization, the VM is the unit that a hypervisor creates, isolates and schedules, and in cloud computing it is the classic form of rented compute, sold as an instance or a server.
The guest operating system behaves as if it owned real hardware, but every resource it sees is abstracted and multiplexed by the hypervisor. This separation gives a VM its defining properties: strong isolation between tenants, hardware independence of the workload, and the ability to snapshot, migrate, clone and resize a server as if it were a file.
How a virtual machine runs on shared hardware
A virtual machine runs because the hypervisor intercepts privileged operations that the guest kernel would normally perform directly on hardware. Ordinary application instructions execute natively on the physical CPU at full speed, while sensitive actions such as changing page tables, handling interrupts or accessing devices trigger a VM exit to the hypervisor, which emulates or mediates them before returning control.
Modern processors make this efficient through hardware-assisted virtualization: Intel VT-x and AMD-V add a separate privilege mode for guests, and second-level address translation (Intel EPT, AMD NPT) lets the memory management unit translate guest addresses without software shadow page tables. Earlier x86 virtualization relied on binary translation or paravirtualization, both of which carried more overhead.
The following table lists the main virtual components inside a VM and how the hypervisor typically provides each of them.
| Component | What the guest sees | How it is usually provided |
|---|---|---|
| vCPU | One or more processor cores | A thread scheduled on a physical core or hyperthread |
| Virtual memory | Contiguous physical RAM | Host memory mapped through EPT or NPT |
| Virtual disk | A block device | An image file, logical volume or network volume |
| Virtual NIC | An Ethernet adapter | A paravirtual device bridged to a virtual switch |
| Firmware | BIOS or UEFI | Emulated firmware, often with a virtual TPM |
For input and output, guests usually load paravirtual drivers such as virtio, which exchange data with the host through shared memory queues instead of emulating a real network card or disk controller. When even that is too slow, device passthrough (PCIe passthrough or SR-IOV) assigns a physical device or a slice of it directly to the VM, at the cost of making live migration harder.
Hypervisor types and virtual machine variants
Virtual machines differ mainly by the type of hypervisor beneath them and by how the guest cooperates with it. A type 1 hypervisor runs directly on the hardware and dominates data centers and public clouds, while a type 2 hypervisor runs as an application on a desktop operating system and suits development and testing.
| Variant | Where it runs | Typical use |
|---|---|---|
| Type 1 (bare metal) | Directly on server hardware | Data centers, public cloud instances |
| Type 2 (hosted) | On top of a desktop OS | Developer laptops, labs, training |
| Paravirtualized guest | Guest kernel aware of the hypervisor | Lower I/O overhead in cloud fleets |
| MicroVM | Minimal device model, fast boot | Serverless functions, sandboxed workloads |
| Confidential VM | Memory encrypted by the CPU | Sensitive data on shared infrastructure |
MicroVMs strip the virtual hardware down to a few paravirtual devices, which lets them boot in roughly a hundred milliseconds or less and keep memory overhead to a few megabytes. Confidential VMs use CPU features such as AMD SEV-SNP or Intel TDX to encrypt guest memory so that even the host operator cannot read it, which changes the trust model of multi-tenant cloud computing.
Virtual machines compared with containers and bare metal
A virtual machine virtualizes hardware, whereas a container virtualizes the operating system: each VM boots its own kernel, while all containers on a host share one kernel and are separated by namespaces and control groups. This difference explains nearly every practical trade-off between the two.
| Property | Virtual machine | Container | Bare-metal server |
|---|---|---|---|
| Isolation boundary | Hardware-enforced, separate kernel | Shared kernel, OS features | Physical separation |
| Startup time | Seconds to minutes | Milliseconds to seconds | Minutes, including firmware |
| Image size | Gigabytes with a full OS | Megabytes to hundreds of megabytes | Not applicable |
| Guest OS choice | Any OS for the CPU architecture | Must match the host kernel | Any supported OS |
| Performance overhead | Low for CPU, higher for I/O | Near native | None |
| Density per host | Tens of VMs | Hundreds of containers | One workload |
In practice the two are combined rather than chosen exclusively. Most managed Kubernetes clusters run containers inside VMs, using the VM as the security and billing boundary and containers as the packaging and scheduling unit. Bare metal remains the choice when a workload needs every CPU cycle, specialized hardware access or a license tied to physical cores.
Sizing and operating a virtual machine
Correct sizing starts from measured demand, not from the physical server being replaced. A VM is defined by its vCPU count, memory, disk type and throughput, and network bandwidth, and in the cloud these are bundled into instance types with fixed ratios, commonly about 2 GiB, 4 GiB or 8 GiB of memory per vCPU for compute-optimized, general-purpose and memory-optimized families.
Operational features are a main reason to use VMs at all. Snapshots capture disk and optionally memory state for rollback, live migration moves a running VM between hosts with a pause typically measured in milliseconds, and templates or golden images make new servers reproducible. These features depend on shared or replicated storage and compatible CPU generations across hosts.
The table below matches common operating situations with a recommended approach.
| Situation | Recommended approach | Reason |
|---|---|---|
| Legacy application needing a specific OS | Lift and shift into a VM | No code changes, full OS control |
| Latency-sensitive database | Dedicated vCPUs, local or provisioned IOPS storage | Avoids noisy neighbors and I/O jitter |
| Bursty development servers | Burstable instance types or schedules | Pays only for real usage |
| Untrusted code from customers | One VM or microVM per tenant | Hardware-enforced isolation boundary |
| Many stateless microservices | Containers on a small VM fleet | Higher density, faster deployment |
Limitations and common mistakes
The virtualization layer is thin but not free. CPU overhead is usually a few percent, but I/O-heavy workloads can lose more, and overcommitment of vCPUs or memory creates contention that appears as CPU steal time, ballooning and swapping inside the guest.
- Treating a snapshot as a backup: snapshots usually live on the same storage, and long chains degrade disk performance.
- Oversizing VMs by habit: idle vCPUs still cost money in the cloud and can increase scheduling latency on a busy host.
- Ignoring steal time: a guest reporting high steal is waiting for the host, so adding vCPUs inside it rarely helps.
- Assuming isolation is absolute: side-channel attacks on shared CPUs have shown that patching the hypervisor and microcode remains essential.
- Letting images drift: manually changed VMs diverge from their templates, so configuration should be applied by automation.
A non-technical view
A virtual machine is a computer made of software that lives inside a real computer. One powerful physical server can be divided into many smaller pretend computers, and each of them believes it has its own processor, memory and hard drive.
A useful comparison is an apartment building. The building is the physical server, and each apartment is a virtual machine with its own locked door, its own furniture and its own tenants. The building manager, the hypervisor, decides how much space and electricity each apartment gets. Tenants do not see each other, and an apartment can be renovated, copied or moved without tearing down the building.
A concrete example
A regional accounting firm runs eleven aging physical servers for email filtering, a file share, a tax application that requires an older Windows Server release, and several databases. Most of them sit at under 10% CPU utilization, while the hardware support contracts are expiring.
The IT team converts each server into a virtual machine and places all eleven on two modern hosts with a type 1 hypervisor and shared storage. Each VM gets only what monitoring shows it needs, for example 2 vCPUs and 8 GiB of memory for the file share. Because both hosts can run every VM, the team live migrates workloads from one host to the other before applying firmware updates, so maintenance no longer requires an evening outage.
The result is two physical machines instead of eleven, lower power and cooling costs, and a nightly snapshot-based backup of every server. The legacy tax application keeps its required operating system without any code changes.