04.02 · Concept
Virtual Machines
Describe what a hypervisor virtualises and what that costs relative to running on the metal.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
A hypervisor virtualises hardware, not an application: CPU, memory, disks, network cards, and device interrupts are presented to each guest OS as if it owned a machine. The cost is extra translation and trapping, usually small for CPU-heavy work but more visible for storage and network-heavy systems.
What this lesson answers
- what does a hypervisor virtualise
- virtual machine overhead versus bare metal
- why is virtualised I/O slower
Notes
Virtual Machines — Virtual machines exist to let multiple isolated guest operating systems share one physical machine by virtualising CPU, memory, storage, and devices; without a hypervisor, workloads would either need dedicated hardware or risk corrupting each other’s kernel, memory, and I/O state.
Key Concepts: - A hypervisor presents each VM with virtual hardware such as vCPUs, virtual RAM, virtual disks, and virtual NICs; for example, a guest may see vCPUs and RAM on a host with physical cores and RAM.
References
Common questions
- Does a virtual machine get its own CPU cores?
- Not necessarily. A VM is given vCPUs, which the hypervisor schedules onto physical cores. Those vCPUs may run immediately, or they may wait if the host is busy or oversubscribed. Treat vCPU count as a scheduling and capacity commitment, not a guarantee of dedicated silicon.
- Why can VM performance be close to bare metal for some workloads?
- Modern CPUs include virtualisation support, so ordinary guest code can often execute directly on the host processor. The expensive parts are operations that cross the VM boundary, such as privileged instructions, page-table handling, interrupts, and device access. A CPU-bound service may therefore see little penalty compared with I/O-heavy software.
- How are virtual machines different from containers?
- A VM boots its own guest kernel on virtual hardware supplied by a hypervisor. A container shares the host kernel and isolates processes with operating system features. That makes VMs a stronger boundary in many failure cases, while containers are usually lighter because they do not run a separate kernel.
Short definition: what is Virtual Machines?