The First 10 Changes To Make After A Fresh Proxmox VE Installation

1. Configure the Proxmox repositories

One of the first things to check is where your Proxmox host will receive package updates from. Proxmox provides different repositories depending on how the system is being used.

Enterprise repository

The Proxmox VE Enterprise repository is intended for systems with an active Proxmox subscription. Packages published here have been through additional testing and it is the recommended repository for supported production environments where stability and official support matter.

A new installation may have the Enterprise repository configured even when the server does not currently have a subscription. Without a valid subscription, package retrieval from that repository will fail.

No-subscription repository

For home labs, testing environments and self-hosters without a Proxmox subscription, the no-subscription repository is normally the appropriate choice. It provides publicly accessible Proxmox packages without requiring a subscription.

That does not make it the better option for every environment. If you are operating supported production infrastructure, use the Enterprise repository with an appropriate Proxmox subscription.

Change repositories in the web interface

1. Select your Proxmox node.
2. Open Updates.
3. Select Repositories.
4. Review the configured repositories.
5. Disable repositories you cannot use and add the appropriate repository for your environment.

Once the repositories are correct, update the package lists and bring the host fully up to date:

apt update
apt dist-upgrade

Read the package changes before accepting them, particularly on a host that has already been customised. If a kernel or other low-level system component has been updated, plan a reboot afterwards.

2. Check hostname, management IP and DNS

Networking mistakes are irritating on a standalone host. Once clustering, certificates, firewall rules and other infrastructure depend on those settings, they become much more awkward to correct. Get the basics right early, especially if you may cluster the host later.

Start by checking the configured hostname and fully qualified domain name:

hostnamectl
hostname -f

Then inspect the host mappings, interfaces and routing table:

cat /etc/hosts
ip addr
ip route

Check that:

• The management interface has the intended static IP address.
• The subnet and default gateway are correct.
• The hostname resolves to the correct management address.
• Your DNS servers are reachable.
• You are not accidentally depending on a temporary DHCP lease.

In the Proxmox interface, review System → Network for interfaces, Linux bridges, bonds and VLAN-aware configuration. Then check System → DNS and make sure the configured search domain and DNS servers match your environment.

Node names and addressing become part of a cluster's identity. Fixing a poor naming scheme before clustering is much easier than redesigning it after several nodes and services already depend on it.

3. Check time synchronisation and NTP

Correct time is easy to overlook because, most of the time, it simply works. When it does not, the resulting failures can be surprisingly difficult to diagnose.

Accurate time matters for:

• Virtualisation hosts and scheduled jobs.
• Cluster communication and distributed systems.
• Authentication and TLS certificates.
• Logs, monitoring and event correlation.
• Storage and backup schedules.

Start with:

timedatectl

Check the current time, timezone and whether the system clock is synchronised. Proxmox systems can use Chrony for NTP synchronisation, which you can inspect with:

chronyc tracking
chronyc sources -v

You should see reachable time sources and a sensible synchronisation state. A single home lab host may use public NTP servers, while larger environments often use internal time sources so that hypervisors, network equipment and other infrastructure agree on the same clock.

4. Install the HSVE Portal Agent

If you use HSVE Portal, this is a sensible point to connect the new host before you start deploying workloads. HSVE Portal can be used to centrally monitor Proxmox alongside other Linux servers and infrastructure.

The basic setup process is:

1. Open HSVE Portal.
2. Select Add Device.
3. Choose Linux.
4. Copy the generated installation command.
5. Open the Proxmox shell and run that generated command.
6. Return to Portal and verify that the host appears online.

Use the command generated for your device rather than copying a static installer command from an old article. Once the host appears online, continue with the rest of the Proxmox configuration normally.

Open HSVE Portal →

5. Install CPU microcode

Modern processors contain low-level firmware known as microcode. Intel and AMD publish microcode updates to fix processor errata, stability problems and, in some cases, security vulnerabilities.

For an Intel system:

apt install intel-microcode

For AMD:

apt install amd64-microcode

Reboot the Proxmox host after installation so the appropriate update can be loaded during startup. This is also a good time to check for BIOS or UEFI updates and server firmware updates from the hardware vendor.

That may include BMC or remote-management firmware, RAID/HBA firmware, network adapter firmware and storage device firmware. Read vendor release notes and understand the update procedure before changing firmware on an important system.

6. Review and understand the storage configuration

Before creating your first VM, understand where Proxmox is going to put it. Start with:

lsblk
df -h

If your installation uses ZFS, also run:

zpool status
zpool list

local

The local storage normally points to filesystem storage on the Proxmox host. Depending on its configured content types, it may hold ISO images, container templates, backup files and snippets.

local-lvm

Installations using LVM-thin commonly include local-lvm. This is generally intended for VM and container disks rather than ordinary file storage.

There are plenty of tutorials that immediately remove local-lvm and expand another filesystem because that layout suited the person writing the tutorial. Do not do that automatically. local-lvm is not inherently a problem; decide what storage layout makes sense for your server before changing it.

ZFS

If you selected ZFS during installation, VM and container storage may instead be backed by a ZFS pool. ZFS provides checksumming, snapshots, compression and flexible storage management, but you should understand how the pool is constructed and what happens when a physical disk fails.

At a minimum, decide where each of these will live:

• VM disks.
• LXC container disks.
• ISO images.
• Container templates.
• Backup archives.

7. Create a separate administrator account

The root@pam account is powerful and useful, particularly during initial setup and recovery. That does not mean it should be the identity used for every routine administrative action.

In the web interface, go to Datacenter → Permissions → Users and create a named account for normal administration. Grant only the permissions that account needs for its role.

In a personal lab that may still be a highly privileged account. In a shared environment, be more deliberate about separating administrators, operators and users.

Named accounts also improve auditing. If several people always log in as root@pam, an audit trail showing that root changed a VM does not tell you which administrator performed the action. Individual accounts make logs considerably more useful.

8. Enable two-factor authentication

A strong password is useful. A strong password combined with a second factor is better. Proxmox supports multiple authentication and second-factor methods; for many home labs and small environments, TOTP is the simplest place to start.

TOTP is the time-based code system used by many authenticator applications and password managers. Proxmox can also support other authentication approaches such as WebAuthn/security-key based methods depending on how your realms and environment are configured.

Whatever method you choose, understand the recovery process and keep recovery information somewhere that remains accessible if the Proxmox host itself is unavailable.

9. Secure SSH and review the Proxmox firewall

SSH is often essential for administering a Proxmox host, but it should not be treated as something that can safely be exposed everywhere with no thought given to authentication or network access.

Use SSH keys for administrative access. Once key authentication has been tested and you know you have a reliable recovery path, you can optionally restrict password authentication and direct root SSH access.

Do not blindly copy an SSH hardening configuration from another server, restart SSH and close your existing connection. Settings that are sensible in one environment can lock you out of another. Make changes deliberately and test them before ending the working session.

Understand the Proxmox firewall hierarchy

Proxmox firewall configuration can exist at several levels:

• Datacenter level — environment-wide or cluster-wide policy and rules.
• Node level — rules applying to a particular Proxmox host.
• VM/CT level — rules applying to individual virtual machines and containers.

Before enabling a restrictive policy, confirm that the management connection you are currently using will remain permitted. Consider the web interface, SSH, cluster traffic, storage networks, backup systems, monitoring, DNS and NTP as appropriate for your environment.

10. Configure notifications and backups

Configure notifications

Proxmox should be able to tell you when something has gone wrong. A failed backup job, storage problem or other event is much less useful if nobody sees the alert until weeks later.

Go to Datacenter → Notifications and configure an appropriate notification target for your environment. Once configured, send a test notification. Do not assume alerts work simply because the settings were accepted.

Configure scheduled backups

Next, go to Datacenter → Backup and create scheduled backup jobs for the VMs and containers that matter. Think about three things when building the schedule:

• Destination: where will the backup data physically live?
• Schedule: how much data could you afford to lose between backups?
• Retention: how many historical recovery points do you need?

Snapshots are not backups.

A snapshot stored on the same underlying storage does not protect you when that storage fails.

RAID is not a backup.

RAID can improve availability after a disk failure, but it does not protect you from accidental deletion, corruption, ransomware, theft or losing the entire server.

Replication is not a backup.

Replication can provide another copy of current data, but unwanted changes or corruption may also be replicated.

Store backups separately from the Proxmox host wherever possible. An external backup server, NAS or other independent storage target means a failure of the hypervisor does not automatically remove the recovery copy with it.

Consider Proxmox Backup Server

For environments with important VMs or containers, Proxmox Backup Server (PBS) is worth considering. It is designed to integrate with Proxmox and provides features including incremental backups, deduplication, verification and retention management.

Ideally, PBS should live on separate infrastructure rather than depending on the same hardware and storage it is protecting.

Final Proxmox Health Check

Once the initial configuration is complete, spend a few minutes checking the overall state of the host.

Check Proxmox package versions

pveversion -v

This lists the installed Proxmox package versions and is far more useful for troubleshooting than simply saying that the server is running Proxmox 9.

Check failed services

systemctl --failed

An empty list is what you want. Investigate failed services before putting important workloads on the host.

Check filesystem space

df -h

Pay particular attention to the root filesystem and any storage used for ISOs, backups or VM data.

Check memory

free -h

Remember that Linux deliberately uses available memory for caching. Look at the overall memory picture rather than treating a large used value as an automatic problem.

Check ZFS health

zpool status

If you use ZFS, confirm that the pool reports a healthy state, the expected devices are present and there are no unexplained errors. If you are not using ZFS, this command is not relevant and can be skipped.

For convenience, the main checks are:

pveversion -v
systemctl --failed
df -h
free -h
zpool status

What We Haven't Changed

Proxmox has plenty of other features you can configure after installation. That does not mean every feature should be enabled on every host.

We have deliberately not automatically configured:

• GPU passthrough.
• PCIe passthrough.
• IOMMU.
• VLANs.
• Software-defined networking (SDN).
• Clustering.
• Ceph.
• High availability.

These are useful when they solve an actual requirement. IOMMU makes sense when you need passthrough. VLANs make sense when your network design uses them. Ceph and high availability make sense when you have the nodes, networking, storage and operational requirements to justify the additional complexity.

Start with the simplest configuration that meets your requirements and add complexity when you know why you need it.

Conclusion

A good Proxmox installation does not need dozens of optimisation scripts or hundreds of changes. It should be simple, understood, documented, monitored and backed up.

Get the repositories right. Confirm the network and time configuration. Understand where your data lives. Secure administrator access. Configure monitoring and notifications. Most importantly, create backups and prove that you can restore them.

Once those foundations are in place, you have a much better platform on which to build the interesting parts of your home lab or infrastructure.