Vous avez un serveur bare metal et vous voulez qu'il fasse tourner des machines virtuelles et des conteneurs au lieu d'un seul système d'exploitation. Proxmox VE transforme ce matériel brut en une plateforme de virtualisation complète : un hôte basé sur Debian avec une interface web, la virtualisation complète KVM, des conteneurs système LXC, du stockage et un réseau intégrés, et aucune licence d'hyperviseur par socket à acheter. Ce guide parcourt tout le chemin, d'un serveur vierge jusqu'à un hôte fonctionnel. Nous installons Proxmox VE 9.2 depuis l'ISO, corrigeons les dépôts APT et effectuons la mise à jour, comprenons le réseau en bridge par défaut, examinons le stockage, créons une première VM et un premier conteneur LXC, et terminons par un durcissement de base. À la fin, vous aurez un nœud unique prêt pour la production, que vous pourrez faire évoluer plus tard vers un cluster.

Un pare-feu OPNsense virtualisé sur votre hôte Proxmox vous donne ce que les fabricants d'appliances facturent à quatre chiffres : un pare-feu/routeur complet qui protège vos VM, avec un snapshot avant chaque mise à jour et sans matériel supplémentaire. Le piège : les détails de configuration (bridges, VirtIO, offloading) décident si le résultat est rock-solid ou étrangement instable. Ce guide couvre les architectures réseau qui fonctionnent sur un serveur dédié, la configuration exacte de VM sur laquelle la communauté s'est mise d'accord, l'installation, et les réserves honnêtes sur les performances et la protection de l'hôte Proxmox lui-même.

Proxmox VE embarque tout ce qu'il faut pour ne jamais perdre une VM, et les réglages par défaut n'en exploitent presque rien. Des snapshots qui vivent sur le même disque que la VM, des archives vzdump ponctuelles sans politique de rétention, et aucun test de restauration : voilà comment les hôtes de virtualisation se retrouvent réellement en difficulté. Ce guide construit la vraie stratégie en trois niveaux : à quoi servent réellement les snapshots, les sauvegardes vzdump planifiées correctement (modes, rétention, fleecing), et à partir de quand la déduplication, la vérification et la synchronisation hors site de Proxmox Backup Server justifient une seconde machine.

Les exigences réelles d'un cluster Proxmox tiennent en une phrase : trois nœuds, une liaison privée à faible latence entre eux, et un stockage que les nœuds survivants peuvent atteindre. Tout le reste (quorum, fencing, Ceph contre réplication) n'est que la justification derrière ces trois points. Ce guide couvre ce que le clustering apporte avant même que la HA entre en jeu, pourquoi le quorum fait de trois le chiffre magique, les règles réseau de corosync que l'on viole en premier, les trois stratégies de stockage, et à quoi ressemble réellement un failover quand un nœud tombe à 3 h du matin.

Proxmox VE vous offre deux façons de découper un serveur : des machines virtuelles complètes via KVM, et des conteneurs système LXC qui partagent le noyau de l'hôte. Le bon choix par workload est généralement clair dès que vous connaissez les trois questions qui tranchent : l'isolation, le noyau et la migration. Ce guide explique comment chacun fonctionne réellement, les compare sur les dimensions qui comptent en pratique, tranche la question de Docker avec les recommandations actuelles de Proxmox lui-même, et se termine par un tableau de décision applicable service par service.