Proxmox knowledge base
Answers to the questions Proxmox puts in front of everyone. Each entry is written to meet everyone searching for the same job in different words, not just one phrasing.
Network
- Giving a container its own address on the network: what you gain, what you pay You can publish a container by its own address instead of a port number. The gain is real and so is the price, and the second one is usually discovered after it is built.
- Understanding a server you inherited: read before you change A Proxmox you did not build has landed in your lap and you are responsible for it now. The first instinct is to change something in order to understand it, and that is exactly the thing not to do first.
- Where Docker belongs on Proxmox: the placement decision and the compose trap Where you put containers is not a matter of taste, it is a matter of blast radius. And a compose file looks like configuration when it is in fact a program you run.
- I wrote a firewall rule and nothing happens: the three level switch The Proxmox firewall is switched on at three levels, and a rule does nothing unless all three are on. The most common situation is a correct rule sitting under a switch that is off.
- How to read the network map: where does a machine’s traffic go There is a question a list view answers badly: where exactly does this machine’s traffic pass. It can be answered, but only by assembling the chain in your head every time.
- I changed the network settings and lost access: sawing the branch you sit on Network configuration is applied over the very connection you are using to apply it. A small mistake cuts the connection at the moment of applying, and without a prepared way back you need physical access.
- Separating with VLANs: one cable, several networks, and where the tag sits The point of separation is to limit how far a bad day can reach. A VLAN does this over one cable, but where the tag is applied and whether the bridge is allowed to carry tags can go wrong silently.
- A virtual machine has no network: looking in the right order Most people start the search inside the machine, which is the last place to look. The chain has four links, and the symptom tells you which one is broken.
- The audit record: the answer to "who did it", not "what happened" Monitoring tells you what happened, an audit record tells you who did it. Its value shows up on the days you hope never come, and if you do not have it that day, it never existed.
- Can you run Proxmox without the command line: the honest answer The answer is largely yes, but that is not the real point. The danger is not being unfamiliar with the command line, it is pasting a command you do not understand.
- Bonding several network cards: redundancy or speed People bond cards for two different reasons, and the two are not the same mode. Most setups actually want redundancy, but configure for throughput, and the result is disappointment.
Updates
- The container changed by itself: what the "latest" tag actually promises You updated nothing, yet the container behaves differently. That is not a fault: latest is not a version, it is a pointer. The real issue is not getting the newest, it is being able to go back.
- Before you press update: which update stops what What people who have not updated for months are afraid of is not the update, it is not knowing what will stop. Updates are not one kind of thing and their effects are nothing alike.
- Repositories and the subscription notice: the first surprise after installing On a fresh install the update fails with an authentication error and nothing is broken: the default repository is the paid one. This entry covers the repositories, the real difference between them, and the dangerous one-liner circulating on forums.
- Kernel updates: why the most dangerous update is the quietest one The kernel installs, nothing happens, everything looks normal. The danger arrives at the next boot, and that boot may be weeks away. Weeks come between cause and effect.
- Something broke after the update: "after" and "because of" are not the same A reboot is the first honest test of everything done since the last reboot. Some of what breaks was not introduced by the update, it was already there and had never been exercised.
- A major version upgrade: this is not an update, it is a migration An update replaces a part, a major upgrade replaces the family. The difference shows up in going back: you can undo an update package by package, you cannot undo a change of family.
Access
- Exposing the panel: what changes, and the path that changes the least The moment you put the panel on the internet, the login page becomes visible to everyone and automated attempts find it within hours. There are three paths, and the one that protects most never makes the panel visible at all.
- Choosing the identity source when adding a user: exists on the server, or only in the panel Proxmox knows two kinds of user: system accounts that really exist on the server, and accounts that exist only inside Proxmox. The wrong choice either blocks the login or opens more doors than needed.
- Console, shell and SSH: three separate doors into the same machine When you cannot reach a machine, the first question is which door you were using. There are three, and each depends on different things working.
- The console is a privilege: why it asks for its own permission A console looks like a screen, but it is a shell. And "can change settings" and "can open a shell" are two different powers; treating one as the other means handing out root.
- A separate key for automation instead of sharing a password: tokens and their limits Giving a script a password writes everything that person owns into a file. A token is a separate key: it can be revoked on its own, given an end date, and held to less authority than the account.
- I revoked their access but they are still inside: a session is not the same as a permission You removed the permission, you even disabled the account, and the person can still do things. Nothing is broken: revoking access and ending a session are two separate actions.
- Panel login: a password on its own is not a defence A password’s strength only means something if guessing is expensive. And the assumption that costs the most is this: "I am on the local network, I am safe".
- Giving an AI assistant access to Proxmox: where the boundary has to sit The work a model is genuinely good at, reading long logs and finding what broke, is exactly the work it is usually not allowed to do. The reason is that today the only ways in hand it root, and the risk is not bad intent, it is missing context.
- Getting off root: the decision nobody forces on you and the one that pays most Working as root does not blow up one day. It quietly breaks two things: who the record points at, and where a wrong click stops. The fix is not disabling root, it is taking the daily work off it.
- I granted permission but it does not apply: the path question in Proxmox permissions A Proxmox permission is not a role on its own. It is who, which role, and at which path, all three together. The most common problem is a role granted at the wrong point.
Virtual machines
- How many cores and how much memory for which job Sizing depends on the kind of work. A media server, a database and an AI box do not resemble each other, and giving too much is often worse than giving too little.
- A virtual machine’s processor type: why the default is slow and why host is not always right The default processor type is deliberately old so that it runs everywhere. The price is performance. The opposite end, host, gives you speed but takes away the machine’s freedom to move.
- Templates and cloning: the difference between a linked clone and a full clone A linked clone comes up in seconds but stays tied to the template. A full clone is independent but costs space and time. The difference surfaces the day you want to delete the template.
- Creating a Proxmox virtual machine in seconds instead of minutes An ISO install takes twenty minutes. With a cloud image the machine arrives ready on first boot, with its user, network name and packages already in place.
- The guest agent is enabled and still says not running Enabling the agent and installing the agent are two separate things, and doing both can still leave it off. What makes this worth chasing is not the missing IP address; it is the backup that keeps succeeding while quietly becoming less trustworthy.
- Container or virtual machine: the one sentence difference and its four consequences The choice is usually made out of resource habit. Yet the difference sits in a single sentence, and everything else follows from it.
- Choosing virtual hardware: what you show the guest decides its speed A virtual machine’s hardware is not a fact, it is a choice. Emulated old hardware is a tool for installation day, not for the machine’s lifetime.
- Why a virtual machine is slow: the processor, the disk, or overcommit Slowness has three common sources and each shows up somewhere else. Adding cores before finding the right one usually makes things worse.
- The machine will not shut down: a request is not a power switch Shutdown asks; stop pulls the plug. Everything confusing about a machine that refuses to shut down comes from that one distinction, and from the fact that a request needs somebody inside listening for it.
- What the QEMU Guest Agent is, and why your VM shows no IP The guest agent is the channel between the hypervisor and the inside of the machine. Without it the IP stays blank, shutdown requests do not land, and nothing can be said inward from the panel.
- Moved a machine from VMware and it will not boot: the disk is there, the road to it is not The most common failure after a VMware migration is not a lost disk. It is a guest that no longer recognises the controller in front of the disk, and the fix is reversible at every step if you change one thing at a time.
Backup
- How many backups to keep: the real question is not the count, it is how far back you can go Seven daily backups protect perfectly against the mistake you notice today and not at all against the damage you notice in a month. Retention is not a number, it is a decision about reach.
- The backup job stopped quietly: the costliest failure is not the loud one A backup that fails loudly gets fixed the same day. A backup that stops quietly is discovered on the day it was needed. The difference is not in a notification, it is in what you look at.
- Testing a restore: a green job is not proof Everyone knows the sentence "an untested backup is not a backup" and nobody acts on it. This entry is about what testing actually means, because a job that looks successful is not a test.
- Where backups should go: the question of what you are protecting against The backup target is not a speed decision, it is a protection decision. A backup on the same pool dies with the data when the disk goes, and most setups are in exactly that position.
- Backup modes: the interruption cost is written down, the consistency cost is not The difference between the three modes is usually explained as downtime. The real difference is consistency, and for a machine that writes constantly that difference decides whether the backup is useful at all.
Installation
- How to arrange the disks: mirroring or distributed parity The question is not which is faster. It is which failure you want to survive, and what the machine will be forced to do after that failure.
- The server's name: choose it at install time, then leave it alone The name is not a label, it is an address. Configuration lives in a folder named after it, graph files are named after it, and cluster members are known by it.
- Before you run a community script on your Proxmox host: five things to read Community scripts encode real expertise and save real hours. They are also usually run as root on the one machine you cannot afford to lose, from a single pasted line nobody read. The fix is not avoiding them, it is reading them.
- Persistent mounts: the single line that can stop a machine from booting The mount you made by hand disappears after a reboot, and making it permanent goes through a file that decides whether the machine boots. A broken line there stops not a service but the machine.
- local and local-lvm: why there are two stores and what each is for When the install finishes you see two stores with confusingly similar names, and neither name tells you what it is for. The distinction is not the technology, it is what they hold.
- The command that removes the subscription notice: the most common one-liner, the quietest damage The first thing everyone meets after installing is the subscription notice, and the first fix everyone finds is a one-line command. The common version of that command was measured: it can break the entire interface library.
- If a machine's configuration file breaks: where the old copy lives Every machine has a small text file. If it breaks, only that machine is affected, and the old copy sits in two places most people never look.
- Leaving a turnkey NAS: what you gain, and which chores quietly become yours An appliance does not mainly sell you storage. It sells you decisions already made and a maintenance calendar somebody else keeps. Both of those transfer to you on the day you move, and the second one is the part people forget.
- One box, two philosophies: should storage or virtualisation be the foundation? The question is not which product is better. It is which layer you want underneath the other, because that choice decides what you can replace later without rebuilding the whole machine.
Topology
- What the Proxmox web interface does well, and where you end up opening a second screen The native interface is not the weak part of Proxmox. It is precise, complete and honest. The friction is in one specific place: questions whose answer lives across several screens at once.
- What should the first screen of a Proxmox server tell you? Most overview screens answer "what exists". The useful question is "is anything wrong, and does it need me today". Those are different screens, and only one of them is worth opening every morning.
- Your Proxmox network has parts you never configured People search for a Proxmox topology visualizer and it sounds like a want for decoration. It is not. The link between a guest, a bridge and a physical port is stored per guest, so the only way to see a bridge is to open every guest one at a time.
- Start order is a delay, not a dependency Everyone sets start order expecting the second machine to wait until the first one is ready. It does not. It waits a fixed number of seconds and then starts regardless, which is why the order that worked in testing fails on the morning of a real power cut.
- Which physical disk is your virtual machine actually on? A list view tells you a machine uses local-lvm. It does not tell you that eight other machines use the same physical disk. That second sentence is the one that decides what a single failure costs you.
Cluster
- Why a two node cluster is the worst choice: the majority problem Buying a second server and building a cluster looks like resilience. In fact two nodes are more fragile than one: when one falls, the other can no longer make decisions.
- Adding and removing a node in a cluster: the steps with no way back Joining a cluster is not being added to a list. The joining machine’s own configuration is replaced by the cluster’s, and removal is one way.
- Configuration went read-only: why the place it lives is different If you cannot write even as root, the disk is not full. Proxmox does not keep configuration in a normal directory, and that place refuses writes on purpose.
- I built a cluster but machines will not move: what is missing is storage Building the cluster does not make machines movable. What makes migration possible is not the network but where the disk sits. And containers do not move the way virtual machines do.
- I turned on high availability but the machine still stopped: what HA really promises HA does not promise uninterrupted operation, it promises an automatic restart. The difference is a few minutes, and an expectation built without knowing those minutes ends in disappointment.
Storage
- Adding a disk and growing a pool: the step that quietly ends redundancy Adding a disk is two separate jobs: getting the system to see it, and deciding where it belongs. A mistake in the second can end redundancy for good.
- Orphaned disks: the question to ask before deleting You deleted the machine but the space did not come back. Leftover disks stay behind for three different reasons, and they are not the same. The list itself is a delete list, so its reliability is a separate matter.
- The disk is full: where the space went and what is safe to delete On a full storage the first move is not deleting but finding where the space went. Snapshots, old backups and orphaned disks are the three usual culprits, and deleting them does not carry the same risk.
- Logs: the only thing that grows without anyone deciding it should Everything that fills your disk was added by you. Except logs. And when something fails, the writing speeds up, so logs grow fastest exactly when you are least able to look.
- A snapshot is not a backup: where the difference lies and why it matters A snapshot lives on the same disk. If the disk goes, the snapshot goes with it. A backup sits somewhere else, and that is the only real difference.
- I built a software RAID, rebooted, and the storage is gone: the array is not assembled at boot The disks are fine and the data is there, but the storage is missing. What is absent is not on the disks: it is the record that tells the system to assemble the array at boot.
- ZFS or LVM: the decision made at install time that is hard to undo ZFS gives data integrity and snapshots and asks for memory in return. LVM is light and familiar but does not notice corruption on its own. The choice usually comes down to memory and expectations.
- A ZFS pool is degraded or gone: is the data lost A degraded pool does not mean lost data, it means lost redundancy. A pool that seems to have vanished has usually not been deleted either, only detached from the system.
Console and files
- The console will not open: the interface works, so why does this one thing fail A console that never connects while the rest of the interface is perfectly fine points at a small set of causes, and the most common one is a reverse proxy that forwards ordinary requests correctly and quietly refuses the connection the console actually needs.
- Getting a file into a virtual machine, when Proxmox has no file manager There is no upload button pointing into a guest, and that absence is deliberate rather than an oversight. There are four real ways in, each with a different cost, and one popular shortcut that corrupts filesystems quietly.
- Copy and paste into the console, and why your keyboard types the wrong characters The graphical console is a picture of a screen, so your clipboard does not automatically reach the other side. There is a way across, and there is a separate setting that quietly mistypes every special character until you find it.
- Why the xterm.js console is greyed out, and which console you actually want Proxmox offers more than one way into a running guest, and the one people reach for is often unavailable with no explanation. The greyed-out entry is not broken; it is waiting on two pieces of setup, one on the host and one inside the guest.
Hardware
- Heat: the fault that breaks nothing but shortens everything A server that runs too warm does not crash. It slows down and ages faster. Because it never reports an error, it goes unnoticed for years.
- Giving a graphics card to a virtual machine: the real obstacle is not the driver, it is the group Passing hardware directly to a machine is possible, but devices are handed over in groups, not one by one. And the hardware you hand over also takes away the machine’s freedom to move.
- The processor shows a hundred percent: the question to ask before reading a number Three different numbers wear the same name: the average since boot, the accumulated total, and the difference between two samples. Only the last one answers "right now".
- Memory shows ninety percent: is it full, or does it only look full Free memory is wasted memory, so a high percentage on its own is not a sign of trouble. The right question is not how full it is but who is holding it.
- The SSD lost forty percent in a year: why Proxmox wears a disk faster The disk is not faulty, the workload is different. A server disk never idles the way a desktop disk does, and every write grows layer by layer. The number to watch is not the percentage but the slope.
Monitoring
- Do you need a metrics stack, or does the built-in view already answer your question? Alerts and metrics are different tools for different questions. The built-in view answers "is something wrong now" perfectly well. A metrics stack answers "what happened last Tuesday at three", and that is the only reason to run one.
- Something happened last night: where the record actually is Alerts tell you that something happened. Logs tell you why. The catch is that the record you most need covers the moment the machine died, and on a default install that is the one most likely to be missing.
- When the watchman dies: why silence is not good news No alert email for weeks. There are two explanations, and from the outside they look identical: either everything is fine, or the watchman died.
- Alerts are configured and nothing arrives: the delivery path nobody tests Monitoring has two halves and only one of them gets set up. The check that notices the problem is the easy half. The path that carries the message to a human is the half that breaks quietly, and it breaks after it worked.
- Why you do not want every alert: alarm or summary After a bad incident the first instinct is to turn on every alert. Six weeks later you read none of them. The value of an alarm is not in ringing, it is in being read.