Category: Home Lab
Difficulty: Beginner-Intermediate
Reading Time: 14 minutes
Introduction: Why Proxmox?
At some point, every home lab builder hits the same wall. VirtualBox starts creaking under the weight of eight simultaneous VMs. VMware Workstation's networking gets tangled. The Type 2 hypervisor overhead becomes noticeable. The nagging suspicion grows that there must be a better way to do this, preferably one that does not involve selling a kidney to afford VMware vSphere licensing.
There is. It is called Proxmox Virtual Environment, and it is the open-source answer to "I want enterprise virtualisation features without the enterprise price tag." Built on Debian Linux with KVM for full virtualisation and LXC for lightweight containers, Proxmox provides a web-based management interface, clustering, snapshots, backups, software-defined networking, and an API for automation -- all completely free.
This article covers Proxmox installation, core concepts, and the essential post-install configuration that transforms a fresh Proxmox node into a properly configured lab platform. The focus is practical: what to do, why, and what to watch out for.
Why Proxmox Over the Alternatives
Before diving into installation, it is worth understanding why Proxmox has become the default recommendation for home lab hypervisors.
VMware's shifting landscape. VMware's acquisition by Broadcom and subsequent licensing changes have made the free ESXi offering uncertain. VMware Workstation Pro became free for personal use, but it remains a Type 2 hypervisor with inherent overhead. Proxmox sidesteps this entirely -- it is free, it will remain free (the code is open source under AGPL), and the paid subscription only adds support and the enterprise package repository.
KVM performance. Proxmox uses KVM (Kernel-based Virtual Machine), which is a Type 1 hypervisor integrated directly into the Linux kernel. VMs run with near-native performance, particularly for CPU-bound and I/O-bound workloads. VirtIO drivers for storage and networking provide excellent throughput.
LXC containers. Not everything needs a full VM. Linux services like DNS servers, web servers, monitoring agents, and network tools can run in LXC containers that consume a fraction of the resources of a VM. Proxmox manages both VMs and containers through the same interface.
Enterprise features, no paywall. Clustering, live migration, high availability, ZFS, Ceph storage, software-defined networking, firewall, API access, backup scheduling -- all included, all free. The only limitation of the free tier is access to the enterprise package repository (the no-subscription repository is perfectly adequate for lab use).
Installation: The Quick Version
Proxmox installation is straightforward. Download the ISO from the Proxmox website, write it to a USB drive (using Rufus, Etcher, or dd), boot from the USB, and follow the installer.
Key decisions during installation:
Target Disk and Filesystem
The installer asks for a target disk and filesystem. The options that matter:
- ext4 -- The safe default. Works on any hardware, well-understood, good performance. Choose this if unsure.
- ZFS (RAID1/RAIDZ/etc.) -- ZFS provides checksumming, compression, snapshots at the filesystem level, and built-in RAID. It is excellent if you have multiple disks and want data integrity guarantees. The downside: ZFS is a memory consumer. Budget 1GB of RAM for ZFS itself plus roughly 1GB per TB of storage for the ARC (adaptive replacement cache). On a 32GB system, this is fine. On a 16GB system, it cuts into VM allocation.
- XFS / BTRFS -- Available but less commonly used for Proxmox. XFS is solid for large files; BTRFS has snapshot capabilities but is less mature than ZFS for this use case.
For a single-disk lab system, ext4 is the pragmatic choice. For a multi-disk system where data integrity matters, ZFS RAID1 is excellent.
Network Configuration
The installer asks for network configuration: IP address, netmask, gateway, and DNS server. Use a static IP address on your home network for the Proxmox management interface. For example:
- IP Address: 10.0.0.50/24
- Gateway: 10.0.0.1
- DNS Server: 10.0.0.1
Replace these with values appropriate for your network. The management interface must be accessible from your workstation's browser.
Hostname
Set a fully qualified hostname (e.g., pve.lab.local). This matters for clustering (even single-node setups) and for SSL certificate generation.
Post-Install: Essential Configuration
A fresh Proxmox installation works, but several configuration changes make it significantly more useful for lab purposes.
Disable the Subscription Nag
On login, Proxmox displays a popup reminding you that no valid subscription is detected. This is cosmetically annoying but functionally harmless -- it does not restrict features. The community has well-documented methods for removing this popup, which can be found in Proxmox community forums and wikis.
Switch to the No-Subscription Repository
By default, Proxmox is configured to use the enterprise repository, which requires a paid subscription. Switch to the no-subscription repository for package updates:
Navigate to the node, then Updates > Repositories in the web UI. Disable the enterprise repository (pve-enterprise) and add the no-subscription repository. The web UI provides buttons to manage this directly.
Alternatively, from the shell:
# Disable enterprise repo
# Edit /etc/apt/sources.list.d/pve-enterprise.list
# Comment out the enterprise line
# Add no-subscription repo to /etc/apt/sources.list
# deb http://download.proxmox.com/debian/pve bookworm pve-no-subscriptionThen run apt update && apt dist-upgrade to bring the system current.
Enable IOMMU (for PCI Passthrough)
If the hardware supports it, enabling IOMMU allows PCI devices (network cards, GPUs, USB controllers) to be passed directly to VMs. This is not immediately necessary but is useful for advanced lab configurations such as passing a dedicated NIC to a firewall VM or a GPU to a Windows VM.
Enable IOMMU in the BIOS/UEFI (Intel VT-d or AMD-Vi), then add the appropriate kernel parameter to the bootloader configuration.
Core Concepts: VMs vs LXC Containers
Proxmox supports two types of guest: full virtual machines (KVM) and Linux containers (LXC). Understanding when to use each is key to building an efficient lab.
Virtual Machines (KVM)
VMs run a complete operating system with virtualised hardware. They are the right choice for:
- Windows guests -- there is no alternative; Windows requires a full VM
- Any non-Linux operating system (FreeBSD, specialised appliances)
- Security-sensitive workloads -- VMs provide stronger isolation than containers
- Workloads requiring specific kernel features or modules
- Malware analysis -- always use a VM, never a container
Each VM has its own kernel, its own virtual hardware, and its own resource allocation. The overhead is higher than a container, but the isolation and compatibility are comprehensive.
VirtIO drivers deserve special mention. KVM can emulate standard hardware (IDE disks, Intel E1000 network cards), but VirtIO paravirtualised drivers provide dramatically better performance. For Linux guests, VirtIO support is built into the kernel. For Windows guests, download the VirtIO driver ISO from the Proxmox website and install the drivers during or after Windows setup.
LXC Containers
LXC containers share the host kernel and run isolated Linux userspace environments. They are the right choice for:
- Linux services -- DNS, DHCP, web servers, monitoring agents, development tools
- Lightweight workloads -- a container running Pi-hole uses 50-100MB of RAM
- Rapid deployment -- containers start in seconds, not minutes
- Resource efficiency -- dozens of containers can run on hardware that would support only a handful of VMs
Proxmox provides container templates that can be downloaded directly from the web UI (local storage > CT Templates > Templates). Debian, Ubuntu, Alpine, CentOS, and other distributions are available as pre-built templates.
Containers are not appropriate for workloads requiring strong isolation (the shared kernel is a thinner boundary than a hypervisor), Windows, or anything that requires a different kernel version or kernel modules not present on the host.
The Practical Guideline
Run your analysis VMs (Kali, SIFT, REMnux, Windows) as KVM virtual machines. Run your infrastructure services (DNS, DHCP, monitoring dashboards, documentation wikis, reverse proxies) as LXC containers. This maximises resource efficiency while maintaining appropriate isolation.
Storage: Where Your VMs Live
Proxmox supports multiple storage backends, and understanding them is essential for lab planning.
Local Storage
The default after installation. Proxmox creates a local storage for ISOs, container templates, and backups, and a local-lvm storage (LVM-thin) for VM disks and container rootfs volumes.
LVM-thin is a thin-provisioned logical volume manager. A 500GB thin pool can host VMs whose combined allocated disk space exceeds 500GB, because thin provisioning only consumes space as it is written. This is ideal for labs where many VMs are created but not all run simultaneously.
ZFS
If ZFS was selected during installation (or added afterwards), it provides:
- Compression -- transparent compression (LZ4 by default) saves disk space with negligible performance impact
- Snapshots -- near-instant, space-efficient snapshots at the filesystem level
- Checksumming -- every block is checksummed, detecting and (with redundancy) correcting data corruption
- Clone from snapshot -- create a writable copy of a snapshot instantly, using no additional space until blocks diverge
ZFS is excellent for lab use. The ability to snapshot a VM, run an experiment, and roll back in seconds is invaluable.
NFS/SMB Shares
Network storage can be added for ISOs, backups, and VM disks. This is useful for centralising ISO libraries or backup storage on a NAS. Performance for VM disks over NFS depends heavily on network speed and NAS capability -- gigabit Ethernet is adequate, 10GbE is comfortable.
Adding Storage
Storage is managed via Datacenter > Storage in the web UI. Click Add and select the type. For a basic lab, the default local and local-lvm storage is sufficient. Add NFS for ISO storage and backups if a NAS is available.
Networking: Building Your Lab Infrastructure
Networking is where Proxmox's flexibility truly shines, and where a lab setup diverges from a simple "install VMs and go" approach.
Default Networking
After installation, Proxmox creates a Linux bridge called vmbr0 that is connected to the physical network interface. VMs and containers attached to vmbr0 receive IP addresses from the home network's DHCP server and are directly accessible on the LAN.
This is fine for the Proxmox management interface and for VMs that need to be on the home network (e.g., a Pi-hole DNS server). It is emphatically not fine for lab VMs that should be isolated.
Creating an Isolated Lab Network
The goal is a second virtual network, isolated from the home LAN, where lab VMs can communicate with each other and (optionally) reach the internet, but cannot reach home network devices.
Step 1: Create a New Bridge
Navigate to the Proxmox node, then System > Network > Create > Linux Bridge.
- Name:
vmbr1 - IPv4/CIDR:
10.10.10.1/24 - Autostart: Yes
- Comment: Lab network (isolated)
Do not assign a gateway. Do not bridge this to a physical interface. This creates an internal-only virtual switch.
Step 2: Set Up NAT for Internet Access
If lab VMs need internet access (for package updates, tool downloads, or threat intelligence feeds), configure NAT (masquerade) on the Proxmox host. This allows lab VMs to reach the internet via the host's connection while remaining isolated from the home LAN.
Add masquerade rules to the Proxmox host's network configuration. The key elements are:
# In /etc/network/interfaces, under the vmbr1 configuration:
# post-up: iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
# post-down: iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
# Also enable IP forwarding:
# post-up: echo 1 > /proc/sys/net/ipv4/ip_forward
# post-down: echo 0 > /proc/sys/net/ipv4/ip_forwardApply the network configuration (or reboot the node).
To restrict lab VMs from reaching your home LAN while allowing internet access, add a blocking rule before the masquerade:
# Block lab network from reaching home LAN (adjust subnet to match your network)
# iptables -I FORWARD -s 10.10.10.0/24 -d 10.0.0.0/24 -j DROPStep 3: DHCP for Lab VMs
Lab VMs need IP addresses. Install dnsmasq on the Proxmox host to provide DHCP and DNS for the lab network:
apt install dnsmasqConfigure dnsmasq to listen only on the lab bridge. Create a configuration file (e.g., /etc/dnsmasq.d/lab-network.conf):
interface=vmbr1
bind-interfaces
dhcp-range=10.10.10.100,10.10.10.200,12h
dhcp-option=option:router,10.10.10.1
dhcp-option=option:dns-server,10.10.10.1Restart dnsmasq and verify it is serving DHCP on the lab bridge.
Step 4: Assign VMs to the Lab Network
When creating a VM or container, select vmbr1 as the network bridge instead of vmbr0. The guest will receive an IP in the 10.10.10.0/24 range and will be isolated from the home LAN.
VLANs
For more complex segmentation (separating attack VMs from analysis VMs, or creating multiple isolated environments), Proxmox supports VLAN tagging. VMs can be assigned a VLAN tag on their network interface, and a VLAN-aware bridge will handle the segmentation.
To make a bridge VLAN-aware, enable the "VLAN aware" checkbox on the bridge configuration. Then assign VLAN tags to individual VM network interfaces. VMs with different VLAN tags on the same bridge cannot communicate directly -- a router or firewall VM with interfaces in both VLANs is required for inter-VLAN traffic.
This is useful for creating separate lab segments: an "attack" VLAN, a "target" VLAN, and a "monitoring" VLAN, with a pfSense or OPNsense VM routing and firewalling between them.
VM Templates and Cloning: Work Smarter
One of Proxmox's most powerful features for lab use is the ability to create templates and clone them rapidly. Instead of installing Kali Linux from scratch every time a clean VM is needed, create a template once and clone it in seconds.
Creating a Template
- Install and configure a VM -- install the OS, apply updates, install guest tools (QEMU Guest Agent), and configure baseline settings
- Clean up -- remove SSH host keys (so clones generate unique keys), clear bash history, remove temporary files
- Convert to template -- right-click the VM in the Proxmox UI and select "Convert to Template"
- Kali Linux template -- fully updated, guest agent installed, common tools verified
- Ubuntu Server template -- minimal install, updated, guest agent, SSH configured
- Windows 10/11 template -- evaluation ISO installed, VirtIO drivers, Sysinternals, analysis tools
- Debian minimal template -- for LXC containers and lightweight VMs
- Infrastructure as Code -- define lab environments in configuration files and deploy them programmatically
- Rapid deployment -- scripts to spin up entire lab scenarios (domain controller, workstations, attacker VM, monitoring stack) in minutes
- Integration with tools -- Ansible, Terraform (via the community Proxmox provider), and custom scripts can manage Proxmox resources
- Terraform with the
telmate/proxmoxprovider can define VMs, containers, and network resources declaratively - Ansible with the
community.general.proxmoxmodules can manage VMs, containers, and configuration - Proper shutdown -- Proxmox can request a graceful shutdown instead of pulling the virtual power cord
- Filesystem freeze -- consistent snapshots and backups by freezing the filesystem before snapshotting the disk
- IP address reporting -- the guest's IP address is displayed in the Proxmox summary panel
- Time synchronisation -- the host can synchronise the guest's clock
- Manual backups -- right-click a VM or container, select Backup
- Scheduled backups -- configure under Datacenter > Backup to run automatically
- Backup modes -- Snapshot (no downtime), Suspend (brief pause), Stop (clean but with downtime)
- Compression -- ZSTD compression provides a good balance of speed and ratio
- Storage -- backups can target local storage, NFS shares, or Proxmox Backup Server
- Install Proxmox, switch to the no-subscription repository, and update
- Understand when to use VMs (Windows, security-sensitive, full OS) versus containers (Linux services, lightweight)
- Configure an isolated lab network with vmbr1, NAT for internet access, and dnsmasq for DHCP
- Create templates and use linked clones for rapid VM deployment
- Use the API for automation as the lab matures
- Back up your templates -- future-you will be grateful
A template cannot be started or modified. It exists solely as a source for clones.
Cloning
Two types of clone are available:
Full Clone: Creates a complete, independent copy of the template's disk. The clone is entirely self-contained. Uses more disk space but has no dependency on the template.
Linked Clone: Creates a copy-on-write clone that references the template's disk. Only blocks that differ from the template consume additional space. This is dramatically faster and more space-efficient but depends on the template remaining intact. Ideal for lab environments where many similar VMs are needed temporarily.
Practical Templates to Create
With templates prepared, deploying a new lab environment becomes a matter of minutes rather than hours.
API Access: Automation for the Ambitious
Proxmox exposes a comprehensive REST API that enables programmatic management of the entire platform. Every action available in the web UI can be performed via the API.
Why This Matters
API access enables:
API Authentication
Proxmox supports two authentication methods for API access:
API Tokens: Created in Datacenter > Permissions > API Tokens. An API token is tied to a user and can optionally have the same permissions as the user or reduced privileges. Tokens use the format user@realm!tokenname with a UUID secret.
Username/Password: Standard authentication with username and password, receiving a ticket (session cookie) and CSRF token in response.
API tokens are preferred for automation, as they do not require storing passwords in scripts and can be revoked independently.
Example: Listing VMs
# Using curl with an API token
curl -s -H "Authorization: PVEAPIToken=your-user@pam!your-token=your-token-uuid" \
https://your-proxmox-ip:8006/api2/json/nodes/your-node/qemuReplace the placeholder values with actual credentials. The API returns JSON, making it easy to parse with jq or process in Python.
Terraform and Ansible
For more structured automation:
These tools transform lab management from manual clicking to repeatable, version-controlled infrastructure definitions.
Enabling the QEMU Guest Agent
The QEMU Guest Agent is a small daemon that runs inside VMs, enabling the Proxmox host to communicate with the guest OS. It provides:
To enable: install qemu-guest-agent in the guest (Linux) or the VirtIO guest tools (Windows), then enable the "QEMU Guest Agent" option in the VM's Options tab in the Proxmox UI.
This is a small step that improves the management experience significantly.
Backup Strategy: Because Labs Are Not Disposable
It is tempting to treat a lab as throwaway, but the hours invested in configuring tools, building templates, and setting up complex environments make backups worthwhile.
Proxmox includes built-in backup functionality:
At minimum, back up your templates. They represent the most time investment and are the most painful to recreate.
Conclusion: Your Lab, Your Rules
Proxmox transforms commodity hardware into a capable virtualisation platform that rivals commercial offerings costing thousands in licensing. It provides the foundation for a cybersecurity lab that can grow from a handful of VMs on a single node to a clustered environment running dozens of guests across multiple machines.
The key takeaways:
The next step is to start deploying VMs from the lists covered in the previous article and building out a lab environment that matches your learning goals. Whether that is a penetration testing range, a DFIR analysis platform, a SOC monitoring stack, or all of the above, Proxmox provides the infrastructure to make it happen.
Now go build something. The web UI is waiting at port 8006.
Tech Corsair -- navigating the digital seas so you don't have to.
