Proxmox VE: The Infrastructure Foundation for Realm Labs

Proxmox VE is one of the core platforms behind Realm Labs.

It provides the virtualisation layer for a growing collection of Linux containers, virtual machines, monitoring services and internal tools, all running from a single physical host.

What started as a convenient way to test a few systems gradually became part of the everyday infrastructure.

Today, Proxmox handles much of the compute side of the lab, while storage, monitoring and other services are deliberately separated around it.

The Proxmox Host

The main Proxmox host in Realm Labs is a Shuttle DS81 named:

QuanChi

It runs Proxmox VE directly on the hardware and provides the platform for both LXC containers and full virtual machines.

The host itself is kept relatively simple.

Its main job is to provide compute.

That separation is intentional because I do not want one machine to become responsible for compute, storage, backups and every other important part of the lab at the same time.

Why Proxmox?

I wanted a platform that could handle both lightweight Linux services and full operating systems without needing separate physical machines for every workload.

Proxmox fits that well because it combines:

  • KVM virtual machines
  • LXC containers
  • browser-based management
  • virtual networking
  • snapshots
  • backups
  • storage management
  • console access
  • resource monitoring

For a homelab, that is a very useful mix.

It gives me enough flexibility to run small services efficiently while still supporting Windows and other workloads that need a complete VM.

Containers and Virtual Machines

One of the biggest advantages of Proxmox is being able to choose the right type of guest for the job.

I generally use LXC containers for lightweight Linux services.

Virtual machines are used when a full operating system is required.

The rough decision looks like this:

Lightweight Linux service
        |
        +--> LXC container


Full operating system required
        |
        +--> Virtual machine

That keeps the environment efficient without forcing everything into the same model.

LXC Containers

LXC containers are a good fit for services that:

  • run continuously
  • use relatively little memory
  • do not need a separate kernel
  • are easy to rebuild
  • perform one clear role

They start quickly and generally have less overhead than a full VM.

That makes them ideal for a lot of Realm Labs infrastructure services.

Services Running as Containers

The exact list changes as the lab evolves, but Proxmox has hosted containers for services such as:

  • Mosquitto MQTT
  • InfluxDB
  • Grafana
  • Telegraf
  • qBittorrent
  • Uptime Kuma
  • Homepage
  • SNMP Exporter
  • monitoring utilities
  • other Linux services

Some of these run permanently.

Others are created for testing and removed later.

That flexibility is one of the main reasons Proxmox works so well in a homelab.

Virtual Machines

Virtual machines are used when stronger isolation or a complete guest operating system is needed.

Windows is the most obvious example.

Realm Labs has used VMs for:

  • Windows 11
  • testing environments
  • domain-related systems
  • application testing
  • other workloads that do not fit naturally into an LXC container

A VM behaves much more like a physical computer while still benefiting from Proxmox management.

Windows on Proxmox

Windows VMs are particularly useful for lab work.

They can be:

  • snapshotted
  • cloned
  • reset
  • rebuilt
  • isolated from other systems
  • integrated into the domain
  • monitored

That makes them ideal for testing configuration changes without risking a physical PC.

If something goes wrong, the environment can usually be recovered much faster than rebuilding a standalone machine from scratch.

Snapshots

Snapshots are one of the most useful tools when experimenting.

Before making a risky change, I can create a snapshot.

The workflow becomes:

Create snapshot
      |
Make change
      |
Test
      |
      +--> Works
      |
      +--> Fails
             |
             v
         Roll back

That is extremely useful for:

  • software upgrades
  • Group Policy testing
  • configuration changes
  • package updates
  • experimental setups

Snapshots make testing less stressful.

Snapshots Are Not Backups

They are useful, but I do not treat them as a replacement for proper backups.

A snapshot normally still depends on the same host and storage.

If the underlying storage fails, the snapshot may disappear with it.

So I think of them as:

Snapshots = short-term recovery
Backups   = real recovery

Both have a place.

Storage Separation

One of the biggest design choices in Realm Labs is keeping storage separate from compute where practical.

Proxmox provides the compute layer.

The Synology NAS provides central storage and backup capacity.

At a high level:

Proxmox
  |
  +-- Compute
  +-- VMs
  +-- LXCs


Synology
  |
  +-- Shared Data
  +-- Backups
  +-- Persistent Storage

This means a problem with the Proxmox host does not automatically mean all important data disappears too.

Synology Integration

The Synology DS224+ named Seido provides storage services across Realm Labs.

Proxmox interacts with it for things such as:

  • network storage
  • backups
  • shared data
  • persistent application data

The relationship is useful because each system has a clear role.

QuanChi provides compute.

Seido provides storage.

That makes troubleshooting much easier.

Network Storage

Linux-based systems can access Synology storage using NFS.

Windows systems can use SMB.

Proxmox can therefore participate in the same wider storage environment as the rest of the lab.

The result is:

             Synology
                |
        +-------+-------+
        |               |
      NFS              SMB
        |               |
    Proxmox          Windows
    Linux
    Raspberry Pi

This makes storage much easier to manage centrally.

Virtual Networking

Proxmox uses Linux bridges to connect guests to the wider network.

From the point of view of the rest of Realm Labs, a VM or container can behave like another normal network device.

For example:

Physical Network
       |
       v
Proxmox Bridge
       |
   +---+---+
   |       |
  VM      LXC

This allows guests to communicate with:

  • Synology
  • Raspberry Pi systems
  • Home Assistant
  • Windows clients
  • switches
  • monitoring services
  • other containers and VMs

DNS Matters

One lesson that comes up repeatedly in Realm Labs is that DNS is critical.

A VM can be perfectly healthy while still appearing broken because another system cannot resolve its hostname correctly.

That is especially noticeable with:

  • domain services
  • internal applications
  • monitoring
  • storage
  • service-to-service communication

So when a Proxmox guest looks unreachable, I do not immediately assume the guest itself is the problem.

DNS and networking are usually high on the troubleshooting list.

Resource Allocation

One of the useful things about virtualisation is being able to allocate resources per guest.

For example:

Container A
  CPU: 1 core
  RAM: 512 MB

Container B
  CPU: 2 cores
  RAM: 2 GB

Windows VM
  CPU: 4 cores
  RAM: 8 GB

The numbers can then be adjusted as required.

This is much more efficient than over-provisioning every service by default.

More Resources Are Not Always Better

Homelab services often need far less than expected.

A lightweight MQTT broker, for example, does not need huge amounts of RAM.

Likewise, a small monitoring utility may run happily with very modest resources.

I prefer starting with a sensible allocation and increasing it only if monitoring shows the guest actually needs more.

That keeps the host efficient.

Monitoring Proxmox

QuanChi is monitored alongside the rest of the Realm Labs infrastructure.

Useful metrics include:

  • CPU load
  • memory usage
  • swap usage
  • disk usage
  • temperature
  • uptime
  • VM status

This data is surfaced through monitoring tools and Home Assistant dashboards.

That gives me a quick view of the host without always opening the Proxmox interface itself.

Home Assistant Integration

Some Proxmox systems are represented inside Home Assistant using status sensors and control buttons.

That can include:

  • host status
  • VM state
  • CPU usage
  • memory usage
  • restart controls
  • shutdown controls
  • snapshot actions

This is not intended to replace the Proxmox web interface.

It just brings useful operational controls into the same dashboard as the rest of the lab.

Grafana and Prometheus

For deeper monitoring, Realm Labs also uses Prometheus and Grafana.

Those tools provide:

  • historical metrics
  • trend analysis
  • detailed graphs
  • PromQL queries
  • long-term visibility

Home Assistant gives me the quick operational view.

Grafana gives me the deeper analysis.

Both are useful for different reasons.

Backups

As Proxmox became more important, backups became more important too.

A good backup strategy focuses on being able to recreate the important parts of the environment.

That includes:

  • VM backups
  • container backups
  • configuration
  • application data
  • external storage
  • documentation

The hypervisor itself can be reinstalled.

The important part is being able to restore the workloads and data it was hosting.

Recovery Matters More Than Installation

Installing Proxmox is easy.

Rebuilding a mature environment is not.

Once the host contains multiple services, it becomes important to know:

  • what runs where
  • what depends on what
  • where data is stored
  • how services are backed up
  • which IPs and hostnames are used
  • which guests are critical

This is where documentation starts becoming more valuable than the hypervisor itself.

Naming Guests

I try to give VMs and containers meaningful names.

A list like:

vm100
vm101
ct102
ct103

is not very useful on its own.

A better naming approach makes the role of the guest obvious.

That matters more as the environment grows.

Proxmox and Active Directory

Proxmox is also useful for Windows domain work.

A Windows VM can be joined to the Order Realm domain and used to test:

  • Group Policy
  • mapped drives
  • user permissions
  • domain login
  • desktop configuration
  • Remote Desktop

This gives me a safe place to experiment without needing another physical machine.

Proxmox and Docker

Proxmox and Docker solve different problems.

I do not see them as competitors.

The stack can look like:

Physical Host
    |
    v
Proxmox
    |
    +-- LXC
    |
    +-- VM
          |
          v
        Docker

There are situations where running Docker inside a VM makes sense.

There are others where a standalone LXC service is simpler.

The goal is to use the right layer for the workload.

When I Use LXC

I prefer LXC when:

  • the service is Linux-based
  • isolation requirements are modest
  • low overhead matters
  • the service is easy to rebuild
  • I do not need a full VM

That covers a large number of homelab services.

When I Use a VM

I prefer a VM when:

  • Windows is required
  • a full kernel is needed
  • stronger isolation is useful
  • the application expects a normal full OS
  • I want a completely separate environment

This keeps the architecture fairly straightforward.

Proxmox as a Lab Platform

One of the best things about Proxmox is how easy it makes experimentation.

If I want to test something:

Create guest
     |
Install software
     |
Test
     |
Keep or delete

There is no need to permanently change the main host operating system.

That keeps experiments isolated and reduces the chance of one project breaking another.

Rebuilding Services

A good homelab service should ideally be easy to rebuild.

That means:

  • configuration is documented
  • data is stored safely
  • backups exist
  • dependencies are known

If a container disappears, I should not be worried about the container itself.

I should care about whether the service can be recreated.

That mindset has made Proxmox much easier to manage over time.

Troubleshooting Proxmox Guests

When a VM or container appears broken, I normally check the basics first.

Is the Guest Running?

Check the Proxmox interface.

If it is stopped, that is the obvious first problem.

Does It Have an IP?

From inside the guest:

ip addr

or on Windows:

ipconfig

Can It Reach the Gateway?

ping 192.168.68.1

Can It Resolve DNS?

nslookup seido.order.realm

Can It Reach the Required Service?

For example:

ping seido

or:

curl http://service

Working through the network path systematically is usually faster than making random changes.

Host Health

The Proxmox host itself also needs monitoring.

If several guests fail at the same time, I check QuanChi before assuming every service broke independently.

Useful host checks include:

  • CPU usage
  • memory pressure
  • swap usage
  • storage
  • temperature
  • network
  • recent logs

One unhealthy hypervisor can make a lot of unrelated services appear broken.

What I Have Learned

Proxmox has taught me that virtualisation is not really about creating more computers.

It is about separating workloads.

A good virtualised environment lets me change one service without disturbing everything else.

It also makes testing much safer.

The biggest lessons have been:

  • keep storage separate where practical
  • do not over-allocate resources
  • monitor the host
  • back up workloads
  • document dependencies
  • use the simplest guest type that fits the job
  • treat snapshots as temporary recovery, not backups

The Result

Proxmox VE has become the main compute platform behind Realm Labs.

QuanChi provides the virtualisation layer.

LXC containers host lightweight Linux services.

Virtual machines provide full operating systems where required.

Synology handles central storage.

Prometheus and Grafana provide deeper monitoring.

Home Assistant provides quick operational visibility.

The result is a flexible environment where services can be created, changed, tested and rebuilt without needing dedicated physical hardware for every project.

That is why Proxmox has become one of the foundations of Realm Labs.