Running several services at home eventually outgrows a single machine running everything directly. A hypervisor lets one physical host run isolated workloads, each with its own environment, restartable and backup-able independently.
Proxmox is the common choice for this because it handles both virtual machines and containers, provides a usable web interface, and does not require a subscription for the software itself.
What changed in 2026
- Container adoption grew relative to full virtual machines. As people understood the overhead difference, more workloads moved to lightweight containers.
- Backup tooling matured. The dedicated backup server component became a standard part of homelab setups rather than an afterthought.
- Passthrough got easier. Assigning hardware directly to a virtual machine, historically fiddly, became better documented and more reliable.
- Mini PCs became the standard host. Low-power compact machines with adequate memory displaced repurposed desktop hardware for many builds.
Virtual machines versus containers
|
Full virtual machine |
Container |
| Isolation |
Complete; own kernel |
Shares the host kernel |
| Overhead |
Meaningful memory and startup cost |
Very light |
| Operating system |
Any supported |
Linux only, sharing the host kernel |
| Hardware passthrough |
Supported |
Limited |
| Snapshot and restore |
Supported |
Supported |
| Right for |
Different operating systems, kernel-level needs, passthrough |
Most Linux services |
Most homelab services do not need their own kernel. A container running a media server, a database, or a web application uses a fraction of the memory a virtual machine would and starts in a moment rather than a minute.
Reserve virtual machines for cases needing a different operating system, kernel modules, or hardware passthrough — a network appliance, a Windows workload, or a media server needing direct access to a graphics device.
Storage planning
This is the decision that is painful to change later.
Decide early whether the host runs on a redundant pool or a single drive with the important data elsewhere. Mixing the boot device and bulk storage on one drive works and gives you no redundancy for either.
Consider separating fast storage for virtual machine disks from bulk storage for media and backups. Virtual machine images benefit from fast random access; large media files do not.
If you use a checksumming filesystem for bulk storage, understand its memory appetite and configuration — ZFS explained covers the integrity benefits and the requirements.
Do not run the storage pool near full. Copy-on-write filesystems degrade badly, and snapshots consume space as they diverge.
Networking and backups
A single network interface works for a basic setup. Separating management, virtual machine traffic, and storage traffic onto different interfaces or virtual networks becomes worthwhile as the lab grows, and it is easier to plan than to retrofit.
Configure backups deliberately. The platform includes backup capability and it does not run by default. Schedule regular backups of every workload you would be annoyed to rebuild, and send them somewhere other than the host — a backup on the machine it protects is not a backup, which is the same point as in NAS buying guide.
Test a restore. A backup you have never restored is a hypothesis.
Skip clustering initially. Multiple-host clustering with shared storage and migration is genuinely useful with several hosts and pure complexity with one.
Common mistakes
- Virtual machines for everything. Wastes memory on workloads containers handle.
- Storage layout decided casually. Painful to change later.
- No configured backups. They do not happen automatically.
- Backups only on the host. Not backups.
- Never testing a restore. Discovering the problem during an emergency.
- Clustering a single node. Complexity without benefit.
- Running the pool near full. Performance degrades sharply.
FAQ
What hardware do I need?
Memory is the usual constraint — more than processor cores for most homelab workloads. A compact low-power machine with generous memory is the common starting point.
Can I pass through a graphics card?
Yes, with motherboard and processor support for the required isolation features. Better documented than it used to be, and still requires care.
Is it free?
The software is free to use. A paid subscription provides access to the enterprise update repository and support; the community repository works without it.
How does this compare to running containers directly?
A hypervisor adds isolation and snapshot capability per workload. Running a container runtime directly is simpler if that is all you need — see Docker vs VMs.
Where to go next
For the container comparison, read Docker vs VMs. For storage, ZFS explained and NAS buying guide, and for hardware, mini PC server guide.