Proxmox VE : comprendre l'architecture (mental model)

Proxmox VE organise vos ressources autour de 4 piliers : nœuds, cluster, stockage et réseau. Avant de créer votre première VM, comprendre cette architecture vous évitera des erreurs de conception et facilitera vos futures évolutions (haute disponibilité, migration, backup). Ce guide s’adresse aux débutants qui découvrent Proxmox ou la virtualisation. À la fin, vous saurez naviguer dans l’interface et comprendre comment les différents composants interagissent.

Terme	Définition express
Datacenter	Vue globale de tous vos nœuds dans l’UI
Node (nœud)	Un serveur physique avec Proxmox installé
VM	Machine virtuelle complète (KVM)
CT	Conteneur Linux léger (LXC)
Storage	Espace de stockage (local ou partagé)
Content type	Ce qu’un storage peut contenir (ISO, backup, disques…)
Bridge	Switch virtuel qui connecte les VM au réseau
VLAN	Réseau virtuel isolé (segmentation)
Quorum	Vote majoritaire pour maintenir un cluster cohérent
pmxcfs	Système de fichiers distribué de Proxmox (`/etc/pve`)

Pourquoi un “mental model” ?

Proxmox VE n’est pas un simple logiciel de virtualisation — c’est une plateforme complète qui gère :

des machines virtuelles (VM),
des conteneurs (CT),
du stockage (local ou partagé),
du réseau (bridges, VLAN),
des utilisateurs et permissions.

Sans comprendre comment ces éléments s’articulent, vous risquez de :

créer des VM au mauvais endroit (mauvais stockage),
avoir des problèmes réseau difficiles à diagnostiquer,
ne pas pouvoir migrer vos VM vers un autre serveur,
perdre des données faute de stratégie de backup cohérente.

Le mental model, c’est la carte qui vous permet de naviguer dans Proxmox sans vous perdre.

Les 4 piliers de Proxmox VE

Voici comment Proxmox organise vos ressources :

Pilier	Ce que c’est	Analogie
Nœud	Un serveur physique avec Proxmox installé	Une maison autonome
Cluster	Plusieurs nœuds avec config partagée	Un plan de ville partagé + règles communes
Stockage	Là où sont stockés les disques des VM/CT	Les placards (locaux) ou entrepôts (partagés)
Réseau	Comment les VM/CT communiquent	Les routes et ponts du quartier

Architecture Proxmox : nœud, cluster, stockage, réseau

Pilier 1 : Le nœud (node)

Un nœud Proxmox est un serveur physique (ou parfois une VM de test) sur lequel Proxmox VE est installé. C’est l’unité de base de la plateforme.

Ce que fait un nœud

Exécute les VM et conteneurs
Fournit les ressources CPU, RAM, stockage local
Héberge l’interface web d’administration (port 8006)
Gère son propre réseau (bridges)

Un nœud = un serveur autonome

Même avec un seul nœud, vous pouvez :

créer des dizaines de VM et conteneurs,
configurer plusieurs réseaux virtuels,
faire des snapshots et backups,
gérer plusieurs utilisateurs avec des droits différents.

Identifier un nœud dans l’interface

Dans l’interface web Proxmox, les nœuds apparaissent sous “Datacenter” dans le panneau de gauche :

Datacenter
└── proxmox1 (node)      ← Votre nœud
    ├── VM 100
    ├── VM 101
    └── CT 200

Le nom du nœud est défini à l’installation (souvent le hostname du serveur).

Pilier 2 : Le cluster

Un cluster Proxmox est un groupe de nœuds qui partagent une configuration commune et peuvent coopérer.

Pourquoi un cluster ?

Sans cluster	Avec cluster
Chaque nœud est isolé	Configuration partagée
Pas de migration entre nœuds	Migration à chaud possible
Pas de haute disponibilité	HA automatique
Gestion nœud par nœud	Vue unifiée “Datacenter”

Comment ça fonctionne

Un cluster Proxmox repose sur deux composants clés :

Composant	Rôle
Corosync	Protocole de communication entre nœuds (heartbeat, votes)
pmxcfs	Système de fichiers distribué qui stocke la configuration

Corosync : le cœur du cluster

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

Avant (nœud seul)	Après (cluster)
Config locale dans `/etc/pve`	Config synchronisée sur tous les nœuds
Gestion nœud par nœud	Vue unifiée “Datacenter”
Pas de migration possible	Migration à chaud entre nœuds
Utilisateurs locaux	Utilisateurs et permissions centralisés

Le quorum : la règle de la majorité

Le quorum garantit qu’un cluster ne se “divise” pas en deux parties indépendantes (split-brain). Pour fonctionner, plus de 50% des votes doivent être disponibles.

Configuration	Votes totaux	Majorité requise	Pannes tolérées
2 nœuds	2	2	0 ⚠️
3 nœuds	3	2	1
4 nœuds	4	3	1
5 nœuds	5	3	2
2 nœuds + QDevice	3	2	1 ✅

QDevice : l’arbitre pour les petits clusters

Un QDevice est un service externe qui fournit un vote supplémentaire au cluster, sans héberger de VM. C’est la solution idéale pour un cluster 2 nœuds.

Comment ça marche :

Sur une machine tierce (VM, Raspberry Pi, serveur Linux léger), vous installez corosync-qnetd
Sur chaque nœud Proxmox, vous installez corosync-qdevice
Le QDevice vote pour maintenir le quorum si un nœud tombe

Prérequis :

Port 5403/tcp ouvert entre les nœuds et le QDevice
Le QDevice doit être sur un réseau fiable et accessible
Ne pas héberger le QDevice sur l’un des nœuds Proxmox (sinon aucun intérêt)

Situation	Recommandation
Budget limité, 2 serveurs max	✅ 2 nœuds + QDevice
3+ serveurs disponibles	Préférez un vrai 3ème nœud
Homelab sur un seul serveur	Pas de cluster, nœud seul

Réseau cluster : les exigences Corosync

Corosync n’a pas besoin de beaucoup de bande passante, mais exige une latence faible et stable.

Critère	Exigence
Bande passante	100 Mbps suffisent (1 Gbps recommandé)
Latence	< 5 ms idéal, instable au-delà de 10-30 ms
Stabilité	Corosync est sensible au jitter (variations de latence)
Réseau dédié	Fortement recommandé (VLAN ou interface séparée)

Cluster vs nœud seul : que choisir ?

Situation	Recommandation
Homelab / Tests	Nœud seul
Petite prod sans criticité	Nœud seul + backups réguliers
Besoin de migration à chaud	Cluster obligatoire
Haute disponibilité requise	Cluster 3+ nœuds (ou 2 + QDevice)

Pilier 3 : Le stockage

Le stockage dans Proxmox désigne l’endroit où sont enregistrés :

les disques virtuels des VM,
les systèmes de fichiers des conteneurs,
les templates et ISO,
les backups.

Types de stockage

Proxmox supporte de nombreux backends de stockage :

Type	Usage	Partage possible
Directory	Dossier sur le disque local	Non
LVM-thin	Volumes logiques avec thin provisioning	Non
ZFS	Système de fichiers avancé (snapshots, compression)	Non
NFS	Partage réseau (serveur NAS)	Oui
iSCSI	Stockage bloc via réseau	Oui
Ceph	Stockage distribué intégré à Proxmox	Oui

Stockage local vs partagé

Stockage local : chaque nœud a son propre espace. Simple, performant, mais les VM ne peuvent pas migrer vers un autre nœud.

Stockage partagé : tous les nœuds accèdent au même espace (NFS, Ceph, iSCSI). Obligatoire pour la migration à chaud et la HA (haute disponibilité).

Architecture de stockage partagé Proxmox avec deux nœuds accédant à un stockage NFS commun

Contenus vs stockage

Proxmox distingue ce qu’un stockage peut contenir :

Content type	Ce que c’est
`images`	Disques de VM
`rootdir`	Systèmes de fichiers CT
`iso`	Images ISO d’installation
`vztmpl`	Templates de conteneurs
`backup`	Fichiers de sauvegarde
`snippets`	Scripts cloud-init, hooks

Un stockage peut être configuré pour accepter certains types seulement. Par exemple : un NFS dédié aux backups.

Snapshot vs Backup : ne pas confondre !

C’est l’erreur n°1 des débutants Proxmox. Les deux servent à “sauvegarder”, mais pas de la même façon :

Critère	Snapshot	Backup
Où ?	Sur le même stockage que la VM	Sur un stockage séparé (idéalement distant)
Quoi ?	État instantané (delta)	Copie complète exportable
Vitesse	Instantané	Minutes à heures
Impact perf	⚠️ Dégrade les I/O si conservé longtemps	Aucun après la copie
Restauration	Rollback rapide	Restore sur n’importe quel nœud
Cas d’usage	Test avant mise à jour, debug	Sauvegarde 3-2-1, PRA, migration

Pilier 4 : Le réseau

Le réseau dans Proxmox connecte vos VM et conteneurs au monde extérieur (ou les isole).

Le bridge : concept fondamental

Un bridge (pont) est un commutateur virtuel qui relie les VM au réseau physique. Par défaut, Proxmox crée vmbr0 relié à votre interface réseau principale.

Topologie réseau Proxmox avec bridge vmbr0 connectant les VM et conteneurs à Internet

Chaque VM/CT connectée à vmbr0 reçoit une IP du même réseau que l’hôte Proxmox (via DHCP ou configuration statique).

Plusieurs réseaux avec VLAN

Pour isoler des groupes de VM (prod vs dev, front vs back), vous pouvez utiliser des VLAN (Virtual LAN) :

VLAN	Usage	Plage IP
VLAN 10	Production	192.168.10.0/24
VLAN 20	Développement	192.168.20.0/24
VLAN 30	Management	192.168.30.0/24

Les VLAN nécessitent un switch physique compatible et une configuration côté Proxmox.

VM vs Conteneur : quelle différence ?

Proxmox propose deux types de workloads : les VM KVM et les conteneurs LXC.

Machine virtuelle (VM KVM)

Une VM est un ordinateur virtuel complet avec son propre noyau, son BIOS/UEFI, ses drivers.

Avantages :

Isolation totale (sécurité maximale)
N’importe quel OS (Windows, BSD, Linux…)
Compatible avec les applications legacy

Inconvénients :

Consomme plus de ressources (RAM, CPU)
Démarrage plus lent
Overhead de virtualisation

Conteneur LXC

Un conteneur partage le noyau Linux de l’hôte Proxmox. C’est une isolation au niveau du système d’exploitation.