Proxmox VE : installation, réseau et haute disponibilité sur un cluster de trois nœuds

Contexte et objectif

Proxmox VE est un hyperviseur de type 1 open source basé sur Debian, qui associe machines virtuelles KVM, conteneurs LXC et interface web d'administration. L'objectif de ce travail était de le prendre en main dans un environnement de test avant une mise en production : installation, création d'une première VM, maîtrise du réseau de l'hyperviseur, déploiement sur un serveur physique, puis mise en place et démonstration de la haute disponibilité.

Ce que j'ai réalisé

J'ai installé Proxmox VE 9.2 dans une machine virtuelle (virtualisation imbriquée), puis je l'ai reproduit sous Hyper-V plutôt que d'installer un second hyperviseur sur mon poste.
J'ai séparé le réseau de gestion et l'accès à Internet avec deux bridges Linux (vmbr0 en adresse fixe, vmbr1 en DHCP), en ne gardant qu'une seule route par défaut.
Nous avons installé Proxmox sur un serveur physique de la salle, démarré depuis une clé USB, avec un plan d'adressage en /23 et un accès à l'interface web à travers le routeur.
J'ai proposé une architecture à deux zones de confiance : un serveur public exposé par redirection de ports, un serveur applicatif interne sans passerelle, le tout filtré par le pare-feu intégré.
J'ai construit un cluster de trois nœuds par export et import de VM en PowerShell, ajouté un pool ZFS sur chaque nœud, planifié la réplication toutes les minutes et déclaré une VM comme ressource haute disponibilité.
J'ai simulé une panne par coupure brutale du nœud principal : la VM a redémarré automatiquement sur un autre nœud.

Difficultés rencontrées et solutions

Installeur introuvable sous Hyper-V en génération 2 : VM recréée en génération 1 et installation en mode texte.
Clones sans réseau : les noms d'interfaces étaient épinglés sur les anciennes adresses MAC. J'ai corrigé les fichiers d'épinglage puis régénéré l'initramfs.
Deux refus de jonction au cluster (adresse de lien incorrecte, nom d'hôte en double), corrigés nœud par nœud.
Erreur de syntaxe dans le fichier d'interfaces, détectée avant application grâce à ifreload -a.

Résultats

Cluster de trois nœuds opérationnel avec quorum conservé à la perte d'un nœud.
Bascule automatique de la VM de test démontrée, avec une perte de données limitée à une minute au plus (fréquence de réplication).
Serveur physique joignable, sans perte de paquets vers sa passerelle et vers Internet.

Ce que j'en retiens

Le point central est la gestion de la route par défaut : une seule interface doit la porter. La seconde notion clé est le bridge, qui joue le rôle de commutateur virtuel et détermine à lui seul le réseau d'une VM. J'ai aussi identifié les limites de ma maquette : un stockage ZFS répliqué n'est pas un stockage partagé, et trois nœuds sur un seul PC valident le mécanisme de bascule, pas la résilience matérielle. En production, il faudrait Ceph ou un SAN, un réseau Corosync dédié et des nœuds physiques distincts.