Ever needed stronger isolation than containers can offer – but got blocked by hardware requirements, slow boot times, or expensive cloud instance types? You’re not alone. Modern workloads often need VM-level security boundaries, but full virtualization can feel like bringing a forklift to a footrace.

At Edera, we built around a different model: paravirtualization. It allows the guest OS to work directly with the hypervisor, eliminating the need for hardware emulation or privileged instruction traps. This model gives us the performance and isolation we need without being tied to specific instance types or silicon features.

Why We Care about Isolation

Before we get into the technical details, let’s ground this a bit. Containers are fast and easy to work with, but they all share a kernel. That shared surface introduces risk, especially in multi-tenant environments (environments where several different applications are accessing the same computing resources). VMs offer stronger isolation but are slower to boot, heavier to run, and often require hardware virtualization flags that may not be available in the cloud.

Paravirtualization offers a middle-ground option: fast startup, strong isolation, no dependency on specific CPU features, and significantly lower cost than bare metal, which can be 2–3× more expensive per vCPU and GiB. Here's how it works.

A Quick Tour of Virtualization Models

Full Virtualization

Full virtualization runs an unmodified guest OS by simulating the hardware it expects. The guest operates under the assumption that it’s installed on physical hardware. To support this illusion, the hypervisor must emulate every component, including CPUs, disk and network devices, interrupts, and more.

Privileged CPU instructions issued by the guest are intercepted and handled by the hypervisor. This model is broadly compatible, but often inefficient.

Hardware-Assisted Virtualization

To reduce some of the overhead associated with full virtualization, modern processors have introduced hardware virtualization support (e.g., Intel VT-x, AMD-V). These features enable guests to execute specific privileged instructions directly within constrained contexts managed by the hypervisor.

While this helps with performance, it's only available when the hardware exposes it to the guest. In cloud environments, these features are often disabled or unavailable, especially on standard VM types.

Xen calls this hardware virtual machine (HVM).

Paravirtualization

With paravirtualization, the guest OS is aware that it’s virtualized and is designed to communicate directly with the hypervisor using hypercalls. These hypercalls are cooperative interfaces—essentially agreements between the guest and the hypervisor—that handle things like memory allocation, I/O, and interrupts. Because the guest doesn’t pretend it’s on real hardware, the hypervisor doesn’t need to emulate devices or intercept privileged instructions.

That cuts out the overhead you’d normally see with full virtualization and makes the whole stack simpler to reason about. It also means there’s less complexity to debug when things go wrong.

Hybrid Virtualization

Some platforms mix and match. You’ll see guests using hardware virtualization for CPU execution, but relying on paravirtualized drivers for things like disk or network access. It’s a practical way to boost performance without needing a fully paravirtualized guest, but it does add some complexity and depends on having the right hardware available.

Why Edera Went With Paravirtualization

Edera zones, production-grade sandboxes, are built around full paravirtualization. The Linux guest running in each zone is configured to use hypercalls for everything from memory allocation to CPU scheduling to I/O. It doesn’t attempt to run privileged instructions at all.

This means we don’t need emulation, we don’t rely on nested virtualization, and we don’t require special instance types. Zones boot quickly, isolate cleanly, and run on a wide range of hardware, including nearly all EC2 instance types.

This design also gives us strong memory isolation. Instead of having the guest edit page tables directly, it requests that the hypervisor make the changes. The hypervisor enforces safety checks and ensures one zone can’t interfere with another. Even without VT-x, we get solid, hardware-enforced boundaries.

A Quick Analogy: Ivy’s Class

Here’s a way to picture it.

Ivy is in a classroom where she doesn’t speak the same language as the teacher. When she wants to ask a question, she must pass a note to a translator, who rewrites it, delivers it, waits for the response, and then translates it back. It works, but it’s slow, awkward, and not always accurate.

Now, imagine Ivy and the teacher speak the same language. She asks her question directly and gets a clear answer right away. The interaction is smoother and more reliable.

This direct line of communication between the guest and hypervisor – like Ivy and her teacher – is what defines Edera’s architecture. Instead of simulating hardware behavior and translating privileged operations, we build zones that speak the hypervisor’s language natively.

How This Plays Out in Practice

Because our entire stack is paravirtualized, we avoid the usual trappings of full virtualization. There’s no QEMU, no userspace device emulation, and no dependency on a general-purpose host OS. The hypervisor manages isolation and resource control directly, without relying on layered abstractions or slow translation paths.

Take networking, for example. In a traditional VM, network traffic passes through a virtual NIC, down through the hypervisor, and eventually into the host’s networking stack. Each hop adds overhead. In Edera, zones can pass packets straight into the host network stack. There’s no copying, no translation – just efficient, direct handling.

The same model applies to CPUs and memory. Zones don’t make assumptions about hardware – they make requests. The hypervisor responds, validates, and enforces boundaries. Every zone’s setup – memory maps, CPU scheduling, and device access – is handled through tightly scoped hypercalls. This provides us with strong isolation, fast startup, and predictability across various environments.

Boot times are measured in milliseconds. We can run securely on nearly any cloud instance type – no costly VT-x required. We enforce strong memory isolation using the same minimal hypervisor, regardless of where it runs. 

We’ve also benchmarked Edera against industry alternatives including Docker, gVisor, Kata Containers, and Firecracker to demonstrate how our technology delivers security without compromising performance.

We’ve also reworked much of the Xen toolstack in Rust, simplifying the control plane and reducing the surface area compared to traditional C-based systems. What you get is a system that appears to be a container runtime from the outside, but is backed by hardened hypervisor boundaries underneath.

Final Thoughts

We built Edera around paravirtualization because it solves real problems. It gives us fast boot times, hardened isolation, and the ability to run securely on almost any infrastructure, even when hardware virtualization isn’t available.

For teams building systems that require strong isolation, fast cold starts, and portability across edge and cloud environments, Edera’s hardened runtime might be right for you.

We'd love to show you how this works in practice.

Want to go deeper into the foundation?

‍Here’s how Xen fits into all of this →

More on PV on our docs site