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.
AtlasPVE ·
This entry answers
- proxmox guest agent not running
- proxmox guest agent not running windows
- proxmox no guest agent configured ip
- proxmox qemu guest agent is not running
- proxmox guest agent not running ubuntu
You ticked the box. You installed the package inside the machine. The panel still says the agent is not running, and the IP address column is still empty.
This one is worth being precise about, because there are three separate things that all have to be true and the interface only reports the final verdict.
Three things, not one
The option in the machine's configuration. This is the host side. It tells Proxmox VE that this guest is expected to have an agent and that it should try to talk to it.
The software inside the guest. This is a package you install in the operating system, and it has to be running as a service, not merely installed.
The virtual device that carries the conversation between them. This is the part nobody thinks about, and it is where most of these cases die.
The step almost everyone misses
Enabling the option adds a virtual device to the machine. The documentation is blunt about the consequence: a fresh start of the virtual machine is necessary for the change to take effect.
That is not the same as rebooting the operating system inside it. A device cannot appear in a machine that is already powered on, so rebooting the guest changes nothing at all: it comes back into the same virtual hardware it left. The machine has to be stopped and started.
If you have enabled the option and installed the package and it still reports nothing, this is almost always the reason. Stop the guest, start it again, and check.
On Windows
The agent for Windows guests comes from the VirtIO driver media rather than from the operating system's own package sources, which is why "install the agent" reads as a dead end for anyone who expects a normal installer to be findable.
After installing it, confirm the service is actually running. A stopped service and a missing installation look identical from the outside, and the panel reports both as the same thing.
Two spellings, both correct
Configurations in the wild carry the agent option written more than one way, because the setting grew extra sub-options over time. Both forms are valid and both enable the agent.
That matters mainly as a warning: if you find one machine written one way and another written differently, resist the urge to normalise them expecting it to fix something. It will not, and you will have spent a machine restart finding that out.
Why this is worth chasing beyond the IP address
The empty IP column is the visible symptom, and it is the least important one.
Here is what the agent is quietly doing when it works: before certain operations, Proxmox VE asks the guest to freeze its filesystems so that what gets captured is consistent. The documented list of operations is longer than most people expect, and it includes backup in snapshot mode, cloning a running machine, replicating a running machine, taking a snapshot without RAM, and importing a disk image from a running guest.
Without a working agent, those operations still run. They still report success. What changes is the guarantee: instead of a filesystem that was told to settle first, you capture one mid-write. Most of the time you get away with it. The times you do not are the times you were relying on the backup.
That is the real cost, and it is invisible. A missing IP address annoys you every day. A weaker backup says nothing until the day it matters.
One Windows caveat in the other direction
The freeze is not universally free. On Windows guests, applications that manage their own consistency through the Volume Shadow Copy Service can be disturbed by it. The documentation records a specific observed case: with some SQL Servers, issuing the freeze triggers a shadow copy path that breaks the differential backup chain.
If you run a database on Windows that keeps its own backup chain, that interaction is worth knowing about before you discover it as a gap in your restore history. It has documented workarounds, and the point here is only that "the agent is always strictly better" is not quite true.
What Atlas does
Atlas reads the same three conditions and reports them as three, not as one verdict. Knowing that the option is on but the machine has not been restarted since is a different problem from knowing that nothing is installed inside, and they have different fixes.
The daily summary is where the second half of this lands. An agent that stopped reporting is exactly the kind of thing that degrades silently: nothing breaks, backups keep completing, and the guarantee behind them quietly thins out. That is worth a line in a summary you actually read, rather than a column you stopped noticing was empty.
Sources
Proxmox's own documentation. In English, and it has the final word on this subject.