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. Installing Services on the Proxmox Host

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. Confusing Snapshots with Actual 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. Not Understanding Proxmox Storage Setup

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 VM Storage

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. Two-Node Cluster with No Quorum Device

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. Wasting Resources on Proxmox

It is very easy to give every VM more CPU and memory than it actually needs. Bigger numbers can feel safer, but over-allocating resources does not automatically make a guest faster and can leave less capacity available for the workloads that genuinely need it.

Start VMs with sensible CPU and RAM allocations, then increase them when monitoring shows a real need. Giving a lightly used VM eight or sixteen vCPUs instead of two or four can increase scheduling overhead, while allocating nearly all host memory to guests leaves the Proxmox host itself with very little breathing room.

Leave headroom for the host, storage services and workload spikes. This matters even more on ZFS systems, where unused memory can be put to work by the ARC cache.

Useful places to check include:

• Node → Summary for overall CPU and memory utilisation.
• VM → Summary for individual guest usage.
• free -h for host memory.
• top or htop for a quick view of host CPU and memory activity.

8. Not Installing/Enabling 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. Running Scripts from an Unknown Source

Community scripts can save a lot of time, and there are excellent Proxmox tools available. The problem is running code from an unknown or untrusted source 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 who published the script, where it is hosted, whether the project is actively maintained, and whether it supports your Proxmox version. Read the script where practical and understand the important changes before executing it. A copied command from a random post, comment or unknown download is not something I would run directly on a production hypervisor.

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, use sensible VM resource allocations, understand quorum before clustering and monitor the systems you depend on.

Those habits prevent a surprising number of problems later.