En 30 secondes : un verrou Proxmox pendant un clone sur NFS indique qu’une opération protège une VM, un disque ou un template. Il faut identifier la tâche, vérifier le stockage, contrôler la concurrence puis seulement déverrouiller si l’opération est terminée.

Comprendre pourquoi Proxmox verrouille une VM sur NFS

Proxmox place des verrous pour éviter deux écritures concurrentes sur le même objet. Pendant un clone, une sauvegarde ou une conversion de template, ce mécanisme empêche une corruption silencieuse.

Avec NFS, le problème devient plus visible. Le stockage partagé ajoute de la latence, dépend du réseau et peut ralentir fortement quand plusieurs jobs lisent le même template.

Diagnostiquer un Proxmox NFS lock sans empirer l’incident

Commencez par identifier la VM, le nœud et l’opération en cours. Une tâche encore active doit aller au bout ou être arrêtée proprement depuis l’interface.

qm status 120
qm config 120 | grep -i lock
pvesh get /nodes/$(hostname)/tasks --limit 20

Ensuite, contrôlez le stockage NFS. L’objectif est de savoir si le partage répond correctement ou si les clones attendent des opérations d’entrée-sortie trop lentes.

pvesm status
mount | grep nfs
nfsiostat 1 5
dmesg -T | grep -Ei 'nfs|timeout|stale'

Les causes fréquentes côté architecture

Les blocages apparaissent souvent quand les templates, les builds CI et les sauvegardes partagent le même export NFS. Chaque action semble légère isolément, mais leur cumul sature rapidement le serveur.

Mini-lab : tester le scénario sans risque

Travaillez sur une VM de test, un template non critique et un export NFS dédié. Ne lancez pas ce test sur le stockage qui héberge vos machines de production.

Lancez deux clones espacés de quelques secondes. Surveillez les tâches et le stockage pendant toute l’opération.

qm clone 9000 190 --name test-lock-a --full 1 --storage nfs-lab
qm clone 9000 191 --name test-lock-b --full 1 --storage nfs-lab
watch -n 2 'pvesm status; qm status 190; qm status 191'

Le résultat attendu est simple : les clones se terminent, les VM passent hors état verrouillé et NFS reste stable. Si une VM reste bloquée, documentez la tâche fautive avant d’agir.

qm config 190 | grep -i lock
qm unlock 190
qm destroy 190 --purge
qm destroy 191 --purge

Prévenir les locks dans une chaîne CI/CD Proxmox

La meilleure correction consiste à réduire la concurrence. Un runner qui lance dix builds sur un NFS moyen reproduira l’incident, même si chaque job est techniquement valide.

Ajoutez une file d’attente par template, un timeout explicite et un nettoyage garanti en fin de job. Les erreurs doivent libérer les ressources temporaires ou alerter un humain.

Erreurs courantes à éviter

Procédure de reprise quand une VM reste verrouillée

En production, l’objectif n’est pas d’aller vite. Il faut reprendre le contrôle sans perdre la trace de ce qui s’est passé.

Commencez par figer la concurrence. Stoppez les nouveaux builds, les clones planifiés et les sauvegardes non urgentes qui ciblent le même stockage.

# Exemple côté runner ou orchestrateur
# passer temporairement la concurrence à 1
export PROXMOX_BUILD_CONCURRENCY=1

# côté Proxmox : lister les tâches récentes
pvesh get /cluster/tasks --limit 50

Si la tâche est terminée mais que le lock reste présent, prenez une preuve avant toute correction. Cette trace aide à repérer une récurrence.

qm config 120 > /root/incident-vm-120-config.txt
pvesm status > /root/incident-storage-status.txt
journalctl -u pvedaemon --since "30 minutes ago" > /root/incident-pvedaemon.log

Ensuite seulement, vous pouvez déverrouiller la VM concernée. Relancez un contrôle de cohérence applicatif ou système avant de remettre les jobs en file.

qm unlock 120
qm status 120
pvesm status

Le retour à la normale doit être progressif. Relancez un seul clone, observez la latence NFS, puis augmentez la concurrence si le stockage reste stable.

Supervision minimale pour éviter la récidive

Un incident de verrouillage devient beaucoup moins coûteux quand les signaux faibles sont déjà suivis. La supervision doit couvrir Proxmox, le réseau et le serveur NFS.

Surveillez au minimum la durée des clones, le nombre de tâches actives, la latence NFS et les erreurs noyau. Ces métriques indiquent souvent le problème avant le ticket utilisateur.

Dans les petites équipes, une alerte simple vaut mieux qu’un tableau parfait jamais consulté. Déclenchez une notification quand un clone dépasse sa durée habituelle.

# Exemple de contrôle simple à intégrer dans un cron de lab
pvesh get /cluster/tasks --limit 20 | grep -Ei 'clone|backup|error|stopped'

Faut-il remplacer NFS par un autre stockage ?

Pas automatiquement. NFS reste pertinent pour des environnements modestes, des templates, des ISO ou des volumes qui ne demandent pas une très forte concurrence.

Si les builds deviennent critiques, comparez NFS avec Ceph, ZFS local répliqué ou un stockage bloc dédié. Le bon choix dépend du budget, de l’équipe et du besoin de haute disponibilité.

Le critère principal est opérationnel. Si chaque montée de charge impose un déverrouillage manuel, le stockage n’est plus aligné avec votre niveau d’automatisation.

Check-list d’exploitation après correction

Une fois le verrou levé, ne considérez pas l’incident comme terminé. Vérifiez que le clone démarre, que le disque est lisible et que le stockage revient à une latence normale.

Notez aussi l’heure, la VM concernée, le runner impliqué et la durée de blocage. Cette petite discipline transforme un incident isolé en amélioration mesurable.

Dans un contexte client, formalisez un seuil simple. Par exemple, un clone qui dépasse quinze minutes ouvre une alerte, et deux locks dans la même journée déclenchent une revue du stockage.

Ajoutez enfin un test mensuel de restauration ou de reconstruction de template. Une plateforme Proxmox fiable n’est pas seulement capable de créer des VM ; elle sait aussi récupérer proprement après un échec.

Cette approche évite les corrections héroïques. Elle donne à l’équipe une procédure répétable, compréhensible et utilisable même quand la personne qui a construit le cluster n’est pas disponible.

FAQ Proxmox NFS lock