Virtualisation
The platform runs a mixture of LXC containers and QEMU/KVM virtual machines. Workloads are placed according to their requirements rather than forcing every service into the same deployment model.
Virtualisation & Systems Administration
A two-node Proxmox VE platform built to run the core services in my home infrastructure. This current hands-on project builds on my previous professional experience supporting VMware and Oracle VM (OVM) virtualised environments, and covers clustered virtualisation, quorum, resilient cluster networking, LXC and QEMU workloads, monitoring, automation, backup and recovery.
WHY I BUILT IT
The project grew out of consolidating infrastructure that had developed across several physical systems. Rather than simply moving those services onto another server, I used the migration to build a managed virtualisation platform.
The result is a two-node Proxmox VE cluster running DNS, monitoring, Nextcloud, network security, vulnerability scanning, container management, Zabbix and Home Assistant.
My aim has been to make the environment easier to operate, understand and recover — not simply to virtualise it.
ARCHITECTURE
Proxmox-1 and Proxmox-2 form the jameshouse-pve cluster. Corosync uses two network paths: a dedicated point-to-point Ethernet connection as the preferred cluster link and the management LAN as a lower-priority fallback.
Because this is a two-node cluster, admin-01 runs Corosync QNetd and provides an external QDevice vote. This allows the cluster to retain quorum during the loss of one Proxmox node while the QDevice remains reachable.
Corosync: dedicated link + management-LAN fallback
RUNNING THE PLATFORM
The platform runs a mixture of LXC containers and QEMU/KVM virtual machines. Workloads are placed according to their requirements rather than forcing every service into the same deployment model.
Git, Ansible and infrastructure-as-code workflows are used across the platform. Changes are validated, repeatability is checked through idempotency testing where appropriate, and rollback is considered before implementation.
Prometheus, Grafana, Loki, Alloy and Zabbix provide infrastructure and application visibility. Greenbone and the Suricata/Zeek sensor add active vulnerability assessment and passive network-security monitoring.
BACKUP & RECOVERY
Proxmox guests are protected by scheduled snapshot backups to node-specific NFS repositories on media-01. Backup archives use Zstandard compression and are retained according to the platform backup policy.
I do not treat a successful backup job as proof of recoverability. The project includes archive-integrity testing and restore validation, while remaining recovery gaps are documented rather than hidden.
Current recovery work includes extending unattended backup evidence, representative QEMU restore testing and application-consistent recovery testing for services such as Nextcloud and PostgreSQL.
IMPORTANT LIMITATION
The two Proxmox nodes currently use node-local guest storage. The cluster therefore provides common management, quorum and controlled migration capabilities, but it is not a shared-storage or replicated-disk HA platform.
Loss of a node does not mean its locally stored guests can simply restart on the surviving node. I deliberately document that boundary rather than describing the environment as highly available when it is not.
WHAT THE PROJECT DEMONSTRATES
This project applies my Linux and infrastructure operations experience to a modern virtualisation environment, building on previous professional experience supporting VMware and Oracle VM (OVM). The current platform work has involved Proxmox VE, Debian Linux, LXC, QEMU/KVM, Corosync/Kronosnet, QDevice, networking, Ansible, Git, monitoring, security, backup and recovery.
More importantly, it demonstrates how I approach infrastructure: understand how it works, automate what makes sense, monitor it, document its limitations and make sure there is a credible route to recovery.