Proxmox VE: The Setup Mistakes Nobody Warns You About

1. Exposing Proxmox directly to the internet

The Proxmox web interface normally listens on TCP port 8006. It can be tempting to forward that port through your router for remote access, but the hypervisor management plane is not something I would expose directly to the public internet.

If somebody gains administrative access to Proxmox, they are potentially gaining control of the virtual machines and containers underneath it as well.

Keep Proxmox on a trusted management network and use a VPN or another properly secured remote-access method when you need to connect from outside.

2. Turning the Proxmox host into an application server

Proxmox is built on Debian, so technically you can install normal Linux packages directly on the host. That does not mean the hypervisor should become your general-purpose application server.

Where possible, put applications inside a VM or LXC container. That gives you cleaner separation and normally makes workloads easier to back up, migrate, rebuild and troubleshoot.

There are valid exceptions, such as a deliberately installed management or monitoring agent. The goal is not to keep the host completely untouched; it is to avoid piling unrelated services onto the system everything else depends on.

3. Treating snapshots, RAID or replication as backups

Snapshots are useful for rollback before a risky update or configuration change, but they are not an independent backup. If the storage holding the VM and its snapshots fails, both can disappear together.

Snapshot ≠ Backup

RAID ≠ Backup

Replication ≠ Backup

Configure scheduled backups under Datacenter → Backup and store them separately from the host you are trying to protect. Proxmox Backup Server is a good option for environments that need a dedicated Proxmox-aware backup platform.

4. Deleting storage you do not understand

A fresh installation may show entries such as local, local-lvm or ZFS storage. You will find plenty of tutorials that immediately remove or resize parts of that layout.

That may be correct for a particular server, but understand where your VM disks, containers, ISO files, templates and backups live before changing anything.

lsblk
df -h

If you use ZFS:

zpool status
zpool list
zfs list

Review configured storage under Datacenter → Storage. Plan storage around your own hardware and requirements rather than copying somebody else's layout.

5. Over-provisioning and forgetting about real capacity

Thin provisioning lets virtual disks appear larger than the amount of physical storage currently being consumed. That flexibility is useful, but it does not create additional physical space.

As guests write more data, the underlying pool still fills up. If that storage reaches capacity, VMs can start receiving I/O errors and you may end up dealing with filesystem or data problems.

df -h
lvs

For ZFS:

zpool list
zpool status

Monitor the real storage underneath your guests and leave sensible headroom. Do not wait until a pool is at 100% before planning what comes next.

6. Building a two-node cluster without understanding quorum

Two-node Proxmox clusters can work, but creating one without understanding quorum is a common source of confusion.

Cluster nodes vote to determine whether enough of the cluster is available to safely continue making cluster-wide decisions. With only two nodes, losing communication between them creates an awkward voting situation.

A QDevice can provide an additional vote from an external system without requiring another full Proxmox node. Before creating a cluster, understand expected votes, quorum, node failure, network failure and your recovery plan.

7. Using privileged LXC containers when you do not need them

For most normal workloads, an unprivileged LXC container is the safer starting point. Root inside an unprivileged container is mapped to an unprivileged user outside the container, reducing the impact of many permission and escape problems.

Privileged containers still have valid uses, particularly where unusual hardware access, bind mounts or permissions are required. The mistake is switching to privileged mode immediately because a permissions problem is inconvenient.

Also remember that LXC containers share the host kernel. If a workload needs stronger isolation, a full VM may be the better fit.

8. Forgetting the QEMU Guest Agent

The QEMU Guest Agent improves communication between Proxmox and the operating system inside a VM. On Debian and Ubuntu guests, install it with:

apt update
apt install qemu-guest-agent

Then open VM → Options → QEMU Guest Agent in Proxmox and enable it. Depending on the guest, restart the VM or confirm that the service is running:

systemctl status qemu-guest-agent

It takes very little time to configure and is worth including in your normal VM build process.

9. Having no monitoring or notifications

Not every infrastructure problem immediately takes the whole server offline. A backup can fail, storage can slowly fill or a service can stop while everything you normally use still appears to work.

Start with Datacenter → Notifications. Configure a target you will actually see, then send a test notification.

We also use HSVE Portal to monitor Proxmox hosts alongside other infrastructure. Portal is optional; the important part is having a reliable way to know when something needs attention.

10. Blindly running scripts from the internet

Community scripts can save a lot of time, and there are excellent Proxmox tools available. The problem is running code as root on your hypervisor without knowing what it changes.

curl https://example.com/script.sh | bash

A post-install script can change repositories, packages, services, kernel parameters, networking, authentication, storage and boot settings.

Check where a script came from, read it where practical, make sure it supports your Proxmox version and understand the important changes before executing it.

Quick Proxmox health check

A few commands give you a useful overview of a host:

pveversion -v
systemctl --failed
df -h
free -h
lsblk

If you use ZFS:

zpool status

These checks do not replace proper monitoring, but they are useful after initial setup and when investigating a problem.

Final thoughts

A dependable Proxmox environment does not need to be complicated. Keep the host clean, understand your storage, keep independent backups, understand quorum before clustering, choose the right isolation for each workload and monitor the systems you depend on.

Those habits prevent a surprising number of problems later.