Qui a modifié cette VM ? L’historique de configuration Proxmox VE

Ce que Proxmox VE conserve

La configuration d’une VM est un fichier texte au format « option: valeur », dans le système de fichiers du cluster : /etc/pve/qemu-server/<VMID>.conf pour une VM, /etc/pve/lxc/<CTID>.conf pour un conteneur. Ce fichier décrit l’état présent ; quand une valeur change, l’ancienne disparaît.

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

qm config affiche la configuration avec les modifications en attente appliquées ; --current donne les valeurs effectivement en vigueur ; qm pending montre les deux côte à côte. C’est utile pour repérer un changement qui attend un redémarrage, pas pour savoir ce qui valait quoi la semaine dernière.

Retrouver qui et quand : l’historique des tâches

Chaque nœud tient la liste des tâches qu’il a exécutées, avec le compte qui les a lancées. Filtrez sur la VM et, si besoin, sur une période :

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

La liste est propre à chaque nœud : si la VM a migré, regardez aussi les nœuds où elle se trouvait avant. Et toutes les modifications ne passent pas forcément par une tâche : qm set se décrit lui-même comme une API synchrone, la documentation recommandant la méthode asynchrone (POST) pour le branchement à chaud et l’allocation de stockage. L’historique des tâches ne garantit donc pas de retrouver chaque modification de configuration.

Les autres traces

Le journal d’accès de l’interface et de l’API, /var/log/pveproxy/access.log, enregistre les requêtes HTTP avec l’adresse source. On peut y chercher les appels qui visent la VM, mais il ne contient pas les valeurs envoyées.
Le journal système des services Proxmox VE, consultable avec journalctl -u pveproxy, complète la chronologie.
Les snapshots conservent la configuration au moment où ils ont été pris. Comparer l’état actuel à un snapshot montre ce qui a changé depuis :

qm listsnapshot 104
qm config 104 --snapshot avant-maj

Un snapshot n’est pas fait pour servir d’historique : il occupe de l’espace de stockage, et on ne le prend pas avant chaque modification.

Ce que Proxmox VE ne fait pas (encore)

La demande est ancienne. Le ticket Bugzilla n° 4244, ouvert le 14 septembre 2022, demande que les journaux de modification des invités indiquent l’ancienne valeur à côté de la nouvelle ; un développeur de Proxmox l’a jugé sensé, et il est toujours au statut « NEW ». Sur le forum, la question « history of actions with vm? » posée le 30 octobre 2024 n’a reçu pour toute réponse qu’un renvoi vers ce ticket.

Une proposition de « PVE Auditing System » a été discutée sur la liste des développeurs Proxmox en janvier 2026 : elle prévoit de journaliser qui a fait quoi sur quel objet et, en option configurable, l’objet avant et après modification. Ce n’était alors qu’une discussion de conception ; le 23 janvier 2026, un développeur indiquait sur le ticket ne connaître aucun travail en cours sur un système d’audit. À notre connaissance, rien n’est livré.

Garder soi-même l’historique

En attendant, la méthode la plus simple consiste à copier régulièrement les fichiers de configuration et à comparer les versions :

copier /etc/pve/qemu-server/ et /etc/pve/lxc/ à intervalle fixe vers un dépôt Git hors du cluster, avec un commit daté à chaque copie ;
quand une question se pose, comparer les deux versions qui encadrent la date : la différence donne l’ancienne et la nouvelle valeur ;
croiser avec pvenode task list --vmid et le journal d’accès sur le même intervalle pour trouver le compte et l’adresse source.

Cette méthode a trois limites. Elle ne voit pas les changements faits puis défaits entre deux copies. Elle ne dit pas qui a modifié : l’attribution reste une déduction, d’autant plus fragile que plusieurs personnes ont agi sur la même période. Et elle exige un script, un stockage et une discipline qu’il faut maintenir.

Des outils d’export comme cv4pve-report produisent un instantané complet du cluster (Excel, HTML ou JSON) à partir de l’API ; ils facilitent la comparaison manuelle entre deux dates, mais ne suivent pas les changements dans le temps.

Enquêter pas à pas après un incident

Exemple : la VM 104 est lente depuis mardi. Dans l’ordre :

Un changement attend-il un redémarrage ? qm pending 104 compare les valeurs courantes et en attente.
Qu’est-ce qui a changé ? Si un snapshot existe d’avant mardi, qm config 104 --snapshot <nom> donne l’état de comparaison ; sinon, la copie Git la plus proche.
Qui a agi, et quand ? pvenode task list --vmid 104 --since <début> --until <fin> sur le nœud actuel, puis sur les nœuds où la VM se trouvait avant une migration. Les bornes s’écrivent en secondes depuis l’epoch Unix.
Le détail d’une tâche : pvenode task log <UPID>.
D’où venait la demande ? Le journal d’accès de pveproxy, sur le même intervalle, pour les appels qui visent la VM et leur adresse source.
Consigner la conclusion : ce qui a changé, l’ancienne et la nouvelle valeur, le compte, la preuve de chaque élément et ce qui reste une déduction.

Les mêmes étapes valent pour un conteneur : son fichier est /etc/pve/lxc/<CTID>.conf, et son identifiant filtre l’historique des tâches comme celui d’une VM.

Ce que doit contenir un historique utile

Pour répondre à un auditeur ou clore un incident, chaque changement devrait être retrouvable avec :

la date et l’heure, le nœud et la machine concernés ;
le champ modifié, sa valeur avant et sa valeur après ;
le compte ou le token à l’origine, et l’adresse source ;
la tâche ou la requête qui a porté le changement, et la trace brute correspondante ;
le degré de certitude de l’attribution : observée, ou seulement déduite.

Avec les outils natifs, les deux premiers points demandent des copies régulières, les suivants un croisement manuel de journaux propres à chaque nœud.

Réduire le nombre de suspects

Moins de comptes peuvent reconfigurer une VM, plus l’enquête est courte. Donnez les droits de modification aux seules personnes qui en ont besoin, sur les seuls chemins concernés, au besoin avec un rôle personnalisé limité aux privilèges utiles (pveum role add). Utilisez des comptes nominatifs plutôt que root@pam, sinon l’historique des tâches ne dira jamais qui était derrière. Et protégez les machines critiques contre la suppression avec qm set <VMID> --protection 1.

Pourquoi c’est une question de sécurité

« Qui a modifié cette VM » se pose rarement par curiosité. C’est la question d’après un incident (une VM devenue lente, un disque détaché, une interface passée sur un autre pont réseau), d’après une alerte (le pare-feu d’une interface désactivé, la protection retirée) ou d’un audit, qui demande la trace des changements sur une période. Pour NIS2, la gestion des changements fait partie des mesures attendues ; le guide Proxmox VE et NIS2 : quelles preuves fournir le détaille. Le guide de l’audit de sécurité Proxmox VE montre les autres points à vérifier sur la même machine.

Ce que ProxTrace ajoute

C’est la raison d’être de ProxTrace : l’historique des changements de chaque machine, avec la valeur avant et après.

Tâches, appels d’API, connexions et journaux deviennent des événements reliés au nœud, à la VM ou au conteneur concerné ; la fiche d’une machine montre son historique.
Chaque modification affiche la valeur avant et après, et l’observation brute dont elle provient, dans un panneau à côté de la liste.
Une connexion n’est rapprochée d’un compte que si la correspondance est unique, et elle est alors marquée « Corrélée » : l’outil ne devine pas un auteur.
Une demande d’API et le changement qu’elle produit forment un seul événement, daté à la seconde où la configuration a été écrite : l’agent lit la date de modification du fichier de configuration du cluster (/etc/pve/qemu-server/<VMID>.conf, /etc/pve/firewall/<VMID>.fw), jamais son contenu, et relit la configuration moins d’une minute après la demande. La valeur avant et après est donc rattachée au compte qui l’a demandée, même si la demande est passée par un autre nœud.
Filtres par nœud, VMID, compte ou token, adresse source, opération et période.
Un agent en lecture seule sur les nœuds, qui ne modifie rien.

Le guide historique des changements Proxmox VE présente la même approche à l’échelle du cluster, et la démo la montre sur des données d’exemple.