ProxTrace
GitHubPublic repository coming soon Open console

Who changed this VM? Proxmox VE configuration history

Proxmox VE keeps a VM’s current configuration and each node’s task history, but not the history of values: it knows that VM 104 was reconfigured on Tuesday by a given account, not that its memory went from 8 to 16 GiB. To fully answer “who changed this VM, when, and what changed”, you have to cross-check several sources, or keep the successive versions yourself.

By Pepiva Technology · Published · Updated

What Proxmox VE keeps

A VM’s configuration is a text file in “option: value” format on the cluster file system: /etc/pve/qemu-server/<VMID>.conf for a VM, /etc/pve/lxc/<CTID>.conf for a container. The file describes the present state; when a value changes, the old one is gone.

qm config 104
qm config 104 --current
qm pending 104

qm config shows the configuration with pending changes applied; --current gives the values actually in effect; qm pending shows both side by side. That helps spot a change waiting for a reboot, not what a setting was last week.

Finding who and when: the task history

Each node keeps the list of tasks it ran, with the account that started them. Filter on the VM and, if needed, on a period:

pvenode task list --vmid 104
pvenode task list --vmid 104 --userfilter john@pve
pvenode task log <UPID>

The list is per node: if the VM migrated, also look at the nodes it was on before. And not every change necessarily goes through a task: qm set describes itself as a synchronous API, with the documentation recommending the asynchronous (POST) method for hotplug and storage allocation. The task history therefore does not guarantee you will find every configuration change.

Other traces

  • The web interface and API access log, /var/log/pveproxy/access.log, records HTTP requests with their source address. You can search it for calls targeting the VM, but it does not contain the values that were sent.
  • The system journal of the Proxmox VE services, readable with journalctl -u pveproxy, completes the timeline.
  • Snapshots keep the configuration as it was when they were taken. Comparing the current state with a snapshot shows what changed since:
qm listsnapshot 104
qm config 104 --snapshot before-upgrade

A snapshot is not meant to serve as history: it takes storage space, and nobody takes one before every change.

What Proxmox VE does not do (yet)

The request is old. Bugzilla #4244, opened on 14 September 2022, asks for guest modification logs to show the old value next to the new one; a Proxmox developer found it sensible, and it is still in “NEW” status. On the forum, the question “history of actions with vm?” asked on 30 October 2024 got only a pointer to that ticket as an answer.

A “PVE Auditing System” proposal was discussed on the Proxmox developer list in January 2026: it would log who did what on which object and, as a configurable option, the object before and after the change. It was only a design discussion at the time; on 23 January 2026, a developer said on the ticket that he knew of no current work on an auditing system. As far as we know, nothing has shipped.

Keeping the history yourself

Until then, the simplest method is to copy the configuration files regularly and compare versions:

  1. copy /etc/pve/qemu-server/ and /etc/pve/lxc/ at a fixed interval to a Git repository outside the cluster, with a dated commit for each copy;
  2. when a question comes up, compare the two versions around the date: the difference gives the old and new value;
  3. cross-check with pvenode task list --vmid and the access log over the same interval to find the account and source address.

This method has three limits. It misses changes made and undone between two copies. It does not say who made a change: attribution remains a deduction, all the more fragile when several people acted during the same period. And it needs a script, storage and discipline that someone has to maintain.

Export tools such as cv4pve-report produce a full snapshot of the cluster (Excel, HTML or JSON) from the API; they make manual comparison between two dates easier, but do not track changes over time.

Investigating step by step after an incident

Example: VM 104 has been slow since Tuesday. In order:

  1. Is a change waiting for a reboot? qm pending 104 compares current and pending values.
  2. What changed? If a snapshot exists from before Tuesday, qm config 104 --snapshot <name> gives the state to compare with; otherwise, the closest Git copy.
  3. Who acted, and when? pvenode task list --vmid 104 --since <start> --until <end> on the current node, then on the nodes the VM was on before a migration. Bounds are written in seconds since the Unix epoch.
  4. A task’s details: pvenode task log <UPID>.
  5. Where did the request come from? The pveproxy access log, over the same interval, for calls targeting the VM and their source address.
  6. Record the conclusion: what changed, the old and new value, the account, the evidence for each item and what remains a deduction.

The same steps apply to a container: its file is /etc/pve/lxc/<CTID>.conf, and its ID filters the task history just like a VM’s.

What a useful history contains

To answer an auditor or close an incident, every change should be traceable with:

  • the date and time, the node and the machine concerned;
  • the field changed, its value before and its value after;
  • the account or token behind it, and the source address;
  • the task or request that carried the change, and the matching raw trace;
  • how certain the attribution is: observed, or only deduced.

With native tools, the first two points require regular copies, the others a manual cross-check of logs that are specific to each node.

Reducing the number of suspects

The fewer accounts can reconfigure a VM, the shorter the investigation. Grant modification rights only to the people who need them, on the relevant paths only, if needed with a custom role limited to the useful privileges (pveum role add). Use named accounts rather than root@pam, or the task history will never say who was behind a change. And protect critical machines against removal with qm set <VMID> --protection 1.

Why this is a security question

“Who changed this VM” is rarely asked out of curiosity. It is the question after an incident (a VM that became slow, a detached disk, an interface moved to another bridge), after an alert (the firewall disabled on an interface, protection removed) or during an audit, which asks for the record of changes over a period. Under NIS2, change management is one of the expected measures; the guide Proxmox VE and NIS2: what evidence to provide details it. The Proxmox VE security audit guide shows the other points to check on the same machine.

What ProxTrace adds

This is what ProxTrace is built for: the change history of each machine, with the value before and after.

  • Tasks, API calls, logins and logs become events linked to the node, VM or container concerned; a machine’s page shows its history.
  • Each change shows the value before and after, and the raw observation it comes from, in a panel next to the list.
  • A login is matched to an account only when the match is unique, and it is then marked “Correlated”: the tool does not guess an author.
  • An API request and the change it produces form a single event, dated to the second the configuration was written: the agent reads the modification date of the cluster configuration file (/etc/pve/qemu-server/<VMID>.conf, /etc/pve/firewall/<VMID>.fw), never its content, and re-reads the configuration less than a minute after the request. The value before and after is thus tied to the account that requested it, even when the request went through another node.
  • Filters by node, VMID, account or token, source address, operation and period.
  • A read-only agent on the nodes, which changes nothing.

The Proxmox VE change history guide presents the same approach at cluster level, and the demo shows it on sample data.

Sources