Tous les articles

Le bare metal l'emporte sur les deux chiffres qui décident si un serveur de jeu est agréable : le temps de tick dans le pire cas et la latence dans le pire cas. Une VM mono-locataire sur du matériel que vous contrôlez s'en approche. C'est sur un VPS multi-locataire survendu que la simulation à tick fixe s'effondre, parce qu'un vCPU ordonnancé avec quelques millisecondes de retard donne un tick manqué que chaque joueur voit sous forme de rubber-banding. Ce guide explique ce qu'un hyperviseur ajoute à une boucle de tick, pourquoi le temps de tick au 95e percentile compte plus que le débit moyen, comment mesurer le steal time et le MSPT sur votre propre serveur, et quand une VM reste le bon choix.

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.

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.

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.

Proxmox VE est une plateforme de virtualisation gratuite et open source qui s'exécute directement sur un serveur physique, transformant une machine en hôte pour des machines virtuelles complètes et des conteneurs légers. Mais ce n'est pas le seul hyperviseur bare-metal : VMware ESXi, XCP-ng et Hyper-V résolvent chacun le même problème différemment, et le bon choix dépend bien plus des licences, du clustering et de l'écosystème de votre équipe que des fonctionnalités brutes. Ce guide explique ce qu'est réellement Proxmox VE, ce que signifie un hyperviseur bare-metal, et comment les quatre principaux prétendants se comparent en matière de coût, de gestion, de haute disponibilité, de stockage et de sauvegarde, avec un tableau comparatif, un cadre de décision tranché et des liens vers le bon serveur pour le déployer.

Le réseau est le point où la plupart des nouvelles installations Proxmox s'enlisent : l'installation fonctionne, la première VM démarre, puis "comment lui donner une IP ?" se transforme en un après-midi passé sur des fils de forum à moitié pertinents. Le modèle sous-jacent est en réalité simple : les VM se branchent sur des bridges Linux, et tout le reste n'est que variations. Ce guide construit ce modèle correctement : ce qu'est vraiment vmbr0, les configurations bridged, routed et NAT chez un hébergeur, les bridges VLAN-aware, le bonding bien fait, la place de la couche SDN, et comment modifier tout cela sans vous couper vous-même l'accès.

Presque toutes les comparaisons Proxmox vs ESXi sont écrites pour un homelab ou par un éditeur de logiciels de sauvegarde. Celle-ci s'adresse à qui loue un serveur dédié ou exploite une petite flotte d'hébergement, avec ses contraintes propres : une reprise qui passe uniquement par l'IPMI, un matériel mono-locataire, pas de SAN, et un réseau configuré sur l'hôte. Elle couvre ce que le changement de licences de Broadcom a modifié, ce que l'ESXi gratuit réintroduit sait faire ou non, les différences d'architecture qui comptent sur du bare metal, les pannes multi-nœuds qui font mal en production (et leurs correctifs), un calcul de coût par nœud sans complaisance, et les cas où ESXi garde l'avantage.

Les listes restreintes post-VMware se résument généralement à ces deux options : Proxmox VE, la plateforme Debian/KVM avec tout intégré, et XCP-ng, le descendant de XenServer basé sur Xen et géré via Xen Orchestra. Les deux sont réellement prêts pour la production et réellement gratuits ; ils incarnent simplement des philosophies différentes sur la façon de construire une plateforme de virtualisation. Cette comparaison couvre la scission architecturale (KVM dans Linux vs Xen plus dom0), des modèles de gestion et de support très différents, le stockage et les sauvegardes, les prix actuels des deux côtés, et un verdict sous conditions.