# Underneath (Micro)VMs: A Primer in H/W Virtualisation I tend to do deep dives into technologies that I don't fully understand yet to clear up the concepts and build a better mental model of them. That's exactly what this blog is all about. Surprisingly, I realized recently that I have a much better grasp on containers than vms. If you ask most platform engineers or devops folks, they can talk confidently about namespaces, cgroups, and container runtimes, but when it comes to what a vm or a microvm is actually doing down at the silicon level, things get a bit fuzzy. Here is my breakdown of how vms actually work underneath, why they can feel slow, and how modern microvms fix those bottlenecks. * * * ### The Privilege Problem: Rings of Trust ![](https://cdn.hashnode.com/uploads/covers/6a25ff63980616b1c020fc7a/07318bd9-fdd0-4a6d-b6ff-f41d0158ae29.png align="right") To understand vms, we have to look at how cpus handle security. Processors use privilege levels called "rings" to protect the system. * Ring 0 is the most privileged mode—reserved for the os kernel so it can interact directly with physical h/w, memory, and devices. * Ring 3 is restricted, meant for user space apps. In a normal bare-metal setup, your host os owns Ring 0. But when you introduce a traditional vm, the guest os inside that vm *also naturally* expects to run in Ring 0. A bit of throwback first - before h/w virtualization existed, this caused a major conflict. The hypervisor had to force the guest os down into Ring 1 or Ring 3. Every time the guest os tried to execute a privileged kernel command, the cpu would throw an exception. The hypervisor had to trap that error, translate the instruction on the fly, and emulate the response. This "trap-and-emulate" cycle is exactly why old-school vms felt brutally slow. * * * ### Enter Hardware Virtualization (VT-x and AMD-V) To fix this performance bottleneck, cpu manufacturers added specialized hardware extensions (Intel VT-x and AMD-V). They introduced a completely new execution dimension: **Root Mode** and **Non-Root Mode**. * **Root Mode:** Where your host os and hypervisor (like KVM) live. * **Non-Root Mode:** A separate sandbox containerized by the cpu hardware for the guest vm. Inside Non-Root Mode, the guest os gets its own complete set of rings, including its own Ring 0. It thinks it has absolute control over the machine. This splits the lifecycle of an instruction inside a vm into two distinct paths: #### 1\. The Fast Path (99% of work) ![](https://cdn.hashnode.com/uploads/covers/6a25ff63980616b1c020fc7a/b5a78487-2039-4a27-8cc8-ae165295f429.png align="center") When an app inside the vm does basic math, runs loops, or processes data, it fires standard instructions. The physical cpu checks the state, sees it's safe, and executes it **directly on the physical silicon** at bare-metal speed. The hypervisor isn't involved at all. #### 2\. The Hypervisor Path (The 1%) ![](https://cdn.hashnode.com/uploads/covers/6a25ff63980616b1c020fc7a/43a61449-ac95-40c8-94a9-50aa38451da0.png align="center") When the app needs to write a file to disk or send a packet over the network, the guest os fires a privileged hardware instruction. The physical cpu flags this, pauses the vm, and executes a hardware-level context switch called a **vm-exit**. Control is handed back to KVM in Root Mode to safely perform the real physical operation. Once done, it triggers a **vm-entry** to unpause the vm and hand control back to the guest. Because this context switching is baked directly into the cpu silicon, it happens in nanoseconds, keeping the overhead minimal. * * * ### The Catch: Why Traditional VMs Still Feel Heavy Even with h/w virtualization, standard vms take time to boot and consume significant resources. This isn't because of instruction execution; it's because of **hardware emulation bloat**. Traditional hypervisors (like QEMU) emulate decades of legacy hardware to support any random os you might install. They emulate virtual IDE controllers, floppy drives, PCI buses, and ancient graphics cards. Booting a traditional vm means waiting for a full, bloated guest kernel to initialize all these virtual devices. * * * ### Shifting to MicroVMs If you are running modern workloads—like serverless functions or untrusted AI agent code—you need the absolute isolation of a vm kernel boundary, but you can't afford a 10-second boot time or hundreds of megabytes of baseline memory overhead. This is where **microvms** (like Firecracker) come into play. A microvm strips away almost all legacy emulation. It throws out the floppy drives and video cards, providing a hyper-minimal device model (usually just `virtio` for basic block storage and network interfaces). Because the guest kernel is stripped down to the bare essentials, a microvm can boot in less than 200 milliseconds and uses a fraction of the ram of a standard vm. ![](https://cdn.hashnode.com/uploads/covers/6a25ff63980616b1c020fc7a/21161855-0b8e-40c5-bd23-a9ee3cfcc86b.png align="center") ### The Under-the-Hood Stack What makes a microvm fascinating is that it combines both hardware virtualization and traditional container primitives: * **Hardware Boundary:** The code inside the microvm is secured via KVM using the hardware's non-root mode, ensuring a compromised app or agent cannot escape to the host kernel. * **Host Boundary:** On the host side, the Virtual Machine Manager (VMM) process running the microvm is wrapped in a "jailer" that uses standard Linux **namespaces (ns)**, **control groups (cgroups)**, and **seccomp filters**. This gives you a defense-in-depth architecture. Even if an untrusted workload manages to break the guest kernel, it's still trapped by the hypervisor. And if it somehow breaks the hypervisor process, it hits the cgroups and namespaces boundary on the host node. Next up would be a detailed breakdown of 2 of the sandboxes that I intend to trial for securing ai agent related workloads in ther cloud - [just-bash](https://justbash.dev/) vs [microsandbox](https://github.com/superradcompany/microsandbox)! Stay tuned!