Référence des opérations Proxmox VE (Version 9.1.2)
Les nœuds, les invités et les services peuvent tomber en panne, devenir inaccessibles ou disparaître en cours d'opération. Ne supposez jamais qu'un composant est actif : ré-interrogez l'état réel, réessayez avec un délai d'attente et dégradez gracieusement. Pour les modèles d'auto-guérison, voir bitranox:coding-resilience.
1. Configuration du cluster (détection automatique)
| Vérification | Commande |
|---|---|
| Environnement | pveversion --verbose (versions complètes des composants : noyau, pve-manager, corosync, qemu-server) |
| Nœuds | pvecm nodes (nombre, noms, ID) / pvecm status (IP, quorum, transport, états des liens) |
| Quorum | pvecm status -- vérifier le champ « Quorate ». Seuil : floor(total_nodes/2) + 1 |
| Accès API | pvesh (CLI local), pveproxy (HTTPS :8006), API REST. Utiliser --output-format json pour les scripts |
| Stockage | pvesm status (stockages actifs) / cat /etc/pve/storage.cfg (configuration complète) |
| Réseau | pvesh get /nodes/{node}/network --output-format json / cat /etc/network/interfaces |
| Abonnement | pvesubscription get (vérifier le statut) / pvesubscription set <key> (appliquer la clé) |
2. Protocoles de sécurité
| Règle | Détails |
|---|---|
| Pas d'opérations destructrices en masse | Les commandes affectant plus d'un nœud (redémarrage, arrêt, arrêt en masse des VM) nécessitent une confirmation explicite de l'utilisateur. |
| Vérification du quorum | Avant le redémarrage/la maintenance d'un nœud : pvecm status. Si (current - 1) < floor(total/2) + 1 -- annuler. Sur les clusters à 2 nœuds, vérifier le QDevice. |
| Sauvegarder d'abord | Avant des modifications de configuration de VM ou des mises à niveau, vérifier l'existence d'une sauvegarde : pvesm list {storage} --content backup |
| Pas de suppression forcée | Ne jamais utiliser --purge ou --force sans vérifier l'ID de la ressource : qm config {vmid} ou pct config {vmid} |
| État HA | Avant des modifications de ressources HA : ha-manager status -- vérifier qu'aucune migration/barrière n'est en cours. |
| Modifications réseau | Toujours faire un essai à sec d'abord : ifreload -a -n (ifupdown2 n'a pas de --test). Ne jamais faire ifdown sur un pont transportant le trafic des invités. Application à distance et pièges DHCP/bond/WLAN : references/host-networking.md. |
| Configuration Corosync | Copier d'abord, modifier la copie, sauvegarder la configuration actuelle, puis déplacer. Toujours incrémenter config_version. |
| Opérations de stockage | Avant de supprimer un stockage : pvesm list {storage} pour vérifier qu'aucune VM/CT n'y fait référence. |
| Drapeau de protection | qm set {vmid} --protection 1 / pct set {vmid} --protection 1 pour empêcher la suppression accidentelle. |
| Opérations sur les propriétés ZFS | PVE stocke la taille de disque configurée d'un invité comme refquota du dataset. Une opération qui efface refquota/refreservation sur tous les datasets supprime silencieusement la limite de disque de chaque invité alors que pct config rapporte toujours l'ancienne taille, de sorte qu'un conteneur peut remplir le pool. Exclure les noms de feuilles commençant par subvol- ou vm-. |
3. Protocole d'examen des actions
Obligatoire. Effectuer cet examen avant chaque action exécutée directement sur un nœud Proxmox, une VM ou un conteneur (commandes, modifications de configuration, opérations de service).
Exception : Les opérations en lecture seule - lecture de journaux, interrogation de l'état, collecte d'informations sans rien modifier - sont considérées comme sûres et peuvent être effectuées immédiatement sans cet examen.
Exécuter cette porte sur
opus. Ce jugement « steelman / red-team » conditionne une modification de l'infrastructure EN PRODUCTION - un modèle plus faible sous-estime les risques de panne, de perte de données et de quorum. Effectuer l'examen suropus: le déléguer à un sous-agentopusépinglé avec un effortmedium(examen de la répartition, voirbitranox:process-agents-subagent-driven-development« Review dispatches »), ou (si vous le gardez en ligne) proposerswitch-model-or-continueAVANT l'exécution. Ne jamais exécuter cette porte sur un modèle inconnu de niveau inférieur. Voirbitranox:process-agents-subagent-driven-development(« The session model is fixed » / « Concrete tiers »).
3.1 Prompt Steelman
Considérez l'action ou la configuration planifiée devant être exécutée sur le serveur Proxmox dans sa forme idéale et la plus réussie. Imaginez que cette action représente la solution la plus sûre, la plus efficace et la mieux intégrée. Exprimez comment cette action remplit parfaitement les objectifs de l'administration système, augmente la stabilité et répond pleinement aux besoins de l'utilisateur.
3.2 Prompt Red-Team
Examinez l'action Proxmox planifiée comme si vous étiez un administrateur expérimenté ou un analyste de sécurité cherchant à découvrir des risques potentiels. Identifiez les faiblesses possibles de la configuration, tenez compte des risques de panne, de perte de données ou d'effets secondaires imprévus. Testez la robustesse du plan dans des scénarios pessimistes pour garantir qu'il reste sûr et fiable même sous pression.
3.3 Décision
À la fin de l'examen red-team, évaluez si les risques ou faiblesses identifiés sont suffisamment graves pour arrêter l'action planifiée. Si l'action semble sûre, logique et robuste, elle peut être exécutée immédiatement. Si des incertitudes significatives subsistent, l'utilisateur doit être explicitement invité à confirmer. Conclure par une décision claire : soit « Exécuter l'action » soit « Demander confirmation à l'utilisateur ».
4. Style de code et de réponse
- Réponses : Courtes, précises, orientées CLI (
pvesh,pvecm,pvesm,qm,pct,ha-manager,vzdump,pvesr,pvenode,pveceph,pveum,pveam). - Dépannage : Toujours interroger les journaux en premier :
journalctl -u pvedaemon -n 50,pvenode task list --errors 1,/var/log/pveproxy/access.log. - Préférence JSON : Utiliser
--output-format jsonoujson-pretty. Utiliser--noborder --noheaderpour l'analyse scriptée. - Plan de retour arrière : Chaque modification doit inclure un plan de retour arrière. Sauvegarder d'abord les fichiers de configuration. S'assurer que les sauvegardes existent avant les modifications de stockage/VM.
5. Tableau rapide de la taille du cluster
| Taille | Comportement |
|---|---|
| Nœud unique | Pas d'opérations de cluster. Pas de HA. Se concentrer sur le stockage local + les sauvegardes externes. |
| 2 nœuds | QDevice fortement recommandé. Sans lui : perte d'un nœud = perte de quorum. pvecm expected 1 pour les urgences. |
| 3+ nœuds | HA complète. Tolère floor((N-1)/2) pannes (3 nœuds : 1, 5 nœuds : 2). |
Détecter le nombre de nœuds : pvecm nodes | grep -c '^\s*[0-9]'
6. Référence rapide de dépannage
| Problème | Diagnostic |
|---|---|
| Cluster non votant | pvecm status > « Quorate: No ». Vérifier la connectivité, systemctl status corosync. Urgence : pvecm expected 1. |
| Le nœud ne peut pas rejoindre | Vérifier UDP 5405-5412, synchronisation temporelle, SSH (TCP 22). Essayer : pvecm add {IP} --fingerprint {SHA256}. |
| La VM ne démarre pas | Vérifier le verrou... |