Sommet Xen 2026 : VM, Docker ou bare metal pour l’auto-hébergement

Le Xen Summit 2026 s’ouvre à Munich le 15 septembre, à un moment intéressant pour la virtualisation. Docker peut empaqueter presque toutes les applications auto-hébergées qui intéressent les utilisateurs, mais les hyperviseurs continuent d’évoluer dans les domaines du cloud, de la sécurité, des systèmes embarqués et des charges de travail fortement dépendantes du matériel.

Pour le propriétaire d’un serveur domestique, la question utile n’est pas « Xen ou Docker ? ». Ils opèrent à des couches différentes. La vraie décision est la suivante : de quelle limite chaque charge de travail a-t-elle besoin ?

Xen Summit 2026 : pourquoi les hyperviseurs comptent-ils toujours ?

Le Xen Summit 2026 se tient du 15 au 17 septembre à Munich, avec deux jours de présentations techniques suivis d’une journée consacrée aux sessions d’architecture et de conception. Le programme couvre l’infrastructure cloud, la sécurité, Arm, les systèmes embarqués, l’automobile, les outils et les déploiements en conditions réelles.

Xen 4.22 est également sorti peu avant le sommet. La version actuelle est prise en charge jusqu’en juillet 2029, et le support de sécurité est prolongé jusqu’en juillet 2031. Ce cycle de vie en dit long sur la virtualisation moderne : la question n’est de plus en plus « combien de VM cette machine peut-elle exécuter ? », mais avec quelle fiabilité l’infrastructure peut-elle isoler, contrôler et maintenir les charges de travail au fil du temps ?

C’est aussi pourquoi les conteneurs n’ont jamais rendu les hyperviseurs obsolètes.

Docker n’a pas tué la machine virtuelle

Les conteneurs résolvent un problème extrêmement utile : regrouper les applications et leurs dépendances sans empaqueter un système d’exploitation invité entier pour chaque service.

La documentation de Docker sur les conteneurs souligne la différence architecturale : les conteneurs peuvent partager le noyau de l’hôte, tandis qu’une machine virtuelle exécute un système d’exploitation invité doté de son propre noyau.

Conteneur
────────────
Dépendances et déploiement
Dépendances
────────────
Noyau de l’hôte partagé


Machine virtuelle
────────────
Dépendances et déploiement
Espace utilisateur invité
Noyau invité
────────────
Matériel virtualisé

Les conteneurs optimisent le déploiement des applications.

Les VM créent une autre limite entre les systèmes d’exploitation.

Et, dans les infrastructures réelles, ils sont généralement empilés :

Matériel
   ↓
Hyperviseur
   ↓
Machine virtuelle
   ↓
Environnement d’exécution des conteneurs
   ↓
Conteneurs

Ainsi, « VM ou Docker » est souvent le mauvais débat.

La vraie question est de savoir de quelle limite la charge de travail a réellement besoin.

Les quatre limites d’un serveur auto-hébergé

Comptes, autorisations et accès aux données

L’erreur consiste à s’attendre à ce qu’une couche résolve le problème d’une autre couche.

Un conteneur ne vous protège pas contre la panne de l’hôte physique. Six machines virtuelles sur le même SSD ne créent pas six systèmes de stockage indépendants. Un deuxième serveur ne corrige pas une authentification applicative faible.

Et donner à chaque application Web ordinaire sa propre machine virtuelle peut recréer la surcharge de déploiement que les conteneurs étaient censés supprimer.

Utilisez la frontière la moins coûteuse qui satisfasse réellement l’exigence.

Avez-vous réellement besoin d’une machine virtuelle ? Le test en cinq questions

1. A-t-elle besoin d’un système d’exploitation ou d’un noyau différent ?

Windows, une distribution Linux complète distincte, une appliance pare-feu ou des tests au niveau du système d’exploitation sont des candidats évidents pour une machine virtuelle.
            ↓
           VM

Système d’exploitation ou noyau différent requis ?

2. A-t-elle besoin d’une frontière de confiance distincte ?

Les expériences de sécurité, les logiciels moins fiables, les agents de compilation et les environnements de test jetables peuvent justifier la séparation du système d’exploitation invité et de l’hôte principal.

Une machine virtuelle n’est pas automatiquement « sécurisée », mais elle fournit une frontière d’isolation différente de celle d’un autre processus partageant le même noyau hôte.

3. A-t-elle besoin d’un contrôle bas niveau du système d’exploitation ou du réseau ?

Les pare-feu, les laboratoires de routage et les systèmes d’exploitation d’appliance bénéficient souvent de leur propre environnement d’exploitation, plutôt que de modifier sans cesse l’hôte conteneur qui les héberge.

4. A-t-elle besoin de la propriété directe du matériel ?

C’est ici que la virtualisation devient particulièrement intéressante.

• Une charge de travail peut nécessiter un :
• GPU,
• carte réseau,
• contrôleur USB,
• autre périphérique PCIe.

La documentation actuelle sur l’infrastructure de Xen inclut précisément le passthrough PCI et le SR-IOV, car la question architecturale devient parfois :

quel invité possède cet appareil physique ?

5. S’agit-il simplement d’une autre application ?

Si la charge de travail est un tableau de bord classique, un service multimédia, une application Web avec base de données, un outil de téléchargement ou un service d’automatisation — et qu’elle ne nécessite ni un autre noyau ni une frontière de confiance spéciale — un conteneur est généralement le point de départ le plus simple.

Machine virtuelle ou conteneur ou bare metal pour les serveurs domestiques

La distinction importante est que l’utilisation des ressources et l’isolation sont deux questions distinctes.

Une petite VM Linux peut consommer très peu. Un conteneur d’IA peut monopoliser un GPU entier et plusieurs dizaines de gigaoctets de mémoire.

Le problème du serveur unique : la consolidation a trois limites

Le dimensionnement d’un serveur domestique commence généralement par le CPU et la RAM. En pratique, un serveur consolidé peut devenir « plein » pour trois raisons différentes.

Limite de calcul

La limite la plus connue : il n’y a pas assez de CPU, de RAM, de performances de stockage, de capacité GPU ou de VRAM pour une charge de travail supplémentaire.

Limite d’isolation

L’hôte dispose encore de ressources, mais vous ne voulez plus qu’une autre charge de travail partage le même noyau, les mêmes privilèges, le même matériel ou la même frontière administrative.

Limite de défaillance

Les charges de travail tiennent techniquement, mais trop de services importants tombent désormais en panne ensemble.

Un hôte physique
├── DNS
├── stockage
├── Home Assistant
├── multimédia
├── VM Windows
└── expériences

Un seul redémarrage affecte désormais toute la maison.

Cela fournit un meilleur modèle pour la consolidation des serveurs domestiques :

Capacité du serveur
ne se limite pas seulement à :

CPU + RAM

Elle peut également être limitée par :

Tolérance à l’isolation

ou

Tolérance aux pannes

Un serveur peut atteindre sa limite d’isolation ou de tolérance aux pannes bien avant que son processeur n’atteigne 100 %.

L’isolation virtuelle n’est pas une redondance physique

Créer six VM vous donne six frontières logicielles utiles. Cela ne vous donne pas six machines physiques indépendantes.

L’hôte tombe en panne
   ↓
L’hyperviseur s’arrête
   ↓
Toutes les VM sur cet hôte s’arrêtent

Il en va de même pour le stockage. Cinq disques de VM sur un seul SSD hors service restent cinq disques de VM indisponibles.

C’est particulièrement important lorsqu’un homelab se transforme discrètement en environnement de production domestique.

Trois enseignements concrets de la virtualisation dans les homelabs Zima

Le modèle des limites devient plus facile à comprendre lorsqu’il est appliqué à du matériel réel plutôt qu’à des schémas.

1. Un hôte de VM léger a quand même une limite de mémoire

ZimaOS prend en charge nativement ZVM depuis la version 1.3, notamment l’installation en un clic de VM Windows et Linux. Ses exigences matérielles actuelles pour les machines virtuelles soulignent également un point important que les calculateurs génériques du type « combien de VM ? » dissimulent souvent : le type d’invité, la charge de travail active, les instantanés et l’allocation mémoire comptent davantage qu’un nombre fixe de VM.

Un test récent en conditions réelles est arrivé à la même conclusion. Mart a exécuté une VM Windows 7 sous Proxmox sur un serveur compact doté de 8 Go de RAM et a montré qu’un invité modeste était réaliste, mais que la mémoire allouée à l’invité réduisait rapidement les ressources restantes pour l’hôte et les autres services. Le test de Proxmox et de Windows en VM rappelle utilement que la virtualisation ne crée pas de RAM.

La première limite de virtualisation sur un petit serveur est souvent la mémoire, et non le processeur.

2. La transmission directe concerne en réalité la propriété

La configuration Proxmox de Jonatan Castro en 2026 illustre plus clairement la question des limites matérielles.

Dans sa configuration, ZimaOS fonctionne comme une VM, tandis qu’un contrôleur SATA AHCI physique est transmis directement depuis Proxmox. ZimaOS voit alors les disques connectés et crée le RAID au niveau de l’invité.

Disques SATA physiques
       ↓
Contrôleur SATA
       ↓
Transmission directe PCI
       ↓
VM ZimaOS
       ↓
Gestionnaire de stockage

L’intérêt n’est pas simplement qu’« un NAS peut fonctionner dans une VM ».

Le détail architectural important est que la propriété du stockage est explicite : au lieu de fournir à l’invité uniquement des disques virtuels abstraits, l’invité reçoit le contrôleur physique concerné.

La configuration complète de virtualisation Proxmox et de transmission directe SATA montre également pourquoi la topologie PCIe et la prise en charge d’IOMMU sont importantes dès que la virtualisation interagit avec des périphériques physiques.

3. Un boîtier peut faire fonctionner de nombreux services, mais la haute disponibilité nécessite un autre boîtier

La même configuration offre une leçon encore plus importante sur la limite de tolérance aux défaillances.

Un nœud compact prend en charge une grande partie de la charge de travail des services, tandis qu’un nœud NAS distinct et un dispositif de quorum participent à la conception Proxmox globale. Les services configurés pour la haute disponibilité peuvent être déplacés lorsqu’un nœud est redémarré.

Cette architecture met en évidence une distinction que les benchmarks sur serveur unique ne peuvent pas montrer :

De nombreuses VM sur un seul hôte
≠
Haute disponibilité

Plusieurs nœuds capables de gérer les défaillances
+
conception de charges de travail partagées et déplaçables
=
une voie vers la haute disponibilité

Vous n’avez pas besoin d’une haute disponibilité pour un serveur domestique ordinaire. Mais si l’exigence est que « cette charge de travail survive à la mise hors service d’un nœud physique », créer une autre VM sur le même nœud ne suffit pas.

Quelles caractéristiques matérielles sont réellement importantes pour la virtualisation ?

« Prend en charge la virtualisation » est trop vague dès que le laboratoire dépasse le stade des VM basiques.

Pour les invités ordinaires, la prise en charge de la virtualisation par le CPU, une quantité suffisante de RAM et un stockage rapide pour les VM sont les éléments de base.

Pour les expériences de passthrough et de mise en réseau, examinez également :

• prise en charge de l’IOMMU, comme Intel VT-d ou AMD-Vi,
• extension PCIe disponible,
• plusieurs interfaces réseau physiques,
• prise en charge par le firmware,
• regroupement des périphériques et de l’IOMMU,
• suffisamment de mémoire pour l’hôte et les invités.

La documentation actuelle de XCP-ng sur le passthrough PCI distingue explicitement la virtualisation CPU standard de la fonctionnalité IOMMU requise pour l’attribution de périphériques physiques.

Pour un homelab compact, un serveur domestique x86 compact doté de VT-x, VT-d, d’une extension PCIe et de plusieurs interfaces Ethernet peut donc être plus intéressant que l’achat du processeur au plus grand nombre de cœurs.

Le matériel doit correspondre à la limite que vous cherchez à établir.

Xen est un hyperviseur ; XCP-ng est une plateforme

Le Xen Summit met également en évidence une autre confusion courante en matière de virtualisation : des projets situés à différents niveaux sont souvent comparés comme s’il s’agissait de produits équivalents.

Xen constitue la base de l’hyperviseur.

XAPI fournit les outils de gestion autour de Xen.

XCP-ng regroupe ces composants au sein d’une plateforme de virtualisation complète.

Plateforme de virtualisation
───────────────────────
XCP-ng + gestion

Outils de gestion
───────────────────────
XAPI

Hyperviseur
───────────────────────
Xen

Matériel
───────────────────────
CPU / RAM / NIC / GPU / Stockage

Le même principe s’applique ailleurs : une plateforme de virtualisation ne se résume pas à l’hyperviseur sous-jacent.

Pour un auto-hébergeur, le choix pratique ne concerne donc pas uniquement la technologie de l’hyperviseur. Il concerne aussi le cycle de vie des VM, le réseau, le stockage, les sauvegardes et la part de cette plateforme que vous souhaitez réellement gérer.

L’IA remet la gestion du matériel au cœur des enjeux

Les conteneurs ont rendu le packaging des applications plus portable. L’IA locale rappelle aux concepteurs d’infrastructures que le matériel est moins portable.

Un GPU soulève des questions dont un conteneur web standard n’aura peut-être jamais besoin :

À qui appartient le GPU ?

Une seule VM doit-elle disposer de tout le périphérique ?

Où se trouvent les pilotes ?

Le périphérique peut-il être réinitialisé proprement ?

Plusieurs charges de travail peuvent-elles le partager ?

L’hôte expose-t-il des groupes IOMMU utilisables ?

C’est l’une des raisons pour lesquelles le passthrough reste pertinent dans un monde axé sur Docker.

Les conteneurs ont simplifié la gestion des logiciels. Les accélérateurs ont remis la gestion du matériel au cœur des discussions sur l’architecture.

La bonne frontière compte davantage que le nombre de VM

Xen Summit 2026 est utile aux adeptes de l’auto-hébergement, même s’ils n’installent jamais Xen.

La leçon générale est que le bare metal, les VM et les conteneurs ne sont pas des niveaux de maturité où l’un finit par remplacer les autres.

Bare metal
→ propriété directe du matériel

Machine virtuelle
→ frontière du système d’exploitation / noyau

Conteneur
→ frontière de l’application

Autorisations de l’application
→ frontière utilisateur / données

Utilisez des conteneurs lorsqu’une frontière au niveau de l’application suffit.

Utilisez une VM lorsque le système d’exploitation, le modèle de confiance ou la propriété d’un périphérique physique mérite sa propre frontière.

Utilisez le bare metal lorsqu’une couche d’abstraction supplémentaire ajoute davantage de complexité de récupération que de flexibilité utile.

Et lorsqu’une seule machine commence à tout prendre en charge, ne vous demandez plus seulement si son processeur dispose de capacité disponible.

Demandez-vous quelle limite vous avez atteinte :

Plafond de calcul ?

Plafond d’isolation ?

Plafond de défaillance ?

L’objectif de la virtualisation n’est pas de maximiser le nombre de VM. Il est de définir la bonne frontière autour de la bonne charge de travail.

FAQ

Quand aura lieu Xen Summit 2026 ?

Xen Summit 2026 se tiendra du 15 au 17 septembre à Munich, en Allemagne. Les 15 et 16 septembre seront consacrés aux présentations techniques, tandis que le 17 septembre sera dédié aux sessions de conception et à la planification des projets.

Xen est-il identique à XCP-ng ?

Non. Xen est l’hyperviseur sous-jacent. XCP-ng est une plateforme de virtualisation complète fondée sur Xen et la pile d’outils XAPI, avec des fonctions de gestion, de stockage, de réseau et de cycle de vie des VM.

Dois-je utiliser une VM ou Docker pour l’auto-hébergement ?

Utilisez un conteneur lorsqu’une application peut partager le noyau de l’hôte en toute sécurité et a principalement besoin d’un empaquetage reproductible. Envisagez une VM lorsque la charge de travail nécessite un autre système d’exploitation, un autre noyau, une frontière de confiance ou l’attribution d’un matériel dédié.

Quand dois-je utiliser le bare metal plutôt qu’une VM ?

Le bare metal peut être plus simple lorsqu’une seule charge de travail domine la machine, que la propriété directe du matériel est importante ou que le passthrough ajouterait une complexité de récupération sans offrir de réel avantage d’isolation.

Puis-je exécuter un NAS dans une VM ?

Oui, mais définissez clairement la propriété du stockage. Le passthrough d’un contrôleur de stockage peut donner à la VM NAS une propriété plus directe des disques physiques, tandis que le bare metal peut rester plus simple lorsque le stockage est le rôle principal de la machine.

La virtualisation protège-t-elle contre la défaillance physique du serveur ?

Non. Les VM isolent les environnements logiciels, mais peuvent toujours partager une même carte mère, une même alimentation et un même système de stockage. Plusieurs VM sur un même hôte ne créent pas de redondance physique.

Que nécessite le passthrough d’un GPU ?

Le passthrough d’un GPU et d’autres périphériques PCI nécessite généralement la prise en charge de l’IOMMU, comme Intel VT-d ou AMD-Vi, en plus de la virtualisation CPU standard, ainsi qu’un firmware compatible, une topologie matérielle adaptée et une configuration appropriée de l’hyperviseur.