XCP-ng: Evolution du Lab V2.0 - Configuration réseau du pool et migration de VMs

Introduction

Il est temps maintenant de rentrer dans le dur.

Si on fait un petit point étape :

• On a installé XCP-ng sur trois serveurs physiques
• On a configuré chacun des serveurs avec un espace de stockage local dédié aux VMs
• On a déployé en CLI sur le premier serveur (prdxcpsrv001) une VM Rocky Linux 10
• On a installé sur cette VM la solution Xen Orchestra à partir des sources
• À partir de Xen Orchestra (XO), on a créé un pool xcp-pool dans lequel on a inscrit les trois serveurs

On a donc maintenant une excellente base pour concevoir une architecture HA comme on l'ambitionnait dans l'introduction de ce tutoriel.

La suite logique est donc de se concentrer sur le réseau, car, pour que tout cela fonctionne correctement, nous devons avoir une logique réseau adaptée et cohérente.

Cible

Pour rappel, chaque serveur dispose d'une carte 1G, déjà en exploitation et utilisée pour l'accès aux différents serveurs (et mappée à la VM Xen Orchestra). Chaque serveur dispose d'une IP en 192.168.10.0/24 associée à cette carte et exploite ce subnet pour dialoguer entre eux. C'est aussi cette interface qu'on sollicite pour les accès SSH.

Côté XCP, cela correspond dans la section Network d'un node sous Xen Orchestra à: Pool-wide network associated with eth0.

Dans le jargon XCP, on parle de PIFs pour Physical Interface. On retrouve la petite icône en étoile pour indiquer que c'est l'interface par défaut du node. On exploite donc la PIF eth0.

L'idée va être de ne pas exploiter cette dernière pour la data des VMs (hors XO) et la réplication des données entre les nodes mais plutôt de s'appuyer sur l'interface 10G bien plus adaptée et performante. C'est la PIF eth1.

À cette interface on va donc associer plusieurs VLANs :

• LAN: VLAN par défaut (donc pas besoin de tag) donnant accès à mon subnet de base 192.168.10.0, certes le même que pour l'administration des serveurs, mais dédié aux VMs. (Nous aurions pu attribuer un sous-réseau dit out of band pour eth0 afin de séparer le réseau administratif, mais j'ai opté pour une solution plus simple pour mes besoins.)
• VLAN_WEB: VLAN avec l'ID 6, dédié aux VMs exposées à Internet (subnet 192.168.5.0/24)
• VLAN_DMZ_FIRST: VLAN avec l'ID 10, dédié à la communication avec le routeur WEB disposant de la connexion avec l'opérateur (subnet 192.168.8.0/24)
• VLAN_STORAGE: VLAN avec l'ID 12, dédié à la réplication du stockage entre les nodes (subnet 192.168.12.0/24), soit un réseau non routé (sans gateway)

En résumé on obtient ce schéma :

Configuration

Switch

L'idée ne va pas être ici de rentrer dans le détail de la configuration du switch que j'utilise, à savoir un MikroTik CRS309-1G-8S+IN disposant de huit interfaces 10G. Il fonctionne de base avec RouterOS, un système extrêmement fourni avec beaucoup d'options et de capacités.

Je vais juste rapidement décrire les quelques instructions passées et la logique globale. Libre à chacun d'adapter en fonction de son matériel.

Bien que la GUI de RouterOS soit complète, je vais privilégier la CLI via l'accès SSH à l'équipement.

Je vous passe la phase d'init du matériel et la mise en place de son IP d'administration (192.168.10.241). À savoir que, ne connaissant absolument pas RouterOS, l'IA m'a bien aidé (mais attention, sur la pure configuration réseau, j'ai parfois eu des surprises et pas dans le bon sens).

Par défaut, le routeur vient avec un bridge préconfiguré, voyez ça comme une sorte de switch virtuel présent au sein de l'équipement. On commence par retirer l'interface d'administration (la seule en 1G) de ce fameux bridge pour la rendre autonome en lui réappliquant son IP :

/interface/bridge/port remove [find interface=ether1]
/ip/address add address=192.168.10.241/24 interface=ether1

On s'occupe de la partie DNS et Gateway :

/IP/route add dst-address=0.0.0.0/0 gateway=192.168.10.253
/IP/dns set servers=192.168.10.30

Puis on supprime le bridge par défaut :

/IP/address remove [find interface=bridge]
/interface/bridge/port remove [find bridge=bridge]

On crée ensuite un nouveau pont, nommé bridge1, avec une MTU (Unité de transmission maximale) de 9 000. C'est crucial pour l'optimisation des performances de la réplication du stockage. Pour l'instant on configure l'option vlan-filtering à no. Ce qui implique que le switch « virtuel » va se comporter comme un simple concentrateur en ignorant les tables de VLAN internes (en gros, tous les paquets sont transmis à tous les ports, peu importe les VLANs):

/interface/bridge add name=bridge1 mtu=9000 protocol-mode=none vlan-filtering=no

On ajoute les trois premières interfaces 10G à ce nouveau bridge :

/interface/bridge/port add bridge=bridge1 interface=sfp-sfpplus1 pvid=1 hw=yes
/interface/bridge/port add bridge=bridge1 interface=sfp-sfpplus2 pvid=1 hw=yes
/interface/bridge/port add bridge=bridge1 interface=sfp-sfpplus3 pvid=1 hw=yes

L'option hw=yes est importante. Elle active le Hardware Offloading pour tirer parti de l'accélération matérielle disponible dans le routeur.

On passe maintenant à la déclaration des VLANs :

# VLAN 1 (Admin/LAN) — géré nativement, mais il faut le déclarer
/interface/bridge/vlan add bridge=bridge1 vlan-ids=1 tagged=bridge1 untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3

# VLAN 6 (WEB) — tagged sur les 3 serveurs
/interface/bridge/vlan add bridge=bridge1 vlan-ids=6 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3

# VLAN 10 (DMZ_FIRST) — tagged sur les 3 serveurs
/interface/bridge/vlan add bridge=bridge1 vlan-ids=10 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3

# VLAN 12 (STOCKAGE) — tagged sur les 3 serveurs 
/interface/bridge/vlan add bridge=bridge1 vlan-ids=12 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3

Pour mon besoin, j'ajoute également la dernière interface 10G (la 8) au bridge1. C'est mon lien d'interconnexion avec mon lab actuel. C'est un trunk dont on a besoin pour laisser passer tous les VLANs.

On lie l'interface 8 au bridge1 (pvid=1 : le trafic sans tag arrivant sur ce port sera mis dans le VLAN 1) :

/interface/bridge/port add bridge=bridge1 interface=sfp-sfpplus8 pvid=1 hw=yes

On enchaine avec les commandes qui définissent comment les étiquettes 802.1Q sont traitées:

# --- VLAN 1 (Management / Natif) ---
/interface bridge vlan
set [find vlan-ids=1] tagged=bridge1 untagged=sfp-sfpplus8

# --- VLAN 10 (DMZ_FIRST) ---
/interface bridge vlan
set [find vlan-ids=10] tagged=bridge1 untagged=sfp-sfpplus8

# --- VLAN 6 (DMZ_web) ---
/interface bridge vlan
set [find vlan-ids=6] tagged=bridge1 untagged=sfp-sfpplus8

On définit le VLAN 1 comme « Accès/Natif » sur tous ces ports. Le trafic sortira sans étiquette vers les équipements connectés:

/interface/bridge/vlan
set 0 tagged=bridge1 untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus8

On définit le VLAN 10 comme « Taggué » sur tous ces ports en s'assurant qu'aucun d'eux ne laisse sortir le VLAN 10 sans tag:

/interface/bridge/vlan
set 2 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus8 untagged=""

La même pour le VLAN 6:

/interface/bridge/vlan
set 1 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus8 untagged=""

(set 2 correspond à l'ID de VLAN 10, set 1 à l'ID de VLAN 6, set 0 à l'ID de VLAN 1. C'est l'index du VLAN dans la conf du switch, la corrélation est visible avec la commande /interface/bridge/vlan print.)

Pas besoin de mettre le VLAN 12 dans le trunk, il est local au switch entre les nodes XCP-ng.

On finit par activer la MTU 9000 sur toutes les interfaces 10G (on l'a déjà activé au niveau global et du bridge1, mais il faut aussi le faire sur les ports). Un peu déroutant: il faut mettre 9100 pour être au-dessus de 9000:

/interface ethernet set [find where name~ "sfp-sfpplus"] mtu=9100

Enfin, on active le vlan-filtering pour rendre notre switch virtuel bridge1 intelligent:

/interface bridge set bridge1 vlan-filtering=yes

Pour contrôler l'ensemble, on peut utiliser la commande suivante. Le champ HW doit être à yes partout.

/interface bridge port print

À noter que, bien entendu, j'ai fait une configuration compatible côté autre switch de mon lab (des ZYXEL XGS1210-12) pour que le trunk fonctionne.

XCP-ng/XO

On peut maintenant revenir dans l'interface de Xen Orchestra, où l'on va manipuler la configuration réseau du pool. Pour ça, on va devoir se remettre sur la version 5 de la GUI XO.

Suppression de la configuration par défault eth1

On va commencer par supprimer la configuration par défaut qui s’est appliquée sur eth1. Pour cela on se rend dans les paramétres réseau de chaque serveur, on sélectionne la PIF eth1, puis on clique sur Remove.

Ensuite au niveau du pool, on renomme la carte eth1 en eth1-10G pour une meilleur lisibilité. On en profite également pour passer l'interface à une MTU de 9000

On retourne dans chaque conf de serveur, au niveau réseau, pour faire un refresh des pifs

Quand l'interface apparait, on clique sur Connected

Création des vlans

On va utiliser le menu New puis Network en sélectionnent ensuite notre pool. Pour chaque VLAN, on va ajouter une interface, basée sur l'interface eth1 (le nom du serveur XCP-ng est le nom du master de votre pool). L'idée va être de le faire pour chaque VLAN en indiquant son ID ainsi que son MTU: 1500 par défaut, 9000 pour le VLAN de stockage.

À la fin on a ce résultat (ne pas hésiter à remplir la case description).

Pour ceux qui chercheraient à faire un rapprochement avec l'univers VMware, disons qu'on vient de configurer des port groups destinés au trafic des VMs, hors VLAN de storage.

Il nous manque d'ailleurs une configuration finale pour le VLAN dédié au storage. En effet, contrairement aux autres VLANs rattachés à des VMs, le VLAN 12 sera utilisé par les serveurs XCP-ng eux-mêmes. Ces derniers vont devoir disposer d'une IP sur ce VLAN (du moins le Dom0). Pour ça, on passe en mode CLI, en SSH sur le master du pool, puis on passe les commandes suivantes :

xe pif-reconfigure-ip uuid=$(xe pif-list device=eth1 VLAN=12 host-uuid=$(xe host-list name-label=prdxcpsrv003 --minimal) --minimal) mode=static IP=192.168.12.3 netmask=255.255.255.0
xe pif-reconfigure-ip uuid=$(xe pif-list device=eth1 VLAN=12 host-uuid=$(xe host-list name-label=prdxcpsrv002 --minimal) --minimal) mode=static IP=192.168.12.2 netmask=255.255.255.0
xe pif-reconfigure-ip uuid=$(xe pif-list device=eth1 VLAN=12 host-uuid=$(xe host-list name-label=prdxcpsrv001 --minimal) --minimal) mode=static IP=192.168.12.1 netmask=255.255.255.0

De cette manière, chaque VM du Dom0 des serveurs XCP-ng disposera d'une adresse IP en 192.168.12.0 attachée à l'interface eth1 avec un tag sur le VLAN 12.

On peut contrôler le tout en se connectant en SSH sur les différents nodes en exploitant la commande de ping à destination des IP du VLAN 12. En ajoutant l'option -s 8972, on force la taille des paquets au-delà de 1500, ce qui nous permet en même temps de valider que la MTU est OK:

ping -s 8972 -M do 192.168.12.2
ping -s 8972 -M do 192.168.12.3

Contrôles

Migration de VM

Afin de valider le bon fonctionnement de l'ensemble, on va monter une VM cette fois directement à partir de Xen Orchestra (GUI v5.0). On va jouer avec les interfaces réseau, tout en déplaçant la VM d'un serveur à un autre, histoire de voir si tout est OK.

Création de la VM témoin

Pour ce faire, on va partir d'un OS que j'apprécie de plus en plus : Zorin OS. Au moment de la rédaction de cet article, je ne comprends plus ce que fait Microsoft avec Windows 11, surtout en milieu professionnel. L'OS s'alourdit de plus en plus, impose des restrictions d'accès au web, même pour un usage professionnel. Jusqu'à présent, j'avais trouvé une alternative avec Tiny11, un script qui permet d'offrir une version de Windows 11 débarrassée de tout le superflu, mais, désormais, je préfère Zorin OS.

J'en profite donc pour faire une petite parenthèse sur ce système d'exploitation basé sur Ubuntu et qui offre à mon sens aujourd'hui l'une des meilleures intégrations possibles de Linux pour un usage UI de travail. Je vous invite à l'essayer.

Pour déployer notre VM de test, il suffit de cliquer sur New VM. Zorin OS n'est pas inscrit dans la liste des templates disponibles, mais la version 18 de ce dernier que je vais utiliser est basée sur Ubuntu 24.04, on peut donc retenir ce template.

Il suffit ensuite de paramétrer une configuration matérielle, ici 2 vCPU et 3 Go de RAM. Puis, connecter l'ISO de l'OS hébergé sur le SR NFS mis en œuvre lors d'une étape précédente. On connecte l'interface réseau à l'étiquette LAN. Enfin, on sélectionne le SR local du serveur prdxcpsrv001 en configurant une taille de disque de 30 Go (ZorinOS 18 réclame 14 Go minimum).

On valide notre configuration et on est de suite amené sur la page de la VM, où on va se rendre dans la console pour suivre le boot de l'OS. On rentre alors dans un process d'installation de système d'exploitation classique. Celui de ZorinOS est très simple à suivre et à mettre en œuvre.

Et pour démontrer la capacité de ZorinOS à s'intégrer dans un environnement AD, je vais même enregistrer la VM sur mon domaine. Bonne nouvelle, des paquets se téléchargent durant l'installation, ce qui est plutôt bon signe pour l'accès réseau.

Une fois terminé, on peut retirer l'ISO de la VM. Au premier démarrage, d'autres mises à jour sont trouvées, ce qui confirme notre accès à internet. D'ailleurs un petit ip addr nous montre que la VM a bien une IP sur le subnet 192.168.10.0 comme attendu.

Pour compléter l'installation, on peut monter l'ISO dédiée aux tools XCP, un peu comme les VMware Tools. On peut essayer de lancer le script d'installation présent avec les binaires, mais celui-ci ne reconnaît pas ZorinOS. Ce n'est pas un souci, il suffit d'exploiter le package .deb disponible avec la commande :

dpkg -i <package.deb>

Ensuite, vérifiez que le service xe-linux-distribution est bien actif et activé au démarrage. Si tout est OK, on a normalement la version de l'agent qui remonte dans les informations générales de la VM. On peut éjecter l'ISO des tools ensuite.

Migration de la VM

Maintenant qu'on sait que le réseau LAN est OK, on va tester le déplacement de VM à chaud. La VM est actuellement exécutée sur le premier serveur prdxcpsrv001, puisqu'hébergée sur le disque local (le SR) du serveur. On va donc chercher à déplacer la VM sur prdxcpsrv002, en déplaçant à la fois le contexte de la VM et sa data.

En l'état, si on essaie, c'est le lien 1G qui va être utilisé, ce qui est dommage puisqu'on a une carte 10G avec en plus un réseau dédié au storage entre les nodes. Même si, pour l'instant, on n'a pas paramétré de solution de réplication de blocs, on pourrait au moins s'en servir pour déplacer les VMs.

Pour ça, on se connecte en SSH sur le master du pool (dans les captures, je suis sur prdxcpsrv002 car entre-temps j'ai fait des tests qui ont fait basculer le master sur le second serveur, mais ce n'est pas un souci).

On liste les réseaux :

xe network-list params=uuid,name-label,bridge

On liste les UUID des hosts :

xe host-list params=uuid,name-label

On fait l'association de l'UUID du VLAN storage (e140fba2-482f-66bc-1869-c80d2f1cf674) avec chaque UUID des hosts pour indiquer qu'on va l'utiliser comme réseau de migration :

xe host-param-set uuid=503e202a-7ad2-4dbf-a575-ed81df29e89d other-config:migration_network_uuid=e140fba2-482f-66bc-1869-c80d2f1cf674
xe host-param-set uuid=0b1350b3-0e6a-4343-a51b-321740185b24 other-config:migration_network_uuid=e140fba2-482f-66bc-1869-c80d2f1cf674
xe host-param-set uuid=3e0daa17-41a7-45a8-b2fb-bef287aa11e6 other-config:migration_network_uuid=e140fba2-482f-66bc-1869-c80d2f1cf674

Tout est prêt pour notre test. On lance un ping continu entre la VM et mon PC fixe présent sur le même subnet, pour suivre les coupures potentielles.

Dans les options Advanced de la VM, on clique sur Warm migration, on fait bien attention à sélectionner les options de suppression à la source et de démarrage automatique à la destination. On cible le SR local de prdxcpsrv002 et on lance.

Ce qui déclenche aussitôt des tâches visibles dans la GUI XO. Les données vont donc être copiées d'un SR à un autre, pour ensuite permettre la reprise de la VM sur prdxcpsrv002. La suite va consister à démarrer le contexte de la VM sur prdxcpsrv002 et nettoyer les restes sur prdxcpsrv001.

On n'est pas sur une opération à zéro coupure de service. Dès lors que les données sont copiées sur le SR de prdxcpsrv002, la VM est coupée de prdxcpsrv001 pour être redémarrée dans l'état du snapshot qui a été fait au moment du lancement de la migration sur le nœud de destination où les données viennent d'être placées. On a une coupure franche durant 2 min 51 pour notre test.

La VM est également redémarrée, mais l'essai est concluant. Il faut bien rappeler que, pour l'instant, on ne dispose pas d'un stockage partagé pour l'exécution des VMs entre les nœuds du pool. On a bien déplacé une VM d'un stockage local à un autre entre deux serveurs.

Dernière petite chose à faire, renommer correctement la VM sur prdxcpsrv002, puisque XO lui laisse par défaut une nomenclature à rallonge.

Changement de réseau

Maintenant que la VM a été déplacée, tentons de la changer de réseau. Pour cela, rien de plus simple : on va dans les paramètres de la VM puis dans l'onglet réseau, on change l'étiquette associée à la VIF (Virtual Interface). On la place, par exemple, sur le VLAN_WEB.

Un petit forçage de déconnexion/reconnexion sur la VM au niveau de ZorinOS, et elle dispose maintenant d'une IP en 192.168.5.0.

Conclusion

On a désormais une configuration réseau fonctionnelle, partagée au sein du pool xcp. On est déjà en mesure de déplacer les VMs d'un serveur à un autre, certes avec une coupure, mais chaque serveur peut reprendre, via une opération manuelle, la VM d'un autre.

On n'est pas au niveau d'une plateforme VMware et d'un storage vMotion, et on pourrait trouver le nom « Warm migration » un peu trompeur. L'ergonomie de l'option est un peu particulière également (si vous ne cochez pas les cases d'arrêt à la source et de redémarrage à la destination, vous finissez avec un message d'erreur). Vivement la bascule complète sur la GUI de XO 6

Néanmoins, la base est là, et il ne reste plus qu'à configurer un espace de stockage partagé pour offrir une expérience HA complète. Mais ça, c'est pour le prochain article.