Compute

The compute layer is built around a five-node Proxmox cluster consisting of three Minisforum MS-01 systems and two Beelink EQ14 nodes.

The goal was to create a flexible virtualization platform capable of supporting infrastructure services, application workloads, containers, development environments, automation, monitoring, media services, databases, and future AI workloads without tying individual applications directly to physical hardware.

Rather than dedicating one physical machine to one application, Proxmox provides a common compute layer where workloads can be created, rebuilt, isolated, moved, backed up, and managed independently from the underlying hardware.

This changes the role of the physical servers. Instead of each machine being identified with a specific application, the servers collectively provide compute capacity to the environment.

Proxmox VE was selected as the virtualization platform because it provides virtual machines, Linux containers, clustering, storage integration, virtual networking, backup capabilities, and centralized management within one platform.

For a home lab, this provides a strong balance between enterprise-style virtualization functionality and accessibility.

Proxmox supports both KVM-based virtual machines and Linux LXC containers, allowing the deployment model to be selected according to the workload rather than forcing every service into the same architecture.

The platform also integrates naturally with the Linux-heavy, open-source, Docker-based, and automation-focused direction of the environment.

A simpler architecture could have used several standalone Linux servers running Docker directly.

That would have worked for many application workloads, but it would have tightly coupled those applications to individual physical systems.

Proxmox introduces an infrastructure abstraction layer between hardware and applications.

Docker still plays an important role in the environment, but Docker and Proxmox solve different problems: Proxmox provides the compute virtualization layer, while Docker provides the application container layer.

VMware would have been a natural enterprise virtualization option given its long history in large corporate environments.

However, licensing and product changes within the VMware ecosystem made it less attractive for a personally funded home lab where experimentation and long-term flexibility were priorities.

Microsoft Hyper-V could also support many of the workloads, but much of the lab is centered around Linux, Docker, open-source infrastructure, automation tools, and containerized services.

Proxmox therefore aligned more naturally with the overall architecture.

The environment uses five Proxmox nodes rather than one large virtualization server.

A single powerful server would be simpler to operate but would also concentrate nearly every workload into one physical failure domain.

The multi-node architecture allows workloads to be distributed across physical systems and provides greater flexibility during maintenance, upgrades, hardware changes, and troubleshooting.

The cluster also provides hands-on experience with distributed infrastructure concepts such as cluster membership, node communication, quorum, resource placement, storage dependencies, and failure domains.

The current cluster architecture should not be confused with automatic workload high availability. Proxmox HA is planned as a future project and will be implemented only after the storage, workload, and recovery requirements are designed and tested.

Three Minisforum MS-01 systems form the primary compute tier of the environment.

The MS-01 platform provides significantly more capability than a typical mini PC while retaining a compact physical footprint and reasonable power requirements.

These systems are used for workloads that benefit from greater compute resources, higher network performance, or more demanding virtualization requirements.

The MS-01 platform also fits particularly well with the 10GbE network architecture, allowing compute workloads to communicate with storage and other infrastructure systems without being limited to a 1Gbps backbone.

Two Beelink EQ14 systems provide a secondary lightweight compute tier.

Utility services, supporting applications, test environments, lightweight containers, and smaller workloads can run efficiently on lower-power compute nodes.

This creates a tiered architecture in which workloads are placed according to actual resource requirements rather than automatically using the most powerful hardware available.

One of the most useful capabilities within Proxmox is the ability to choose between full virtual machines and Linux containers.

LXC containers provide low resource overhead, fast startup, efficient memory utilization, and strong suitability for lightweight Linux services.

Virtual machines provide a stronger abstraction boundary with an independent operating-system environment and greater flexibility for workloads requiring specialized networking, kernel behavior, operating-system control, or stronger isolation.

The virtualization model is selected according to the requirements of the workload.

Docker is used extensively throughout the environment but operates at a different layer from Proxmox.

Proxmox manages physical compute resources, virtual machines, Linux containers, host lifecycle, networking, and virtualization boundaries.

Docker manages application containers, application dependencies, service composition, and application lifecycle.

A common deployment model therefore consists of a physical Proxmox node hosting a Linux virtual machine, which then runs Docker and one or more application containers.

The Proxmox environment participates directly in the larger segmented network architecture rather than operating as an isolated virtualization island.

Workloads can be assigned to different logical network segments according to their role and security requirements.

The 10GbE SFP+ backbone is particularly valuable for virtualization because compute environments generate significant east-west traffic between hosts, storage, applications, and supporting services.

The Proxmox environment integrates with centralized storage provided by the Ubiquiti UNAS Pro.

Shared network storage allows important workload data to remain independent from individual physical compute nodes.

NFS is used to provide shared storage to virtualization workloads.

The architecture separates compute, network, and storage into distinct infrastructure layers that can evolve independently.

As the environment has grown, workload placement has become an increasingly intentional decision.

Placement can consider CPU requirements, memory consumption, storage dependencies, network requirements, workload intensity, security classification, kernel requirements, dependency relationships, and maintenance impact.

The objective is to place workloads according to their operational characteristics rather than whichever server happens to have available capacity at the moment.

Operating a multi-node Proxmox cluster introduces the concept of quorum.

Cluster members need to determine whether enough nodes remain available to make safe decisions about cluster state.

Using five nodes provides an odd-numbered membership model that supports majority-based decision making more cleanly than a cluster that can divide evenly.

The Plex environment provided a practical example of an application issue that was ultimately caused by infrastructure capacity.

The Plex virtual machine filesystem reached 100% utilization.

The virtual disk was expanded, filesystem capacity was increased, and Plex storage usage was reviewed.

This reinforced the importance of monitoring infrastructure resources independently from application availability.

Network-mounted storage introduced the requirement for reliable persistent filesystem configuration.

A mount functioning correctly during a manual test is not sufficient if applications depend on that storage following a reboot.

Persistent mount configuration therefore became part of the operational design.

Proxmox is operated as an infrastructure platform rather than as a collection of independent servers.

Cluster membership, host health, storage availability, network connectivity, workload placement, and maintenance state are treated as shared operational concerns across the five-node environment.

Routine administration includes validating node health, checking resource pressure, reviewing storage connectivity, confirming virtual-network access, and understanding which workloads depend on each host before maintenance is performed.

The goal is to make host maintenance predictable and to reduce the chance that a change to one node unintentionally affects unrelated services.

Virtual machines and LXC containers are selected according to workload requirements rather than by a single standard for every service.

Full virtual machines are preferred when a workload requires stronger isolation, its own kernel behavior, specialized networking, or more predictable compatibility.

LXC containers are used for lighter-weight Linux services where shared-kernel operation is appropriate and the lower resource overhead provides a practical benefit.

As the platform matures, repeatable base images and templates can be used to reduce manual provisioning and standardize common Linux configurations.

The WireGuard migration from an unprivileged LXC container to a dedicated Debian VM is a practical example of choosing operational reliability over minimum resource usage.

Workload lifecycle management includes provisioning, configuration, patching, restart behavior, storage dependencies, networking, backup considerations, and eventual retirement.

Before a Proxmox host is maintained, the workloads on that host are reviewed so application impact and dependencies are understood.

The multi-node architecture makes it possible to distribute workloads so maintenance does not automatically become an all-or-nothing event for the entire environment.

Persistent storage mounts and network dependencies are part of the maintenance checklist because an application is not healthy merely because its VM or container has restarted.

A key operational direction is to standardize common deployments through reusable VM templates, container baselines, Docker Compose definitions, and version-controlled configuration.

The goal is to reduce one-off builds and make it easier to recreate a workload from a known baseline.

This work connects directly to the Infrastructure as Code roadmap, where provisioning and configuration can progressively move from manual steps into repeatable definitions stored in Git.

Snapshots and backups are treated as operational tools rather than substitutes for a broader disaster-recovery strategy.

Snapshots can be useful before significant changes or upgrades, while backups protect the ability to recover a workload after corruption, failed changes, or host-level problems.

A more formal backup and disaster-recovery architecture, including retention, restore testing, and off-site protection, is intentionally being developed as a later phase of the lab roadmap.

The five-node cluster provides practical experience with quorum, node membership, cluster communication, and distributed decision making.

An odd-numbered five-node cluster provides a clear majority model when determining cluster state.

Operational maintenance therefore includes preserving healthy cluster communication and avoiding changes that would unnecessarily reduce the number of available voting members.

Proxmox High Availability is still a future project; cluster quorum and multi-node operation should not be interpreted as automatic workload failover.

The central design principle is that physical hardware should be treated as compute capacity rather than as the application itself.

Instead of thinking in terms of a Plex computer, Home Assistant computer, or DNS computer, the environment is designed around a shared compute platform hosting virtualized workloads.

As the environment matures, workloads should increasingly be defined by their requirements, dependencies, security classification, and availability needs rather than by a permanent attachment to specific hardware.