Ilango RajagopalArticlesSeriesProjectsNow
Homelab

Choose the stack, plan the addresses, install node one

September 10, 2026

The win for tonight: the stack decided and written down, an IP plan for the rack, and Proxmox running on the first M710q with its web UI open in a browser on your laptop. About two hours: twenty minutes reading and deciding, the rest at the keyboard. Nodes two and three wait for lesson 3.

Key idea —

Two of the decisions you make tonight cannot be undone cheaply. Proxmox will not let a node change its hostname or IP once it has joined a cluster, and the installer wipes whichever disk you point it at. So the plan comes first, on paper, and the install follows the plan.

1. Two ways to run three small boxes (8 min)

You have three machines and want two things from them: a Kubernetes cluster to learn on, and services that stay up. There are two sensible shapes.

Bare Ubuntu, Kubernetes on the metal. Ubuntu Server on each node, k3s on top, done. One layer fewer to learn. Every byte of the 8 GB goes to Kubernetes. The cost: the node is the cluster member. To try a different Kubernetes distribution, a different OS, or to recover from a bad upgrade, you reinstall the box with a USB stick and a monitor.

Proxmox on the metal, Kubernetes in VMs. Proxmox VE — a Debian-based hypervisor with a web UI, KVM for virtual machines and LXC for containers (admin guide) — on each node. Kubernetes runs inside VMs that Proxmox creates. The cost: one more layer, and roughly 2 GB of each node's RAM go to the host (recommended requirements). What you get: a reset button. VMs snapshot, clone, and are destroyed and recreated from a Terraform file in minutes. Breaking the cluster becomes routine instead of an evening lost.

Bare Ubuntu
Tuesday: a k3s upgrade leaves node 2 half-joined. You drive home, plug in the monitor, reinstall Ubuntu, redo the static IP, rejoin the cluster. Two hours; nothing learned that you did not already know.
Proxmox
Tuesday: the same upgrade breaks the k3s VM on node 2. From the sofa: roll the VM back to last night's snapshot, or terraform apply a fresh one. Fifteen minutes, and the broken VM is still there to read the logs from.
Same failure. The second version is why the hypervisor is worth its 2 GB — and it is also the Terraform practice the career plan asked for.

For your mission — infra depth first, Terraform practice, apps as payoff — Proxmox is the right call, and the recommendation here is Proxmox on all three nodes with k3s in VMs. The one honest argument against it is the 8 GB: Proxmox takes ~2 GB, a k3s server VM wants at least 2 GB (k3s requirements), and that leaves little for the apps. The fix is a second 8 GB DDR4-2400 SO-DIMM per node; the M710q has two slots and takes 32 GB (Lenovo PSREF). Order it this week; it does not block tonight.

2. Three facts to hold before you touch anything (5 min)

Hostname and IP are permanent. From the Cluster Manager docs: each node must be "installed with the final hostname and IP configuration", because changing either after joining the cluster is not supported. So the name and address you type into the installer tonight are the ones the node keeps.

Three nodes is the right number. Proxmox gives each node one vote and needs a majority to write to its cluster config; lose quorum and "the cluster switches to read-only mode". Three nodes survive one failure. Two do not, which is why the docs offer a QDevice for two-node setups. You bought the right count by accident.

The installer takes the whole disk. Two of your nodes have both a 256 GB SATA SSD and a 512 GB NVMe. Install Proxmox on the SATA disk on every node so all three look the same; the NVMe becomes VM storage later. The installer lists disks by device name — the SATA drive is /dev/sda, the NVMe is /dev/nvme0n1. Check the size shown next to it before you confirm.

The IP plan

Your ISP router hands out addresses by DHCP. Proxmox nodes want fixed addresses, so they live outside the DHCP pool but inside the router's subnet — same network, no VLANs yet. Step 1 below finds the real subnet and pool; until then this uses 192.168.1.0/24 as a placeholder. Correct it in the reference sheet once you know.

DeviceHostnameAddressNote
ISP router—192.168.1.1Gateway and DNS for everything
TL-SG2008sw1192.168.1.10Set in lesson 2 (ships on 192.168.0.1)
Node 1pve1192.168.1.11Tonight
Node 2pve2192.168.1.12Lesson 3
Node 3pve3192.168.1.13Lesson 3
Reserved—.20–.49VMs, later

Use home.arpa as the domain — it is the name reserved for exactly this (RFC 8375) and will never collide with a real one. So node 1 is pve1.home.arpa.

Drill: which of these can you change later without a reinstall?0 of 6

The root password

The node’s hostname

Which disk holds the OS

The node’s IP address

Which apt repository it updates from

The root filesystem (ext4 vs ZFS)

3. Hands on (90 min)

Work through these in order on your Mac and node 1. Keep a terminal open with a file called RUNBOOK.md and paste every command you actually run, with the node name — this file is what lesson 12's "rebuild in under an hour" is measured against.

Install Proxmox on node 10 of 8

  1. On the Mac, get your own address and gateway. Then log in to the ISP router (the gateway address in a browser) and find the DHCP settings page: note the start and end of the pool. Pick node addresses outside it and rewrite the IP plan above if the subnet is not 192.168.1.0/24.
    ipconfig getifaddr en0        # your IP
netstat -rn | grep default    # the gateway

    Done when: You can say the subnet, the gateway and the DHCP pool out loud, and pve1’s address is outside the pool.

  2. Get Proxmox VE 9.2-1 (1.71 GB) and compare the SHA256 on the download page with what you compute.
    shasum -a 256 ~/Downloads/proxmox-ve_9.2-1.iso

    Done when: The two hashes match character for character.

  3. The admin guide gives the macOS recipe: convert the ISO to a raw .dmg, find the stick with diskutil list, unmount it, then dd to the raw device (rdiskN, which is much faster). Triple-check N — dd does not ask twice. Etcher is the documented alternative if you prefer a GUI.
    cd ~/Downloads
hdiutil convert proxmox-ve_9.2-1.iso -format UDRW -o proxmox-ve_9.2-1.dmg
diskutil list                      # find the stick, e.g. /dev/disk4
diskutil unmountDisk /dev/diskN
sudo dd if=proxmox-ve_9.2-1.dmg bs=1m of=/dev/rdiskN status=progress

    Done when: dd finishes without error; macOS may say the disk is unreadable — that is expected, eject it.

  4. Plug node 1 into the switch, a monitor and keyboard. Power on and press F1 for Setup (the Lenovo splash screen lists the keys if these differ). Confirm Intel Virtualization Technology is enabled (Proxmox needs VT-x) and that Wake on LAN is on. Save, reboot, press F12 for the boot menu and pick the USB stick.

    Done when: The Proxmox boot menu appears. Choose "Install Proxmox VE (Graphical)"; if the screen stays black, reboot and pick the Terminal UI installer instead.

  5. Accept the EULA. Target disk: the 256 GB SATA drive (/dev/sda), not the NVMe. Leave the filesystem at ext4 (the default; ZFS later, when there is a reason). Country, timezone Asia/Kolkata, keyboard. Root password: 12+ characters, into your password manager. Email: yours. Network: hostname pve1.home.arpa, IP 192.168.1.11/24 (your real subnet), gateway and DNS both the router. Read the summary page twice. Install.

    Done when: The node reboots off the SATA disk and shows a login prompt with the URL https://192.168.1.11:8006.

  6. Unplug the monitor — you will not need it again for this node. In a browser on the Mac open https://192.168.1.11:8006, accept the self-signed certificate, log in as root with realm Linux PAM. Dismiss the "no valid subscription" dialogue; it is a notice, not an error.

    Done when: You see pve1 in the left-hand tree with a green tick, and Summary shows the CPU and 8 GB (well, ~7.7 GB) of RAM.

  7. The install ships with the enterprise repo enabled, which needs a key you do not have. Per Package Repositories, disable it and add the no-subscription one (fine for a lab; the docs say not production). The web UI can do it — node → Updates → Repositories, disable the enterprise entry, Add → No-Subscription — but do it by hand once so the runbook has the file contents.
    ssh root@192.168.1.11
echo 'Enabled: no' >> /etc/apt/sources.list.d/pve-enterprise.sources
cat > /etc/apt/sources.list.d/proxmox.sources <<EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
apt update && apt dist-upgrade -y && reboot

    Done when: apt update reports no errors, and after the reboot the web UI comes back on its own.

  8. In RUNBOOK.md: the date, the ISO version and hash, the BIOS settings you changed, the exact installer answers (disk, filesystem, hostname, IP), and the repo fix. Then the one line you will thank yourself for: what you would do differently.

    Done when: Someone with the USB stick and this file could reproduce node 1 without you.

Before you call it a night0 of 4

4. Retrieval (3 min)

No looking back.

Q1. Why does the course put Kubernetes inside VMs rather than on the metal?

Q2. What happens to a three-node Proxmox cluster when two nodes are off?

Q3. Which installer answer can you not change afterwards without a reinstall?

Q4. Why did node 1 get an address outside the DHCP pool?

The primary source for this lesson is the Installation page of the Proxmox VE wiki (the same text as chapter 2 of the admin guide, plus the LVM sizing options). Twenty minutes. Read it after the install, and notice what the installer did that you did not have to decide.