Proxmox VE 9.2 VM Checklist for Post-Install Homelabs

This checklist proves a Proxmox VE 9.2 homelab host is ready for VM creation by confirming storage, network, SSH, firewall, and backup before the first guest is built. It turns a fresh install into a repeatable pass/fail record, so you can create VMs with known storage paths, bridge names, SSH access, firewall rules, and backup targets. If you have already completed the Proxmox VE 9.2 pre-install audit, this is the next pass.

Key Takeaways

• Storage: Confirm storage status, mount points, and ZFS or LVM assumptions before assigning VM disks.
• Network: Confirm the bridge, IP address, route, and SSH listener before VM traffic is created.
• Firewall: Confirm host firewall state and VM firewall defaults before exposing guest services.
• Backup: Confirm the backup target is visible and restore-testable, not merely configured.
• Readiness: A Proxmox host is ready for VMs when storage, network, SSH, firewall, and backup all pass a short command check.

What Does This Checklist Prove Before VM Creation?

A Proxmox VE 9.2 host can look healthy in the web interface while still being unsafe for VM creation. The web UI may show storage as active, but the storage may be mounted on the wrong path. A bridge may exist, but the IP route may be missing. SSH may be listening, but the firewall may allow it from the wrong network. Backup storage may be visible, but the first restore test may fail.

This checklist gives you a small, repeatable pass/fail sequence. The goal is not to install every possible Proxmox feature. The goal is to prove that the host can safely create, attach, protect, and restore a VM.

Run the short pass/fail sequence first, then drill into each area if anything fails.

pvesm status
ip -br addr
ss -tln
pve-firewall status
pvesm list pbs

If those checks pass, the host has enough visibility for a first VM. If any check fails, stop before VM creation. A failed storage check can cause disk attachment problems. A failed network check can cause VMs to start without a working bridge. A failed SSH check can block management access. A failed backup check can leave you with no tested restore path.

How to Verify Storage Before VM Creation?

Storage is the first place a homelab host can look fine but fail later. A Proxmox storage resource may appear active, but the underlying mount, pool, or LVM volume may not be ready for VM disks. The storage status check gives you the high-level view. The filesystem or ZFS check gives you the physical view.

Start with the storage status check.

pvesm status
df -h

The storage status output should show each storage resource and its status. For a homelab, you usually want at least one storage resource that can hold VM disks, such as local-lvm, local, a ZFS dataset, or a PBS datastore. The disk check should show where Proxmox is actually reading and writing files.

If your host uses ZFS, confirm the pool and dataset assumptions.

zpool status -v tank
zfs list -H -o name,used,available tank
zfs list -t snapshot | head -n 20

The pool status check should show a clean pool without severe errors. The dataset check should show the dataset you intend to use for VM disks. The snapshot check should show whether snapshots are already present, but do not treat snapshots as backup proof. A snapshot is not a tested restore path.

If your host uses LVM-Thin, confirm that the storage resource is visible and readable.

pvesm list local-lvm

This command lists files or volumes associated with the storage resource. If the storage name differs, use the actual storage name shown by the storage status check.

For a homelab, storage choice affects VM creation, backup behavior, and restore speed. The table below compares common choices without assuming every host has the same hardware.

Option	Best for	Watch out	Check type
LVM-Thin	Fast VM disks on a single Proxmox host	Thin provisioning can surprise you during restore or snapshot work	Storage status and mount visibility
ZFS	Snapshots, checksums, and local redundancy	RAM, pool health, and dataset naming matter	Pool status and dataset listing
NFS	Simple shared storage for small labs	Network latency can affect VM disk performance	Mount visibility and route check
PBS	Backup-focused storage with restore testing	Separate host or network dependency adds complexity	Backup storage visibility and restore test

The honest tradeoff is this: local ZFS is excellent for fast snapshots and local recovery, but it does not replace a tested backup target. PBS is better for backup and restore testing, but it adds another component to the homelab. If you use both, keep their roles clear. ZFS is the working storage. PBS is the tested recovery target.

How to Check Network and SSH Before VM Creation?

Network checks should happen before VM creation because the first VM inherits the host network assumptions. If the bridge is wrong, the VM may start but fail to reach the network. If the SSH listener is wrong, management access may break after the first reboot. If the route is missing, Proxmox may look reachable locally while failing from another LAN segment.

Start with the interface, bridge, and route checks.

ip -br link
ip -br addr
ip route show
cat /etc/network/interfaces

The link check should show the physical interface and any bridge. The address check should show the Proxmox host IP. The route check should show the default route. The network interfaces file should show the bridge that VMs will use, such as vmbr0.

Before creating VMs, confirm that SSH is listening and configured as expected.

ss -tln
grep -E '^(PermitRootLogin|PasswordAuthentication)' /etc/ssh/sshd_config
systemctl status sshd --no-pager

The listener check should show SSH on port 22. The SSH config check should confirm whether root login and password authentication are enabled. The service check should confirm that the SSH daemon is active.

Then test SSH from the management machine, not only from the Proxmox host itself.

ssh -o ConnectTimeout=5 [email protected]

Use the actual Proxmox host IP. This test proves the management path works from outside the host. A local SSH loopback test is not enough for a homelab if you plan to manage Proxmox from another machine.

If you use SDN zones, do not assume the default bridge is still the correct VM network. Before enabling SDN zones, see the Proxmox VE 9.2 SDN audit checklist. The basic host network check is still useful, but SDN can change how VMs attach to zones, bridges, and routing rules.

How to Confirm Firewall Defaults Before VM Creation?

Firewall checks should happen before VM creation because the first VM often exposes SSH, HTTP, DNS, or backup services. A host firewall may be enabled, but a VM firewall may be disabled. A VM firewall may be enabled, but the wrong rules may be active. A firewall rule may look correct in the web interface but fail to compile cleanly.

Start with the host firewall checks.

pve-firewall status
pve-firewall compile

The firewall status check should show whether the host firewall is enabled. The compile check should show whether the firewall configuration can be processed without errors. If the host firewall is disabled, VMs can still run, but they will not have host-level firewall protection unless the VM firewall is enabled.

A typical VM firewall config file should have a clear enable flag and a default policy. A simple example looks like this.

[OPTIONS]
enable=1
policy=IN
port=80

Do not treat this as a complete firewall rule set. It only shows the basic shape of a Proxmox firewall config. For exposed VMs, you should explicitly allow only the ports you need, such as SSH, HTTP, HTTPS, or backup access.

A common gotcha is the difference between host firewall state and VM firewall state. The host firewall can be enabled while a VM firewall is disabled. A VM can have a firewall config file but still lack a network interface attached to the correct bridge. Another gotcha is that a firewall rule may be present but not applied because the VM is running on a network that does not match the expected zone or bridge.

For exposed homelab services, keep the firewall narrow. Allow SSH from your management network only. Allow HTTP or HTTPS only from the network that needs access. Do not allow all inbound traffic because a homelab is easier to manage. A small firewall rule that fails to compile is better than a broad rule that silently opens the wrong path.

How to Prove Backup Before VM Creation?

Backup is the easiest place to have false confidence. Proxmox may show a PBS storage resource as active, but that does not prove the backup target is healthy, writable, or restore-testable. A backup job can look fine until the first restore test fails.

Start with the backup storage visibility check.

pvesm status
pvesm list pbs

The storage status check should show PBS storage as active. The PBS storage listing should show that Proxmox can see the backup target. If no PBS storage is configured, this check fails. That is not a bug. It means the host is not ready for backup-tested VM creation.

If PBS is running on a separate Proxmox Backup Server host, confirm the datastore from the PBS side.

proxmox-backup-manager datastore list

This command should show the datastore name, path, and basic health information. If PBS is remote, the Proxmox host must be able to reach the PBS host over the network. If PBS is local, the storage resource must still be visible to Proxmox.

The real backup proof is a restore test, not a backup job. A 50 GB VM backup over a 1 Gbps link can take roughly 5 to 10 minutes at around 100 MB/s, but the time is not the point. The point is whether a restore can succeed. I once had a PBS storage entry appear active in Proxmox while the Proxmox node was still pointing to an old PBS hostname. The backup looked fine until the first restore test failed. The storage status check passed, but the restore path did not.

For a homelab, a small restore test is enough. Create a tiny test VM, back it up, restore it to a test VM ID, and confirm that the restored VM can boot. If you use PBS with S3, follow the PBS 4.2 S3 restore test guide. The restore test is where backup storage becomes real.

The honest tradeoff is that PBS adds network dependency, while local snapshots are faster. PBS is better for tested recovery, offsite storage, and restore planning. Local snapshots are better for fast local rollback, but they are not a backup target unless you have a tested restore workflow.

Quick Homelab Command Checklist

Use this as the short version before creating the first VM.

pvesm status
df -h
ip -br link
ip -br addr
ip route show
ss -tln
pve-firewall status
pve-firewall compile
pvesm list pbs

If any check fails, stop before VM creation. A storage failure can affect VM disk attachment. A network failure can affect VM startup and management access. A firewall failure can expose the wrong service path. A backup failure can leave you with no tested recovery option.

For a homelab, the practical rule is simple: do not create VMs until the host can prove storage, network, SSH, firewall, and backup. The first VM is not the test. The host checks are the test.

Conclusion

This Proxmox VE 9.2 post-install checklist proves that a homelab host is ready for VM creation by checking storage, network, SSH, firewall, and backup before the first guest is built. The concrete outcome is a host with known storage paths, working bridge names, tested SSH access, clear firewall state, and a visible backup target. Your next step is to run the short command checklist, fix any failed check, and only then create the first VM.