Homelab Build — Part 2 — Building the Server
With the plan from Part 1 decided, this part turns a physical box into a running Proxmox host, configured and laid out for storage the way the rest of this series will actually use it.
Confirming virtualization support and address availability before the installer runs.
Hostname, network bridge, and repositories set correctly the first time.
A deliberate split between where VM disks live and where ISOs and backups live.
What This Part Covers
Part 1 produced a plan: a domain name, a hostname prefix scheme, and an IP addressing scheme, written down before any hardware was touched. This part is where those decisions get executed for the first time — the physical server gets built, Proxmox gets installed as the hypervisor, and the host gets configured with the exact hostname and address the plan already reserved for it.
Think of this part as pouring the foundation. Every VM the rest of this series creates — the domain controllers in Part 4, the certificate authority in Part 7, the file server in Part 9 — sits on top of the hypervisor and storage layout decided here. Getting the storage split right now means never having to migrate a domain controller’s disk mid-series because it landed on the wrong pool.
lab.example.com, hypervisor hostname pve01, and the 10.10.1.0/24 management segment.
Why the Host Layer Gets Its Own Part
It is possible to install Proxmox with every default left untouched, create VMs on whatever storage the installer picked, and never think about the host again. That works right up until the single disk the installer defaulted to fills up, or a hostname typo three months in turns into a cluster-join error that is disproportionately annoying to unwind.
Proxmox itself is thoroughly documented elsewhere on this site — what it is, how it compares to other hypervisors, and the full installer walkthrough are already covered in Proxmox VE overview and Installing Proxmox VE: From ISO to First Login. This part does not repeat either. It picks up at the two decisions that are specific to building a homelab as planned infrastructure rather than a quick evaluation install: which hostname and address to give the host, and how to lay out storage before the first VM exists to complicate the decision.
Physical Build and Pre-Install Checks
Before the installer boots, confirm the two things Part 1’s planning cheat sheet flagged as worth checking on real hardware: that the CPU actually has virtualization extensions enabled, and that the address about to be assigned is not already in use. Both commands are in Part 1’s Pre-Build Verification Commands section — run egrep -c '(vmx|svm)' /proc/cpuinfo from a Linux live USB on the target hardware, and nmap -sn 10.10.1.0/24 from a device already on the network to confirm 10.10.1.5 — the address this part reserves for pve01 — is free.
Rack or place the box, connect it to the switch port that reaches the management segment, and confirm in BIOS/UEFI that Intel VT-x or AMD-V is enabled and that the boot order allows booting from USB. If the board has Secure Boot enabled and the installed Proxmox build doesn’t support it, disable it — this is covered in more detail in the installation guide’s boot-prep step.
Installing Proxmox VE
The ISO download, checksum verification, bootable media creation, and the installer’s screen-by-screen walkthrough are all covered step by step in Installing Proxmox VE: From ISO to First Login — follow that post for the mechanics. The only difference building this specific lab host is that the installer’s Management network screen gets answered with values already decided in Part 1 instead of picked on the spot:
| Installer Field | Value for This Lab | Where It Came From |
|---|---|---|
| Hostname (FQDN) | pve01.lab.example.com | Part 1’s hypervisor_prefix: pve plus the AD domain name |
| IP address | 10.10.1.5/24 | Part 1’s management segment, static reservation range .1–.20 |
| Gateway | 10.10.1.1 | Reserved as the first usable address in the management segment |
| Filesystem | ext4 for the root disk | The installation guide’s default recommendation; ZFS is added afterward as a second, dedicated pool for VM storage — see Storage Layout below |
/etc/hosts and every reference to the old name, rebooting, and is explicitly unsupported once the node has joined a cluster or holds VMs — see the official Renaming a PVE node documentation. A five-minute correction at the installer screen avoids that entirely.
Host Configuration After First Login
Once the installer finishes and the box reboots, log in to the web GUI at https://10.10.1.5:8006 and work through the same repository fix the installation guide covers — switching from the enterprise repository to no-subscription so apt update actually pulls updates. After that, two lab-specific checks are worth doing before creating any VM.
First, confirm the network bridge landed the way the installer configured it. vmbr0 is the default bridge every VM’s virtual NIC will eventually attach to, and its configuration lives in /etc/network/interfaces:
# /etc/network/interfaces — confirm this matches what the installer wrote
auto vmbr0
iface vmbr0 inet static
address 10.10.1.5/24
gateway 10.10.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
# Apply any manual edit to this file without rebooting
# (requires the ifupdown2 package, the default since Proxmox VE 7.0)
ifreload -aSecond, confirm the hostname and address are consistent everywhere the host references itself — a mismatch here is the single most common cause of confusing certificate and cluster-join errors later in the series:
# Confirm the hostname Proxmox thinks it has
hostnamectl
# Confirm /etc/hosts maps that hostname to the management IP,
# not to 127.0.0.1 or a stale address
cat /etc/hosts
# Confirm the GUI's own view of the node matches
pvesh get /nodestimedatectl and correct it with timedatectl set-ntp true if it shows unsynchronized.
Storage Layout for the Homelab
Proxmox tracks every storage location in /etc/pve/storage.cfg, and each entry declares both a storage type and which content types it’s allowed to hold — VM disk images (images), container root filesystems (rootdir), container templates (vztmpl), ISO uploads (iso), backup files (backup), and hook scripts (snippets). The installer creates one default local directory storage at /var/lib/vz for ISOs, templates, and backups, plus either an LVM-thin or ZFS pool for VM disks depending on the filesystem chosen during install.
| Storage Type | Snapshots | Thin Provisioning | Best Fit |
|---|---|---|---|
Directory (dir) | Only with qcow2 images | Only with qcow2 | ISOs, templates, backups — the role local already fills |
| LVM | No | No | Raw block performance where snapshots don’t matter |
| LVM-thin | Yes | Yes | Local VM storage on hardware without ZFS’s RAM/CPU overhead |
ZFS pool (zfspool) | Yes, native and instant | Yes | Single-node VM storage with checksums and resilience — the choice this series makes |
This series uses ZFS for the pool that holds domain controller and other VM disks, for the same reasons covered in depth in the existing ZFS on Proxmox post — checksums that catch silent corruption, and snapshots cheap enough to take before every risky change starting with the domain join in Part 4. That post covers pool creation, ashift, and compression in full; the step specific to this part is registering the pool with Proxmox as a storage target once it exists:
# Confirm the pool Proxmox already created (if ZFS was chosen at install)
# or one created manually per the ZFS on Proxmox post
zpool status
# Register (or confirm) it as a Proxmox storage target for VM images
pvesm add zfspool vmstore --pool rpool/data --content images
# List every storage target the host currently knows about, and what
# content type each one accepts
pvesm status
# Confirm the local directory storage still handles ISOs, templates, and backups
pvesm list local --content iso,vztmpl,backupimages) on the ZFS pool and everything else (iso, vztmpl, backup) on the directory storage. Mixing large ISO uploads onto the same pool that holds live VM disks makes capacity planning harder to reason about later, even though Proxmox allows either storage type to hold either content type.
Post-Build Verification Commands
Before creating the first VM in Part 4, confirm the host is in the state this part assumes: reachable at its planned address, on the correct hostname, patched, and with storage laid out as above.
# Confirm the management IP and hostname match the plan
hostnamectl
ip -4 addr show vmbr0
# Confirm packages are current against the no-subscription repository
apt update && apt dist-upgrade
# Confirm both storage targets are active and report the expected content types
pvesm status
# Confirm the ZFS pool is healthy, not just present
zpool status -xzpool status -x should return all pools are healthy. pvesm status should list both the local directory storage and the ZFS pool as active with no errors in the Total/Used/Avail columns.
Build and Host Configuration Issues
| Symptom | Likely Cause | Fix |
|---|---|---|
| Web GUI unreachable at the planned address after install | The management screen was answered with a different address, or DHCP was used instead of the planned static one. | Check the console directly on the host for the actual assigned address, then correct /etc/network/interfaces to match the plan and run ifreload -a. |
vmbr0 missing from Network in the GUI |
The installer’s bridge configuration didn’t apply, often from selecting the wrong physical NIC during install. | Confirm the correct interface name with ip link, then add the bridge-ports line pointing at it in /etc/network/interfaces. |
| Hostname doesn’t match the plan after install | A typo on the installer’s Management network screen, or the wrong FQDN entered. | Fix it now, on a fresh, empty node, following Renaming a PVE node — before Part 4 creates the first VM and the correction becomes riskier. |
pvesm add zfspool fails with “pool does not exist” |
The ZFS pool wasn’t created yet, or was created under a different name than referenced. | Run zpool status to confirm the actual pool name, and create it first per the ZFS on Proxmox post if it doesn’t exist. |
apt update still fails after switching repositories |
The enterprise repository entry wasn’t actually disabled, or the no-subscription source file has a syntax error. | Re-check both files exactly as shown in the installation guide’s repository step — the newer .sources format is strict about indentation and field names. |
Final Thoughts
None of this part is unique to a homelab — it’s the same host-build discipline any production hypervisor deployment follows, just applied to a single box instead of a fleet. The payoff shows up in Part 4 onward: creating a domain controller VM is a matter of picking the right storage target and network bridge, both of which are already named, sized, and verified.
A host with the wrong hostname, an unclear storage layout, or a bridge nobody double-checked is still usable — right up until the moment three VMs in it becomes genuinely inconvenient to fix.
Part 3 is the first thing to actually run on top of this host: pfSense goes in as a VM using the storage and bridge decided here, and turns the segments planned in Part 1 into VLANs the network enforces. See Homelab Build — Part 3 — Networking with pfSense.
pvesm status shows both the directory storage and the ZFS pool active, and that hostnamectl matches the FQDN from Part 1’s plan, before creating the first VM in Part 4.
Part 3 installs pfSense as the lab’s firewall and router: WAN/LAN interfaces, the VLANs this series’ segments map onto, and the DHCP scopes that hand out addresses outside the static reservation range set in Part 1.