Proxmox PulseProxmox VE 9.1 Homelab Setup Checklist: Verify Storage
Run this Proxmox VE 9.1 homelab checklist to verify updates, storage, networking, and backups before adding VMs for a stable, repeatable baseline you can trust.
On this page
A fresh Proxmox VE 9.1 install is not production-ready until you have verified updates, storage, networking, and backup paths with actual commands. This checklist turns a clean node into a stable homelab foundation by catching the common gaps before you add VMs and containers. It takes about 45 minutes on a single-node rackmount or mini-PC, and it gives you a repeatable baseline you can re-run after upgrades.
Key Takeaways
- Base system: Confirm Proxmox VE 9.1, packages, kernel, and time are current before any workload.
- Storage: Separate VM disks, ISOs, backups, and root filesystem so one full disk does not take down management.
- Networking: Pin down bridge, VLAN, firewall, and management access before containers and VMs inherit the default.
- Backup: Test a real backup job and a restore, not just the existence of a PBS storage.
- Scope: Keep the first workloads small and isolated while you validate snapshots, backups, and firewall rules.
How to verify the base system is actually current
A clean install can still be missing a kernel update, a package security fix, or a time source that will bite you later. Treat the first hour after install as a verification pass, not a workload deployment pass.
Check the Proxmox version and package state
Start by confirming the node reports Proxmox VE 9.1 and that the package database is current.
pveversion -v
apt update
apt full-upgrade -y
If the upgrade touches the kernel, restart the node before you continue.
reboot
After the node returns, run the version command again. You want to see the 9.1 series and a kernel that matches your hardware.
Make time and hostname behave
Backups, logs, and firewall rules all depend on a consistent clock and a predictable hostname.
timedatectl status
systemctl status systemd-timesyncd --no-pager
If the time service is not active, enable it.
systemctl enable --now systemd-timesyncd
Set a short hostname that will not clash if you later add a second node.
hostnamectl set-hostname proxmox-01
hostnamectl status
Decide whether to enable the firewall now
The Proxmox firewall is disabled by default. For a homelab, I usually enable it early because it forces you to think about which services are exposed.
pve-firewall status
pve-firewall enable
pve-firewall start
pve-firewall status
Keep SSH and the management UI reachable while you test. If you lock yourself out, you can still recover through the console, but it is annoying to do that with a fresh node.
What storage checks prevent the most common homelab failures?
Most early homelab pain comes from running out of space in the wrong place. The default install gives you a workable layout, but it is not a final layout.
Inspect the default storage layout
List the storage that Proxmox already knows about.
pvesm status
Then break it down by type so you can see what is usable for VMs, ISOs, and backups.
pvesm status --type dir
pvesm status --type lvmthin
pvesm status --type zfs
pvesm status --type pbs
The default directory storage is convenient, but it lives on the root filesystem. I have seen a single 120 GiB Ubuntu VM image fill the local directory and make the web UI sluggish. That is the gotcha to watch for.
Choose a homelab storage target
Use the table below to decide what each storage should do before you create your first VM.
| Check | Fresh install state | Homelab target |
|---|---|---|
| local directory | VM images can share root with the OS | ISOs and small disposable test VMs only |
| local-lvm | Thin pool on local disk | Main VM storage with explicit capacity limits |
| PBS storage | Often absent | Off-node or separate disk backup target |
| ZFS pool | Optional | Dedicated pool for VMs or NAS |
If you are building a ZFS pool for VMs or a NAS, my Proxmox NAS ZFS pool guide covers pool layout, shares, and dataset choices: Proxmox NAS: Build a ZFS Pool with SMB and NFS Shares.
Verify disk capacity and pool health
Check the physical disks and the root filesystem.
lsblk
df -h /
For LVM-thin storage, inspect the volume group and logical volumes.
vgs
lvs
For ZFS, check pool health and dataset names.
zpool status
zfs list
The honest tradeoff here is simplicity versus isolation. Local LVM-thin is fast and simple, but it keeps VM disks on the same node. If that node dies, you still need backups or replication to recover. PBS or a second node solves that, but it adds another system to manage.
How to make networking predictable before adding workloads
Networking is where a homelab starts to drift. If you do not know which bridge carries management traffic, which VLANs exist, and which firewall rules are active, your first VM will inherit a mess.
Confirm the management interface and bridge
Look at the address and link state.
ip -brief addr show
ip link show type bridge
Then review the interface file so you know what will survive a reboot.
cat /etc/network/interfaces
A typical single-node homelab bridge looks like this.
auto lo
iface lo inet loopback
auto eno1
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
If you are deciding between VLAN and VXLAN, my VLAN vs VXLAN guide covers the tradeoffs for existing bridges and new SDN zones: VLAN vs VXLAN in Proxmox VE.
Make firewall rules explicit
If you enabled the firewall in the base system pass, verify that it is still active after a reboot.
pve-firewall status
Before you add VMs, write down which ports must be reachable from your LAN: SSH, the Proxmox UI, and any management services you actually use. If you plan to add a second node later, keep management access predictable across nodes from the start.
What backup checks prove your restore path works?
A backup target in the storage list is not a backup strategy. You need a scheduled job, a completed backup, and a restore test.
Confirm a backup target exists
Check whether Proxmox has a PBS storage or another backup-capable storage.
pvesm status --type pbs
pvesm status --type dir
If you are using PBS 4.2 with S3, my PBS 4.2 S3 backup pre-flight checklist covers datastore, retention, and bandwidth checks: PBS 4.2 S3 Backup Pre-Flight Checklist for Production.
Create a scheduled job and test it
For the first test, use the local directory storage if it exists. It is not the best long-term target, but it proves the backup path.
vzdump --storage local --all --mode snapshot
If you have a PBS storage named pbs, create a daily job instead.
vzdump --storage pbs --all --mode snapshot --schedule daily --time 02:00
A 200 GiB VM with mostly static data can finish a first full backup in 10 to 20 minutes on a 1 GbE link, but the first run may be longer. Do not assume the job succeeded because the command returned quickly.
Verify a restore before trusting it
List the backups that exist.
vzdump --list local
Then restore one test VM to a new VM ID.
vzrestore --storage local 100:backup:0 --vmid 101
If the restore fails, fix the storage path, permissions, or network issue before you add real workloads. A backup you have not restored is a hope, not a plan.
Which first workloads are safe to deploy after this checklist?
Now you have a node that is current, has a defined storage plan, a known bridge, and a tested backup path. The next step is to keep the first workloads small.
Start with one management or test VM
Create one small VM and confirm it appears in the list.
qm list
After you create it, check its status.
qm status 100
Use local-lvm or ZFS for the disk if you followed the storage table. Keep the disk size modest, and confirm that the backup job picks it up.
Add containers only after backup and firewall rules are proven
Containers are convenient, but they increase the number of ports and services you need to track.
pct list
If you plan to run OCI image containers, my OCI LXC setup guide covers the tradeoffs and the basic configuration: OCI Image Containers in Proxmox VE 9.1: Setup and Tradeoffs.
Do not add a full stack of services on day one. Run one VM and one container, verify backups, verify firewall rules, and only then expand.
Conclusion
This checklist turns a fresh Proxmox VE 9.1 node into a stable homelab foundation by verifying updates, storage, networking, and backup before workloads are added. Your next step is to run the storage and backup commands on your own node, create one small test VM, and restore it before you deploy any real service.
