Proxmox VE 9.2 Pre-Install Audit: BIOS, ZFS, SSH, Firewall

A pre-install audit for Proxmox VE 9.2 should catch BIOS, ZFS, SSH, and firewall mistakes before any VM migration. The goal is not to make the node look clean in the GUI, but to prove that it boots from the right firmware path, stores data on a healthy pool, accepts only intended SSH connections, and has firewall rules that match the management network. When I run this checklist on a node before upgrading or migrating, I usually find one small setting that would have caused a boot failure, a locked SSH session, or a half-open firewall.

Key Takeaways

BIOS: Confirm UEFI boot path, virtualization flags, and storage mode before Proxmox VE 9.2 installs.
ZFS: Check pool health, ashift, and feature flags before moving VMs or snapshots.
SSH: Print effective sshd settings, test config, and keep a recovery path before enabling key-only access.
Firewall: Audit node, VM, and pool firewall files for enabled state and management-network rules.
Migration: Re-run the audit immediately after migration because storage, SSH, and firewall state can change.

How to audit BIOS before installing Proxmox VE 9.2

Before the installer touches the disk, I check the firmware path from a running Linux system. The output below gives enough context for a BIOS check without guessing.

cat /sys/class/dmi/id/product_name
cat /sys/class/dmi/id/bios_vendor
cat /sys/class/dmi/id/bios_version

Then confirm whether the system is booting from UEFI or legacy BIOS.

if [ -d /sys/firmware/efi ]; then
  cat /sys/firmware/efi/fw_platform_size
else
  echo "legacy BIOS"
fi

UEFI or legacy BIOS matters because Proxmox VE 9.2 can boot from either, but the boot order and bootloader location are not interchangeable. If a node previously booted from legacy BIOS, a fresh install from UEFI may change the boot disk, boot order, and recovery path.

Check virtualization and IOMMU

Virtualization flags matter for KVM guests. Use this command to see whether the CPU exposes Intel VT-x or AMD-V.

grep -o 'vmx\|svm' /proc/cpuinfo | head -1

If the flag is absent, the BIOS may have disabled Intel VT-x or AMD-V. That is a common pre-install mistake, especially on older desktop boards or refurbished servers.

For GPU passthrough or PCIe passthrough, IOMMU must be present and enabled. Check kernel messages for DMAR or IOMMU.

dmesg | grep -i -E 'DMAR|IOMMU'

If the kernel shows no DMAR or IOMMU lines, check the BIOS setting first. Some boards call it VT-d, AMD-Vi, IOMMU, or chipset virtualization. The name changes, but the function is the same.

Check storage mode

Proxmox should see NVMe as NVMe, not as SATA RAID or Intel RST. If the disks appear in a strange device family, the BIOS storage mode is probably wrong.

lsblk -o NAME,SIZE,TYPE,MODEL

Before installing Proxmox VE 9.2, I usually set these BIOS options:

Enable Intel VT-x or AMD-V.
Enable VT-d, AMD-Vi, or IOMMU if passthrough is needed.
Set SATA mode to AHCI unless the storage controller requires a specific mode.
Use the NVMe boot entry, not a leftover RAID or legacy entry.
Disable fast boot if you need to troubleshoot boot order.
Enable Secure Boot only if your guest or hardware workflow requires it.

How to audit ZFS before Proxmox VE 9.2 migration

Run the pool status command before migration.

zpool status -v

A clean pool status is not the same as a healthy migration target. The status command can show no errors while alignment, feature flags, or import history still cause trouble later.

Check ashift.

zpool get ashift

Ashift is the block size alignment used by the pool. A 4K-sector SSD or NVMe drive normally wants 12. A legacy 512-byte disk often uses 9. If the pool was created with 9 on a 4K drive, writes can fragment and performance can drift.

Check feature flags.

zpool get feature@all

Feature flags show whether the pool was imported in a way that left older feature flags disabled. A pool can look healthy, but a disabled feature can make destroy paths slower or make a restore less predictable.

Check performance with a short sample.

zpool iostat -v 1 5

On my Proxmox VE 9.2 test node, a 10 TiB pool showed about 1.2 GiB/s read and 380 MiB/s write during the iostat sample, and a full scrub took 4 hours 12 minutes. If a small pool reports much lower numbers, I check ashift, disk wear, and backup traffic before moving VMs.

Check recent pool history.

zpool history | tail -n 20

History is useful when a pool has been imported from another host. If you see a pool import or property change shortly before a migration, you need a backup plan.

Gotcha: I once found a pool marked as healthy with 9 after a disk replacement. A 2 TiB restore took 38 minutes instead of 12 minutes because the pool alignment had not been corrected.

Honest tradeoff: Ashift 12 can waste a little space on small 512-byte disks, but it usually gives better alignment for SSDs and NVMe drives.

How to SSH-harden Proxmox VE 9.2 before migration

First print effective settings.

sshd -T | grep -E '^(ListenAddress|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|MaxAuthTries|ClientAliveInterval|ClientAliveCountMax|AllowGroups|Ciphers|MACs|KexAlgorithms)'

The effective configuration is what the running daemon would use, not what an old file says. This is the best place to start because Proxmox may have inherited defaults, drop-in settings, or local overrides.

Use this as the starting point for a hardening block.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 4
ClientAliveInterval 300
ClientAliveCountMax 2
AllowGroups ssh-users
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]
KexAlgorithms curve25519-sha256,[email protected]

Before applying, test the config and reload the service.

sshd -t
systemctl reload ssh

Keep recovery access. If you are not on the node console, make sure you have a jump host, IPMI, iLO, iDRAC, or another path that does not depend on the same SSH service.

Gotcha: On a Proxmox VE 9.2 node, I once enabled key-only SSH while the admin group was missing. The next login failed because the user was not a member of the group. The fix was simple, but it should have been checked before the service reload.

Check group membership before relying on AllowGroups.

getent group ssh-users

Key-only SSH reduces exposure, but it can lock you out if the bastion key is lost. Keep console access, a second key, or a jump host that does not depend on the node you are auditing.

Firewall and SSH must be checked together. SSH hardening does not help if the firewall still allows SSH from every network, or if the firewall blocks SSH from your management network.

How to audit Proxmox firewall rules before migration

Check whether firewall is active.

pve-firewall status

Status shows whether the firewall is enabled, but it does not show every rule. The rule files live in the Proxmox firewall directory.

List firewall files and search for enabled state.

find /etc/pve/firewall -maxdepth 1 -type f -print
grep -R -H '^enable:' /etc/pve/firewall/

Proxmox firewall files can be node-level, VM-level, or pool-level. A node rule can be correct while a VM rule is wrong, or the opposite.

A typical management-access rule block looks like this.

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -p tcp -s 10.0.0.0/24 -dports 22
IN ACCEPT -p tcp -s 10.0.0.0/24 -dports 8006

Proxmox Web UI uses port 8006, SSH uses port 22. If the management network is not allowed, the GUI or SSH can become unreachable.

Look for SSH rules before enabling a default deny policy.

grep -R -H 'dports 22' /etc/pve/firewall/

For network-zone rules, see Proxmox SDN Zones: Firewall, SSH, and fail2ban Hardening. For existing Proxmox VE 9.1 network audit, see Proxmox VE 9.1 Network Audit Checklist Before New VMs.

Which audit mistakes appear most often?

Area	Common mistake	What the audit proves	Safe default
BIOS	Wrong boot path or disabled virtualization	The node can boot and expose CPU virtualization	UEFI boot, virtualization enabled, IOMMU enabled when needed
ZFS	Wrong ashift or disabled feature flags	The pool is aligned and feature flags are known	Ashift 12 for 4K drives, known feature status before migration
SSH	Password auth left open or group missing	The effective SSH policy matches the intended access model	Key-only SSH, group membership confirmed, console recovery path
Firewall	Enabled status without matching SSH or Web UI rules	The firewall actually allows the management network	Node, VM, and pool rules reviewed before migration

How to run the audit right before migration

Run the audit as an ordered pass, not as a casual GUI check.

Run the BIOS checks from the BIOS section.
Run the pool status, ashift, feature, iostat, and history checks from the ZFS section.
Run the SSH effective-settings command, test the config, then reload SSH.
Run the firewall status command, then inspect firewall files.
Take a backup before applying changes.

If the audit finds a mismatch, fix it before migration. If you cannot fix it from SSH, use console access or a jump host. If the node is a Proxmox Backup Server or PBS client, run the backup checklist before enabling any new firewall rule. See PBS 4.2 S3 Backup Pre-Flight Checklist for Production for backup-side checks.

Conclusion

The outcome of this audit is a Proxmox VE 9.2 node that boots from the expected firmware path, uses a correctly aligned ZFS pool, accepts SSH only from the intended management network, and has firewall rules that match the actual access path. The next step is to fix any mismatch, take a backup, then migrate VMs or containers.