Virtual Machines
A virtual machine is a complete guest computer, including its own operating system kernel, running on virtual hardware supplied by a hypervisor. The hypervisor virtualises CPU, memory, disks, network cards, and other devices so multiple isolated operating systems can share one physical host without directly owning the hardware.
Virtual machines solve the problem of sharing expensive physical machines without letting workloads interfere at the kernel or device level. If every service needed its own server, utilisation would be poor and provisioning slow. If unrelated workloads all ran inside one operating system, a kernel bug, bad driver, or privileged process could corrupt shared state. A VM gives each workload the illusion of owning a machine, while the host keeps actual control.
The hypervisor presents virtual hardware: vCPUs, virtual RAM, virtual disks, and virtual network interfaces. The guest boots as if those devices were real. Ordinary CPU instructions can often run directly on the processor, while privileged operations trap to the hypervisor. Memory accesses pass through an extra translation from guest addresses to host addresses. Device operations are either emulated, or handled through paravirtual drivers such as virtio-net and virtio-blk.
The cost is not just abstract overhead. VM exits, virtual interrupts, nested memory translation, and virtualised I/O all add work compared with bare metal. CPU-bound code can be close to native, but storage and networking are often where the bill appears, especially with emulated devices or synchronous disk writes. A common misunderstanding is that a vCPU is a dedicated physical core. It may just be scheduled time on an oversubscribed host.
Engineers meet VMs as cloud instances, development guests, and the machines underneath container platforms. EC2 instances, Google Compute Engine VMs, OpenStack guests, and many Kubernetes nodes are virtual machines. The important distinction from containers is the kernel boundary: containers share the host kernel, while a VM runs its own. That is why a panic inside one guest usually does not take down neighbouring guests on the same host.
Common questions
- What does a hypervisor virtualise?
- It virtualises hardware resources, not the application itself. The guest operating system sees CPUs, memory, disks, network cards, timers, and other devices that look like machine hardware. The hypervisor maps those virtual resources onto the real host and intercepts operations that require privileged control.
- Are virtual machines slower than bare metal?
- Usually yes, but the size and location of the overhead depends on the workload. Pure CPU work may be close to bare metal because many instructions run directly. I/O-heavy workloads can suffer more because disk and network operations cross virtual device layers and may cause extra traps into the hypervisor.
- How are VMs different from containers?
- A VM runs a full guest operating system with its own kernel on virtual hardware. A container is an isolated process tree sharing the host kernel. That makes containers lighter, but the isolation boundary is different. With VMs, a guest kernel crash usually stays inside that guest.
- What is a Type 1 versus Type 2 hypervisor?
- A Type 1 hypervisor runs directly on the hardware and is common in servers, with examples including VMware ESXi, Hyper-V, and KVM. A Type 2 hypervisor runs above a normal host operating system, such as VirtualBox or VMware Workstation, and is common on developer machines.