Xen Summit 2026: VM vs Docker vs Bare Metal for Self-Hosting

Xen Summit 2026 opens in Munich on September 15 at an interesting moment for virtualization. Docker can package almost every self-hosted application people care about, yet hypervisors are still evolving across cloud, security, embedded systems and hardware-intensive workloads.

The useful question for a home-server owner is not “Xen or Docker?” They operate at different layers. The real decision is: where does each workload need its boundary?

Xen Summit 2026: Why Do Hypervisors Still Matter?

Xen Summit 2026 runs September 15–17 in Munich, with two days of technical talks followed by a day of architecture and design sessions. The program spans cloud infrastructure, security, Arm, embedded systems, automotive, tooling and real-world deployments.

Xen 4.22 also arrived shortly before the Summit. The current release is supported through July 2029, with security support extending to July 2031. That lifecycle says something about modern virtualization: the value is increasingly not “how many VMs can this box run?” but how reliably can infrastructure isolate, control and maintain workloads over time?

That is also why containers never made hypervisors obsolete.

Docker Did Not Kill the Virtual Machine

Containers solve an extremely useful problem: package applications and dependencies without packaging an entire guest operating system for every service.

Docker's container documentation highlights the architectural difference: containers can share the host kernel, while a virtual machine runs a guest operating system with its own kernel.

Container
────────────
Application
Dependencies
────────────
Shared host kernel


Virtual Machine
────────────
Application
Guest userspace
Guest kernel
────────────
Virtualized hardware

Containers optimize application deployment.

VMs create another operating-system boundary.

And in real infrastructure they are commonly stacked:

Hardware
   ↓
Hypervisor
   ↓
Virtual machine
   ↓
Container runtime
   ↓
Containers

So “VM versus Docker” is often the wrong debate.

The real question is which boundary the workload actually needs.

The Four Boundaries of a Self-Hosted Server

The mistake is expecting one layer to solve another layer's problem.

A container does not protect you from the physical host dying. Six VMs on the same SSD do not create six independent storage systems. A second server does not fix weak application authentication.

And giving every ordinary web app its own VM can recreate the deployment overhead containers were meant to remove.

Use the cheapest boundary that actually satisfies the requirement.

Do You Actually Need a VM? Use the Five-Question Test

1. Does it need a different operating system or kernel?

Windows, a complete second Linux distribution, a firewall appliance or OS-level testing are straightforward VM candidates.

Different OS / kernel required?
            ↓
           VM

2. Does it need a separate trust boundary?

Security experiments, less-trusted software, build workers and disposable test environments may justify separating the guest OS from the primary host.

A VM is not automatically “secure,” but it gives you a different isolation boundary than another process sharing the same host kernel.

3. Does it need low-level OS or network control?

Firewalls, routing labs and appliance operating systems often benefit from having their own operating environment rather than repeatedly modifying the container host around them.

4. Does it need direct hardware ownership?

This is where virtualization becomes especially interesting.

A workload may need a:

• GPU,
• network adapter,
• HBA,
• USB controller,
• other PCIe device.

Xen's current infrastructure documentation includes PCI passthrough and SR-IOV precisely because sometimes the architectural question becomes:

which guest owns this physical device?

5. Is it simply another application?

If the workload is a conventional dashboard, media service, database-backed web app, download tool or automation service—and it does not require another kernel or special trust boundary—a container is usually the simpler starting point.

VM vs Container vs Bare Metal for Home Servers

The important distinction is that resource use and isolation are separate questions.

A tiny Linux VM may consume very little. An AI container can consume an entire GPU and tens of gigabytes of memory.

The One-Box Problem: Consolidation Has Three Ceilings

Most home-server sizing starts with CPU and RAM. In practice, a consolidated server can become “full” for three different reasons.

Compute ceiling

The familiar one: there is not enough CPU, RAM, storage performance, GPU capacity or VRAM for another workload.

Isolation ceiling

The host still has resources available, but you no longer want another workload sharing the same kernel, privileges, hardware or administrative boundary.

Failure ceiling

The workloads technically fit, but too many important services now fail together.

One physical host
├── DNS
├── storage
├── Home Assistant
├── media
├── Windows VM
└── experiments

One reboot now affects the entire house.

This gives home-server consolidation a better model:

Server capacity
is not only limited by:

CPU + RAM

It can also be limited by:

Isolation tolerance

or

Failure tolerance

A server can hit its isolation or failure ceiling long before its CPU reaches 100%.

Virtual Isolation Is Not Physical Redundancy

Creating six VMs gives you six useful software boundaries. It does not give you six independent physical machines.

Host fails
   ↓
Hypervisor stops
   ↓
Every VM on that host stops

The same applies to storage. Five VM disks on one dead SSD are still five unavailable VM disks.

This is the part that becomes especially important when a homelab quietly turns into home production.

Three Real Virtualization Lessons From Zima Home Labs

The boundary model becomes easier to understand when it is applied to real hardware rather than diagrams.

1. A lightweight VM host still has a memory ceiling

ZimaOS has included native ZVM support since version 1.3, including one-click Windows and Linux VM installation. Its current virtual machine hardware requirements also make an important point that generic “how many VMs?” calculators often hide: guest type, active workload, snapshots and memory allocation matter more than a fixed VM count.

A recent real-world test reached the same conclusion. Mart ran a Windows 7 VM under Proxmox on an 8 GB compact server and showed that one modest guest was realistic, but guest memory quickly reduces what remains available to the host and other services. The Proxmox and Windows VM test is a useful reminder that virtualization does not create RAM.

The first virtualization ceiling on a small server is often memory, not CPU.

2. Passthrough is really about ownership

Jonatan Castro's 2026 Proxmox build demonstrates the hardware-boundary question more clearly.

In his setup, ZimaOS runs as a VM while a physical SATA AHCI controller is passed through from Proxmox. ZimaOS then sees the attached drives and creates RAID at the guest level.

Physical SATA drives
       ↓
SATA controller
       ↓
PCI passthrough
       ↓
ZimaOS VM
       ↓
Storage Manager

The value is not simply “a NAS can run in a VM.”

The useful architectural detail is that storage ownership is explicit: instead of giving the guest only abstract virtual disks, the guest receives the relevant physical controller.

The full Proxmox virtualization and SATA passthrough build also demonstrates why PCIe topology and IOMMU support matter once virtualization touches real devices.

3. One box can run many things—but HA requires another box

The same build provides an even better lesson about the failure ceiling.

One compact node carries a large portion of the service workload, while a separate NAS node and quorum device participate in the broader Proxmox design. Services marked for HA can move when one node is restarted.

That architecture exposes a distinction that single-server benchmarks cannot:

Many VMs on one host
≠
High availability

Multiple failure-capable nodes
+
shared / movable workload design
=
a path toward HA

You do not need high availability for an ordinary home server. But if the requirement is “this workload survives one physical node going down,” creating another VM on the same node does not satisfy it.

What Hardware Features Actually Matter for Virtualization?

“Supports virtualization” is too vague once the lab moves beyond basic VMs.

For ordinary guests, CPU virtualization support, enough RAM and fast VM storage are the basics.

For passthrough and networking experiments, also look at:

• IOMMU support such as Intel VT-d or AMD-Vi,
• available PCIe expansion,
• multiple physical network interfaces,
• firmware support,
• device/IOMMU grouping,
• enough memory for both host and guests.

XCP-ng's current PCI passthrough documentation explicitly distinguishes normal CPU virtualization from the IOMMU functionality required for physical device assignment.

For a compact homelab, a compact x86 home server with VT-x, VT-d, PCIe expansion and multiple Ethernet interfaces can therefore be more interesting than simply buying the CPU with the largest core count.

The hardware should follow the boundary you are trying to build.

Xen Is a Hypervisor; XCP-ng Is a Platform

Xen Summit also exposes another common virtualization confusion: projects at different layers are often compared as though they are equivalent products.

Xen is the hypervisor foundation.

XAPI provides management tooling around Xen.

XCP-ng packages those components into a complete virtualization platform.

Virtualization platform
───────────────────────
XCP-ng + management

Management/toolstack
───────────────────────
XAPI

Hypervisor
───────────────────────
Xen

Hardware
───────────────────────
CPU / RAM / NIC / GPU / Storage

The same principle applies elsewhere: a virtualization platform is more than the hypervisor underneath it.

For a self-hoster, the practical choice is therefore not only about hypervisor technology. It is also about VM lifecycle, networking, storage, backups and how much of that platform you actually want to operate.

AI Makes Hardware Ownership Relevant Again

Containers made application packaging more portable. Local AI is reminding infrastructure builders that hardware is less portable.

A GPU introduces questions that a normal web container may never need:

Who owns the GPU?

Does one VM need the entire device?

Where do the drivers live?

Can the device reset cleanly?

Can multiple workloads share it?

Does the host expose usable IOMMU groups?

This is one reason passthrough remains relevant in a Docker-first world.

Containers simplified software ownership. Accelerators brought hardware ownership back into the architecture discussion.

The Right Boundary Matters More Than the VM Count

Xen Summit 2026 is useful to self-hosters even if they never install Xen.

The broader lesson is that bare metal, VMs and containers are not maturity levels where one eventually replaces the others.

Bare metal
→ direct hardware ownership

Virtual machine
→ OS / kernel boundary

Container
→ application boundary

Application permissions
→ user / data boundary

Use containers when an application boundary is enough.

Use a VM when the operating system, trust model or physical-device ownership deserves its own boundary.

Use bare metal when another abstraction layer adds more recovery complexity than useful flexibility.

And when one machine starts carrying everything, stop asking only whether it has spare CPU.

Ask which limit you reached:

Compute ceiling?

Isolation ceiling?

Failure ceiling?

The goal of virtualization is not to maximize VM count. It is to put the right boundary around the right workload.

FAQ

When is Xen Summit 2026?

Xen Summit 2026 runs September 15–17 in Munich, Germany. September 15–16 focus on technical talks, while September 17 is dedicated to design sessions and project planning.

Is Xen the same as XCP-ng?

No. Xen is the underlying hypervisor. XCP-ng is a complete virtualization platform built around Xen and the XAPI toolstack, with management, storage, networking and VM lifecycle capabilities.

Should I use a VM or Docker for self-hosting?

Use a container when an application can safely share the host kernel and mainly needs reproducible packaging. Consider a VM when the workload needs another operating system, kernel, trust boundary or dedicated hardware assignment.

When should I use bare metal instead of a VM?

Bare metal can be simpler when one workload dominates the machine, direct hardware ownership is important or passthrough would add recovery complexity without providing a useful isolation benefit.

Can I run a NAS inside a VM?

Yes, but define storage ownership clearly. Passing through a storage controller can give the NAS guest more direct ownership of physical disks, while bare metal may remain simpler when storage is the machine's primary role.

Does virtualization protect against physical server failure?

No. VMs isolate software environments but can still share one motherboard, power supply and storage system. Multiple VMs on one host do not create physical redundancy.

What does GPU passthrough require?

GPU and other PCI passthrough generally require IOMMU support such as Intel VT-d or AMD-Vi in addition to ordinary CPU virtualization, plus compatible firmware, device topology and hypervisor configuration.