Corosync : la communication entre nœuds Corosync assure la communication entre les nœuds. Il envoie des “heartbeats” pour vérifier que chaque nœud est en vie et gère le quorum, le vote qui détermine si le cluster peut fonctionner.

pmxcfs : la configuration partagée pmxcfs (Proxmox Cluster File System) est un système de fichiers virtuel monté sur /etc/pve. C'est une base de données SQLite répliquée en temps réel sur tous les nœuds via Corosync.

Ce que contient /etc/pve :

Configuration des VM et conteneurs (nodes/<node>/qemu-server/, nodes/<node>/lxc/) Stockages, réseaux, utilisateurs, permissions Certificats SSL du cluster

Vue globale de tous les storages Proxmox

#pvesm status

LVM-thin : utilisation du pool (surveiller data% et meta%)

#lvs -o lv_name,data_percent,metadata_percent

ZFS : état du pool (doit afficher ONLINE)

#zpool status

ZFS : utilisation de l'espace

#zpool list

Directory : espace disque classique

#df -h

• Storage ≠ Disque : Proxmox organise le stockage en 3 couches (disques → backend → storage). Comprendre cette architecture évite les confusions.
• Fichier vs bloc : Directory stocke des fichiers visibles, LVM-thin et ZFS stockent des volumes bloc. Chacun a ses avantages.
• Snapshot ≠ Backup : le snapshot est un point de restauration court terme, le backup est une copie indépendante long terme. Vous avez besoin des deux.
• LVM-thin : efficace mais à surveiller : thin provisioning est puissant, mais un pool plein = catastrophe. Surveillez à partir de 80%.
• ZFS : intégrité contre ressources : checksums et redondance, mais demande de la RAM et des disques en mode HBA.
• Directory : simplicité et transparence : idéal pour ISO, backups, templates. Pas optimal pour les VM en production.
• Séparez runtime et archives : un storage pour vos VM, un autre pour vos backups.

Le réseau fonctionne en couches. Deux nous concernent ici :

• Un bridge = switch logiciel = travaille en L2 (il regarde les MAC)
• Le NAT/routage = travaille en L3 (il regarde les IP)
• Un VLAN = étiquetage L2 (tag 802.1Q sur les trames)

Le chemin d'un paquet (bridge simple) Quand une VM envoie un paquet vers Internet :

VM (eth0) → tap100i0 → vmbr0 → eno1 → switch physique → Internet

Le bridge vmbr0 fonctionne comme un switch : il reçoit le paquet de la VM via tap100i0, regarde l'adresse MAC de destination, et le transmet vers eno1 (qui est connecté au réseau physique).

Le chemin d'un paquet (NAT) En NAT, c'est différent, le paquet passe par le routage de l'hôte :

VM (eth0) → tap100i0 → vmbr0 → ip_forward → NAT (iptables) → eno1 → Internet

L'hôte Proxmox remplace l'IP source de la VM par son IP publique avant d'envoyer. Quand la réponse arrive, il fait l'inverse.

Si vous avez installé Proxmox normalement, c'est déjà en place. Vérifiez :

/etc/network/interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Points clés :

• L'IP est sur vmbr0, pas sur eno1
• eno1 est en manual (pas d'IP)
• bridge-ports eno1 connecte le bridge au physique

Modifier le réseau peut vous couper l'accès. Suivez cette procédure systématiquement.

Avant de modifier

Ces trois points se préparent quand tout va bien : une fois l'accès perdu, il est trop tard pour sauvegarder quoi que ce soit.

1. 1 * Vérifiez que vous avez un accès console
   • IPMI/iLO/iDRAC (serveur physique)
   • Console VNC (hébergeur)
   • Accès physique clavier/écran

1. 2 Sauvegardez la config actuelle

#cp /etc/network/interfaces /etc/network/interfaces.backup-$(date +%Y%m%d-%H%M)

1. 3 Notez l'IP et la gateway actuelles

#ip -br addr
#ip route | grep default

Appliquer les changements

Rien n'est actif tant que Apply Configuration n'a pas été cliqué : jusque-là, vos modifications dorment dans /etc/network/interfaces.new. La vérification doit suivre immédiatement, pendant que vous disposez encore d'une session ouverte.

1. Faites vos modifications via l'interface web
2. Cliquez Apply Configuration
3. Regardez le Task log (en bas), il doit se terminer par TASK OK
4. Immédiatement après, vérifiez :

# L'hôte répond
#ping -c 2 <IP_PROXMOX>

# L'interface web est accessible
#curl -k https://<IP_PROXMOX>:8006

Si vous perdez l'accès

La procédure de retour arrière consiste à remettre en place le fichier sauvegardé, puis à le recharger. Elle se déroule entièrement depuis la console, l'interface web étant par définition inaccessible.

Accédez via la console (IPMI, VNC, physique)

Listez les backups disponibles :

#ls -la /etc/network/interfaces*

Proxmox crée des backups avec timestamp lors de l'apply.

Restaurez le dernier backup fonctionnel :

#cp /etc/network/interfaces.backup-YYYYMMDD-HHMM /etc/network/interfaces

Réappliquez :

#ifreload -a

Vérifiez que l'accès est rétabli

Ces trois contrôles s'enchaînent du plus proche au plus lointain : l'hôte, le bridge, puis la VM. Si le ping vers la passerelle échoue depuis la VM alors que l'hôte répond, le problème est presque toujours dans le rattachement de la carte virtuelle au bon bridge.

# L'hôte a une IP sur vmbr0

#ip -br addr | grep vmbr0

# Le bridge est connecté à eno1

#bridge link show

# Une VM obtient une IP (DHCP ou statique) # Depuis la VM :

#ping 192.168.1.1   # passerelle
#ping 8.8.8.8       # internet

# Ce que fait “Apply Configuration” en coulisses

#ifreload -a

# Voir les VLAN configurés sur le bridge

#bridge vlan show

# Depuis une VM sur VLAN 10

#ping <autre-machine-vlan-10>   # doit marcher
#ping <machine-vlan-20>         # ne doit PAS marcher (isolation)

Activer le routage (persistant)

Le routage IP doit être activé pour que le NAT fonctionne. Ne pas utiliser echo 1 > /proc/… (perdu au reboot).

# Créer le fichier de config sysctl

#echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/99-ip-forward.conf

# Appliquer immédiatement

#sysctl -p /etc/sysctl.d/99-ip-forward.conf

# Vérifier

#cat /proc/sys/net/ipv4/ip_forward   # doit afficher 1

Port forwarding

Pour rendre un service accessible depuis l'extérieur :

# Rediriger le port 80 public vers la VM 10.10.10.10

#iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 80 -j DNAT --to 10.10.10.10:80
#iptables -A FORWARD -p tcp -d 10.10.10.10 --dport 80 -j ACCEPT

Le dernier test est le plus parlant : depuis la VM, l'adresse renvoyée par un service d'écho doit être l'IP publique de l'hôte, preuve que la traduction d'adresse s'applique bien.

# Sur l'hôte : vérifier le routage

#cat /proc/sys/net/ipv4/ip_forward   # 1

# Sur l'hôte : vérifier les règles NAT

#iptables -t nat -L -n -v | grep MASQUERADE

# Depuis la VM

#ping 8.8.8.8           # internet
#curl -s ifconfig.me    # doit afficher l'IP publique de l'hôte

Lancez-les dans cet ordre : elles vont du plus général au plus spécifique. L'option -br de ip produit une sortie condensée sur une ligne par interface, bien plus lisible que la sortie complète quand le serveur héberge une dizaine de tap.

# État des interfaces

#ip -br link
#ip -br addr

# Bridges et leurs ports

#bridge link show

# Table de routage

#ip route

# Règles NAT

#iptables -t nat -L -n -v

# Logs réseau récents

#journalctl -u networking --no-pager -n 30

Pour du stockage réseau (Ceph, NFS, iSCSI), augmenter le MTU à 9000 améliore le débit.

Prérequis : tous les équipements du chemin doivent supporter le même MTU.

/etc/network/interfaces
auto vmbr1
iface vmbr1 inet static
    address 10.0.0.1/24
    bridge-ports eno2
    mtu 9000

Test :

#ping -M do -s 8972 10.0.0.2   # 8972 + 28 headers = 9000

Vérifier vos permissions Sans entrer dans les procédures de création, voici comment lire l'état de votre RBAC :

# Lister tous les utilisateurs
#pveum user list

# Lister les groupes
#pveum group list

# Lister les rôles disponibles
#pveum role list

# Voir les ACL (qui a quoi où)
#pveum acl list

# Voir les tokens d'un utilisateur
#pveum user token list alice@pve

# Voir les privilèges d'un rôle
#pveum role list PVEVMUser --output json

Autorisation = Sujet × Rôle × Path : comprendre cette formule évite 90% des erreurs de permissions.

Le slash / est dangereux : une permission sur / se propage partout. Utilisez les paths complets.

Les pools simplifient tout : regroupez les VM par usage et attribuez les permissions sur les pools, pas sur les VM individuelles.

Un token = une tâche : pour l'automatisation, créez un token dédié avec le minimum de droits.

root@pam bypass tout : le compte root Linux n'est pas limité par les ACL Proxmox. Utilisez-le uniquement pour l'urgence.

Console = accès sensible : VM.Console permet de voir et utiliser les sessions ouvertes. Ne le donnez pas aux auditeurs.

Les backups contiennent les données : l'accès au stockage backup = accès aux données des VM. Limitez-le.

Revue trimestrielle : permissions, tokens, groupes. Les droits s'accumulent si on ne nettoie pas.