Commandes Proxmox VE de base avec exemples pratiques : guide d’implémentation sûr pour les opérateurs

Introduction

Ce guide propose aux opérateurs du quotidien un ensemble ciblé et sûr de commandes Proxmox VE, avec des exemples pratiques directement copiables. Il s’adresse aux développeurs, aux consultants DevOps et aux équipes techniques de startups qui ont besoin d’une routine fiable pour les vérifications de santé des nœuds, le cycle de vie des VM et des conteneurs, le stockage et les sauvegardes, la validation du cluster et de Ceph, ainsi que le dépannage rapide.

Opérez de façon conservatrice : privilégiez d’abord les vérifications en lecture seule, puis effectuez des changements réversibles et vérifiés. Testez les exemples en laboratoire ou durant une fenêtre de maintenance avant la production.

Prérequis et sécurité

Environnement : Proxmox VE 7.x ou 8.x sur des nœuds Linux ; exécution des commandes dans le shell du nœud.
Privilèges : root sur le nœud (ou sudo avec droits équivalents).
Réseau : accès shell à chaque nœud ; commandes de cluster depuis n’importe quel membre ayant quorum.
Les ID utilisés ci-dessous sont des exemples (VMID/CTID comme 100/101/200/201). Remplacez par vos ID.
Confirmez toujours l’espace libre du stockage et la santé du cluster avant toute action de cycle de vie ou de migration.
Conservez une sauvegarde récente et vérifiée avant toute opération disruptive.

Aperçu du flux de travail

Suivez cet ordre, adapté aux opérations quotidiennes :

Vérifier la santé du nœud et des services.
Dresser l’inventaire des VM et des conteneurs.
Réaliser des actions de cycle de vie sûres (arrêt propre en premier, vérifier l’état).
Contrôler la capacité de stockage et les sauvegardes.
Valider la santé du cluster et de Ceph.
Inspecter le réseau et les journaux ciblés.
Utiliser les aides API pour des rapports rapides.

Conseil : après tout changement, relancez les vérifications de santé et de stockage afin de confirmer l’état stable.

Nœuds et services

Commencez en lecture seule, puis creusez si quelque chose paraît anormal.

Version de Proxmox VE et des composants :

pveversion -v

Attendu : liste pve-manager, pve-kernel, qemu-server, lxc-pve, etc. Des versions dépareillées entre nœuds peuvent indiquer des mises à jour en attente ou partielles.

Résumé de l’état du nœud :

pvenode status

Attendu : charge CPU, mémoire utilisée, KSM, swap, uptime. Un swap élevé alors que de la RAM est libre peut indiquer un souci de swappiness ou un invité avec ballooning.

Vue d’ensemble du stockage configuré :

pvesm status

Attendu : une ligne par stockage avec total/utilisé/disponible. Si un stockage affiche unknown ou error, inspectez ce backend avant d’exécuter des sauvegardes ou des restaurations.

Services Proxmox essentiels :

systemctl status pvedaemon.service
systemctl status pveproxy.service
systemctl status pvestatd.service
systemctl status pve-cluster.service

Attendu : Active: active (running). Si pve-cluster est dégradé ou arrêté, les tâches de cluster et l’API peuvent échouer.

Journaux récents du proxy API (dernière heure) :

journalctl -u pveproxy -b --since "1 hour ago" --no-pager

Recherchez des erreurs d’écoute sur le port 8006 ou des échecs d’authentification.

Gestion des modèles LXC (lecture seule et sûre)

pveam update
pveam available
pveam list local

Utilisez available pour choisir un modèle ; list affiche ce qui est déjà téléchargé sur un stockage nommé local.

VM et conteneurs

Inventaire et état

Lister toutes les machines virtuelles QEMU :

qm list

Exemples de colonnes : VMID, NAME, STATUS, MEM, BOOTDISK, PID. Une VM en cours d’exécution affiche status running et un PID.

Vérifier l’état d’une VM spécifique (remplacez 100 par votre VMID) :

qm status 100

Attendu : status: running ou status: stopped.

Lister tous les conteneurs LXC :

pct list

Vérifier l’état d’un conteneur spécifique :

pct status 101

Exemples de cycle de vie avec arrêt propre

Privilégiez les arrêts gracieux. Vérifiez l’état après chaque action.

VM : demander un arrêt ACPI, attendre jusqu’à 60 s, puis vérifier l’état :

qm shutdown 100 --timeout 60
qm status 100

Si l’invité ignore l’ACPI, l’arrêt peut expirer. En dernier recours, durant une fenêtre de maintenance, utilisez qm stop 100 (arrêt brutal). À éviter en fonctionnement normal.

VM : démarrer et vérifier :

qm start 100
qm status 100

Conteneur : demander l’arrêt, puis vérifier :

pct shutdown 101 --timeout 60
pct status 101

Conteneur : démarrer et vérifier :

pct start 101
pct status 101

Inspecter la configuration (lecture seule) :

qm config 100
pct config 101

Vérification sûre dans l’invité pour un conteneur en cours d’exécution :

pct exec 101 -- uptime

Prudence : qm stop et pct stop sont des arrêts brutaux. Préférez shutdown, sauf si vous avez un plan de retour arrière clair et une fenêtre.

Si une VM est bloquée à cause d’un verrou obsolète après une tâche échouée, ne l’enlevez qu’après avoir confirmé qu’aucune opération disque n’est active :

qm unlock 100

Pistes en cas d’échec :

Tâche figée : consultez journalctl -xe et /var/log/syslog dans l’invité si accessible.
Verrou persistant : assurez-vous qu’aucune tâche vzdump ou de snapshot n’est en cours ; puis déverrouillez.

Comparaison des commandes de cycle de vie

Action	Quand l’utiliser	Effet	Risques/Remarques
`qm shutdown` / `pct shutdown`	Maintenance normale	Arrêt gracieux initié par l’invité	Peut expirer si les outils/ACPI de l’invité ne répondent pas
`qm stop` / `pct stop`	Urgence uniquement	Arrêt brutal (power-off)	Risque de perte de données ; à réserver aux fenêtres de changement
`qm reset`	Invité non réactif mais doit rester allumé	Redémarrage type cycle d’alimentation	Peut corrompre le FS invité si les tampons ne sont pas vidés

Stockage, sauvegarde, restauration

Vérifications de stockage

Vue Proxmox du stockage :

pvesm status

Lister les volumes d’un stockage nommé local :

pvesm list local

Espace libre au niveau OS :

df -h

Enquêtez tout stockage avec moins de 15 % d’espace libre avant de lancer des sauvegardes ou des restaurations.

Créer une sauvegarde (vzdump) et vérifier

Sauvegarder la VM 100 sur le stockage local en mode snapshot avec compression Zstandard, et une note simple :

vzdump 100 --storage local --mode snapshot --compress zstd \
  --notes-template "auto:%{date}" --mailto ""

Attendu : journal de tâche se terminant par INFO: Finished Backup of VM 100. Si le mode snapshot n’est pas pris en charge par le stockage, vzdump échoue avec un message à ce sujet.

Vérifier l’existence du fichier de sauvegarde :

ls -lh /var/lib/vz/dump/

Motifs de noms attendus : vzdump-qemu-100-YYYY_MM_DD-HH_MM_SS.vma.zst (pour les VM) ou vzdump-lxc-101-...tar.zst (pour les conteneurs).

Pannes courantes et réponses :

Espace insuffisant : libérez de l’espace sur le stockage cible ou choisissez un autre stockage avec --storage.
Snapshot non pris en charge : réessayez pendant une fenêtre avec --mode stop.
Verrou invité persistant : assurez-vous qu’aucune tâche n’est en cours, puis qm unlock 100 ou pct unlock 101 (uniquement si c’est sûr).

Restaurer une sauvegarde de VM en labo vers un nouveau VMID

Restaurez pour éviter les collisions d’ID ou d’adresses MAC. Exemple vers le VMID 200 sur le stockage local-lvm.

qmrestore /var/lib/vz/dump/vzdump-qemu-100-YYYY_MM_DD-HH_MM_SS.vma.zst 200 \
  --storage local-lvm --unique 1

--unique 1 régénère les adresses MAC et identifiants associés. Puis vérifiez :

qm list | grep "^\s*200\b"
qm start 200

Sauvegarde et restauration d’un conteneur

Sauvegarder le CT 101 :

vzdump 101 --storage local --mode snapshot --compress zstd

Restaurer la sauvegarde CT vers un nouveau CTID 201 :

pct restore 201 /var/lib/vz/dump/vzdump-lxc-101-YYYY_MM_DD-HH_MM_SS.tar.zst \
  --storage local-lvm

Comparaison des modes de sauvegarde

Mode	État de l’invité	Pré-requis	Usage typique
snapshot	En fonctionnement	Stockage supportant les snapshots (LVM-thin, ZFS, Ceph RBD)	Sauvegardes avec indisponibilité minimale
suspend	Pause l’invité	QEMU guest agent recommandé	Brève mise au repos des I/O sans arrêt complet
stop	Éteint	Fenêtre de maintenance	Quand le snapshot est indisponible ou pour une cohérence simple

Cluster et Ceph

Santé du cluster et appartenance

État du gestionnaire de cluster et quorum :

pvecm status

Attendu (extraits) : Quorum OK, nombre de nœuds, état des anneaux. Si le quorum est perdu, évitez les migrations et les changements disruptifs.

Lister les nœuds du cluster :

pvecm nodes

Affiche Nodeid, Votes, Name et l’état en ligne. Les nœuds marqués DEAD ou avec 0 vote doivent être investigués (réseau/Corosync).

Santé Ceph (si activé)

Santé Ceph de haut niveau via l’intégration Proxmox :

pveceph status

Attendu : health HEALTH_OK, comptes osd up/in, états des PG. Si la santé est WARN/ERR (ex. dégradé, PG undersized, seuil de remplissage dépassé), reportez les migrations et traitez d’abord les problèmes de stockage.

N’opérez que lorsque pvecm status indique un quorum et que pveceph status est sain.

Réseau et journaux

Vérifications réseau rapides

Interfaces (bref) :

ip -br a

Table de routage :

ip r

Écoute de l’interface Web Proxmox sur le port 8006 :

ss -lntp | grep ":8006"

Atteignabilité basique vers une passerelle :

ping -c 3 192.0.2.1

Si l’interface Web est injoignable mais que pveproxy tourne, vérifiez le pare-feu et d’éventuels reverse proxies.

Journaux ciblés pour incidents récents

journalctl -u pveproxy -b --since "30 min ago" --no-pager
journalctl -u pvedaemon -b --since "30 min ago" --no-pager
journalctl -u pve-cluster -b --since "30 min ago" --no-pager

Si vous utilisez le pare-feu Proxmox, vérifiez l’état sans modifier les règles :

pve-firewall status

Aides API avec pvesh

Utilisez le client shell intégré pour interroger l’API et produire des rapports/ scripts rapides.

Toutes les ressources du cluster (VM, conteneurs, nœuds, stockages) :

pvesh get /cluster/resources

Uniquement les VM :

pvesh get /cluster/resources --type vm

Configuration de la VM 100 depuis le nœud pve1 :

pvesh get /nodes/pve1/qemu/100/config

Conseil : explorez les endpoints avec pvesh ls / pour découvrir l’arborescence de l’API. pvesh utilise les identifiants du nœud local ; aucun jeton externe n’est requis pour des requêtes sur le nœud.

Plan pilote local

Objectif : un parcours sûr et mesurable que vous pouvez analyser localement avant toute action en production.

Baseline (lecture seule)

Exécuter : pveversion -v, pvenode status, pvesm status.
Sauvegarder les sorties dans un fichier daté pour comparaison.

Inventaire

Exécuter : qm list, pct list.
Identifier une VM non critique (ex. VMID 100) pour les tests de cycle de vie.

Cycle de vie contrôlé

Exécuter : qm shutdown 100 --timeout 60, puis qm status 100 (attendu : status: stopped).
Démarrer : qm start 100, confirmer avec qm status 100 (attendu : status: running).

Sauvegarde et vérification

Exécuter : vzdump 100 --storage local --mode snapshot --compress zstd.
Vérifier l’existence du fichier avec ls -lh /var/lib/vz/dump/ et noter sa taille.

Test de restauration en labo

Restaurer vers un nouveau VMID (ex. 200) avec qmrestore ... 200 --storage local-lvm --unique 1.
Confirmer avec qm list | grep 200 et démarrer avec qm start 200.

Vérifications du cluster et de Ceph (si applicable)

Exécuter : pvecm status, pvecm nodes et pveceph status.

Contrôle réseau express

Exécuter : ip -br a, ip r, et ss -lntp | grep :8006.

Critères de sortie :

Toutes les commandes se sont exécutées sans erreurs ; sorties capturées.
La VM test a été arrêtée proprement puis relancée et est de nouveau joignable.
Le fichier de sauvegarde existe et une restauration en labo démarre correctement.
Le cluster affiche un quorum ; Ceph est sain si utilisé.

Considérations de repli :

Si un arrêt bloque, évitez les arrêts brutaux sauf en fenêtre ; tentez d’abord un arrêt depuis l’invité.
Si une restauration entre en conflit avec des ID ou un stockage, choisissez un nouvel ID ou stockage et réessayez.
Si l’espace est faible, étendez ou libérez du stockage avant de relancer sauvegardes/restaurations.

Conclusion

Ce workflow sûr pour opérateur vous donne une routine Proxmox fiable : commencez par des vérifications en lecture seule, effectuez un changement contrôlé à la fois, vérifiez les résultats et conservez de courts journaux comparatifs. Avec les commandes et exemples ci-dessus, vous pouvez gérer sereinement les opérations quotidiennes, produire des rapports rapides via pvesh, et exécuter des sauvegardes/restaurations testées sans surprise. Une fois le pilote reproductible, standardisez-le comme runbook et étendez-le à davantage de charges à mesure que votre environnement croît.