Homelab Build — Part 1 — Planning the Lab Like Real Infra

What Is Lab Planning?

Lab planning is the work you do before any hardware gets racked or any virtual machine gets created: deciding what you actually need, how things will be named, how addresses will be handed out, and how all of that gets recorded somewhere other than your memory.

Think of it like an architect’s drawings before a single brick is laid. The building can technically go up without them, but every wall added later has to guess at what came before. A homelab is the same. It can be built by improvising each step, but every VM, subnet, and hostname added without a plan makes the next one harder to place correctly.

This series builds a home lab the way real infrastructure gets built: hardware and hypervisor first, then networking, then Active Directory services layered on top one at a time. This first part is the planning phase that makes every part after it faster, because the naming and addressing decisions will already be made.

Why Plan Before You Buy or Build?

It is entirely possible to skip this step. Plenty of homelabs start with a single repurposed desktop, a default 192.168.1.0/24 network from a home router, and hostnames picked on the spot. That works fine for a weekend experiment. It stops working once the lab has a domain controller, a second site, a few VLANs, and six months of forgotten decisions behind it.

The two decisions that are genuinely expensive to change later are the Active Directory domain name and the IP addressing scheme. Renaming an AD domain after the forest exists is a disruptive, multi-step operation. Renumbering a subnet after DNS records, DHCP reservations, and firewall rules all reference it is tedious and error-prone. Both are nearly free to get right before Part 4 stands up the first domain controller, and both are painful to fix afterward.

Why Real Infrastructure Teams Plan This Way

In a production environment, nobody hands out a static IP address or creates a hostname without checking a plan first, whether that plan lives in an IPAM tool, a spreadsheet, or a wiki page. The reason is not bureaucracy. It is that infrastructure outlives the person who built it.

A homelab is a smaller version of the same problem. If you rebuild it in a year, add a second site, or hand a runbook to someone else, undocumented decisions become tribal knowledge that only lives in your head. Treating a homelab like production infrastructure from day one — even a lab with one physical host — is what makes the later parts of this series (DNS, certificates, Group Policy) buildable without re-deriving earlier decisions each time.

Hardware and Tooling to Acquire

This series assumes a single physical host running Proxmox as the hypervisor, so the hardware decision comes down to enough CPU cores with virtualization support, enough RAM to run several VMs comfortably, and SSD or NVMe storage. That decision is covered in depth in Home Lab – Hardware, and the choice of hypervisor itself is explained in KVM’s & Hypervisors — this post will not repeat either.

Beyond the host itself, plan for: a managed switch if VLANs are part of the design (Part 3 uses them for pfSense), a USB drive for installer media, and a second location to keep backups — even a homelab benefits from the 3-2-1 habit of not storing your only copy of anything on the machine that might fail.

Naming Conventions

Every host, VM, and the domain itself needs a name before it exists, not after. Getting this consistent early means every future part of the series — and every command copied from it — refers to the same names.

The domain name. Part 4 creates an Active Directory forest, and the DNS name chosen for it should follow the same guidance Microsoft gives production environments: avoid .local, since it collides with multicast DNS (mDNS) name resolution defined in RFC 6762, and avoid single-label names like lab on their own, since DNS servers cannot locate domain controllers reliably in single-label namespaces. The safest pattern for a lab is a subdomain of a domain you actually control — for example lab.example.com — even if it is never delegated publicly. This keeps the namespace collision-free and matches how a real organisation would name an internal domain relative to its registered one.

Hostnames. Windows computer names are capped at 15 characters for NetBIOS compatibility, and DNS host names may only contain letters, digits, and hyphens — no underscores, no periods within the label itself. A short prefix scheme works well for a lab this size: dc01, dc02 for domain controllers, mbr01 for a member server, cli01 for a client VM, pve01 for the Proxmox host. Keep the primary DNS suffix of every machine matching the AD domain name exactly — a mismatch here is what Microsoft calls a disjointed namespace, and it causes computers to register DNS records in the wrong zone.

IP Addressing Scheme

RFC 1918 reserves three private address ranges for exactly this kind of internal use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Any of the three works for a homelab; the choice mostly comes down to avoiding whatever range your home router already uses by default (usually somewhere in 192.168.0.0/16), so the lab network and the household network are never mistaken for each other.

For a single-site lab, one /24 per functional segment is generally enough — that is 254 usable addresses, far more than a homelab needs, but it keeps the arithmetic simple and leaves room to add a segment later without renumbering. Part 3 turns these into actual VLANs on pfSense; this section just reserves the ranges.

Documentation Before You Touch Anything

None of the decisions above are useful if they only exist in your head. A single plain-text file, checked into a personal git repo or just kept alongside the lab notes, is enough — it does not need to be a dedicated IPAM tool for a lab this size. The important part is that it exists before the first VM does, and gets updated when something changes.

network-plan.yaml below is the kind of file worth writing before Part 2 starts. It is not consumed by any tool in this series; it is a human-readable record that every later part can be checked against.

# network-plan.yaml — lab planning record, written before any hardware is touched

domain:
  ad_name: lab.example.com        # Active Directory forest/domain FQDN, chosen in Part 4
  netbios_name: LAB                # NetBIOS name, 15 characters max

naming:
  dc_prefix: dc                    # dc01, dc02
  member_prefix: mbr                # mbr01
  client_prefix: cli                # cli01
  hypervisor_prefix: pve             # pve01

addressing:
  management: 10.10.1.0/24         # Proxmox, pfSense, switch management
  servers: 10.10.10.0/24           # domain controllers, member servers
  clients: 10.10.20.0/24           # Windows client test VMs
  dmz_guest: 10.10.99.0/24         # isolated segment, Part 3

  static_reservation: .1-.20        # reserved per subnet for fixed-address infrastructure
  dhcp_range: .50-.200              # handed out by pfSense in Part 3

change_log:
  - "2026-08-24: initial plan written, before Part 2 build"

Pre-Build Verification Commands

Before buying or repurposing hardware, and before assigning the address ranges above to a physical switch, confirm the two assumptions the rest of the plan depends on: that the hardware actually supports virtualization, and that the chosen IP range is not already in use somewhere on the network.

# On an existing Windows machine, check whether Hyper-V/virtualization
# requirements are met before assuming it can run Proxmox or Hyper-V workloads
Get-ComputerInfo | Select-Object HyperVisorPresent, HyperVRequirementVMMonitorModeExtensions, HyperVRequirementVirtualizationFirmwareEnabled

# On a Linux machine (or a Linux live USB booted on the candidate hardware),
# count CPU flags indicating Intel VT-x (vmx) or AMD-V (svm) support
egrep -c '(vmx|svm)' /proc/cpuinfo

# A result of 0 means no hardware virtualization support was found —
# check BIOS/UEFI settings, since the feature is often present but disabled

# Before assigning a planned subnet to real hardware, confirm nothing already
# answers on it — run this from a machine already on the target network segment
nmap -sn 10.10.10.0/24

# If nmap is not available, a manual ping sweep confirms the same thing for
# a single address you are about to make static
ping -n 4 10.10.10.1

Planning Cheat Sheet

Planning Mistakes and Fixes

Final Thoughts

None of this is exciting work. Naming schemes and IP ranges do not demo well, and it is tempting to skip straight to installing Proxmox. But every part of this series after this one — DNS, certificates, Group Policy, monitoring — refers back to a domain name, a hostname prefix, and a subnet decided here.

Spend the hour it takes to write the plan down. The lab you build on top of it in Part 2 onward will be easier to expand, easier to explain to someone else, and easier to rebuild from scratch if it ever needs to be.