Virtual Machine

Hi everyone 👋, I'm Hung Anh.

This is the third article in the Kubernetes Fundamentals series. In the previous article, we saw how limited a physical server really is: one kernel, one set of hardware, one environment. This time, let's see how the Virtual Machine solves that problem, and the downsides of this approach.

Let's get started.

1. What Is a Virtual Machine?

A Virtual Machine (VM) is a computer entirely emulated in software — it has its own complete OS and kernel, runs independently, and knows nothing about any other VM running alongside it on the same physical machine.

It's the strongest level of isolation there is: instead of isolating at the process level, a VM emulates an entire virtual set of hardware, letting a full, real operating system run on top of it — just as if it were installed on real hardware.

2. How a Virtual Machine Works

But if every VM has its own complete OS, how do several of them end up sharing the exact same physical hardware? There has to be a piece of software standing between the real hardware and the VMs, called the hypervisor. Its job is to divide the physical CPU, RAM, and disk among each VM, while keeping them isolated from one another.

Hypervisors come in two kinds, depending on whether there's a host OS underneath them:

• Type 1 (bare-metal hypervisor) — installed directly on the hardware, no host OS needed. Examples: VMware ESXi, KVM. Used in datacenters and production.
• Type 2 (hosted hypervisor) — installed as a regular program running on top of an existing OS. Examples: VirtualBox, VMware Workstation. Used for dev/test on a laptop.

An application installed inside a VM behaves exactly as it would on real hardware: it makes syscalls to that VM's own kernel, that kernel calls down into the hypervisor, and the hypervisor is the one that actually translates the request down to the real hardware. A VM shares only the physical hardware with the real machine (through the hypervisor) — the OS and kernel are each VM's own, completely separate copy.

Related: WSL2 (Windows Subsystem for Linux) is a real-world application of this exact model — it runs a real Linux kernel inside a lightweight VM hidden in the background, letting you run Linux directly on Windows.

3. How This Solves the Previous Article's Problem

Thanks to the hypervisor, a single physical machine can now run several fully independent operating systems at once — one VM needs Ubuntu, another needs CentOS, and both run on the exact same hardware, no new machine required. The capacity that used to sit idle is now shared across multiple VMs instead of going to waste.

4. The Downsides of a Virtual Machine

• Heavy. Each VM carries a full OS and kernel of its own, typically several GB per VM — no matter how small the application running inside it actually is.
• Slow to start. Booting a VM means booting an entire operating system, just like turning on a real computer — tens of seconds to a few minutes, every time.
• Overhead just to exist. Before your application runs a single line of its own code, the VM has already spent CPU and RAM just keeping its own OS alive.

Here's the question that comes out of this: in practice, most VMs on the same server often only need the same one type of OS — say, all of them are Linux. So does each one really need to carry around its own complete kernel?

5. Summary

The Virtual Machine solves the "one machine, one environment" problem by emulating an entire set of hardware for each OS, managed by a hypervisor. But the price is that every VM is heavy, slow to start, and spends resources just running its own OS.

If most VMs only need to share the same OS, is there a lighter way to isolate them?

Time to relax for a bit, then join me in the next article on containers.

Happy reading! 🍵

References

1. What's the difference between Type 1 vs. Type 2 hypervisor? - TechTarget
2. What is Windows Subsystem for Linux - Microsoft Learn