XCP-ng: Evolution du Lab V2.0 - Installation OS et déploiement de la VM pour Xen Orchestra

Introduction

Maintenant que l'article précédent a permis d'établir la cible et d'expliquer l'architecture à mettre en place, il nous est permis d'enchainer avec l'installation des serveurs.

XCP-ng ne présente pas de difficultés spécifiques d'installation.

Il suffit de récupérer l'ISO, puis de la copier sur une clef USB avec un utilitaire comme Rufus.

On est sur une même logique d'installation que n'importe quel OS Linux.

Base de XCP-ng

D'ailleurs il est important de noter que XCP-ng 8.3, qui est la dernière version LTS en date à l'écriture de cet article, est basé sur CentOS 7.0.

Certains prendront peut-être peur, sachant que CentOS 7.0 est « end of life » depuis pas mal de temps pour le grand public, mais Vates maintient ses propres dépôts et assure la sécurité des paquets.

Ce choix garantit une stabilité maximale pour les outils de gestion (XAPI) qui ont été historiquement développés pour cette base.

Principe du Dom0

D'ailleurs ce socle CentOS 7.0 ne contient pas l'hyperviseur, il s'exécute par-dessus. En effet, dans l'univers de Xen, l'hyperviseur à la base de XCP-ng, on parle de Dom0 (abréviation de Domain 0), soit une machine virtuelle privilégiée qui démarre automatiquement au lancement du serveur.

Considérez-le comme le "cerveau" ou le "poste de pilotage" de votre serveur.

C'est à cette VM que vous accédez une fois l'installation de XCP-ng terminée.

C'est dans cette dernière qu'est déployé l'API de gestion XAPI qui communique avec le reste de l'écosystème XCP.

Le cœur de l'hyperviseur Xen lui, n'a ni shell ni possibilité d'accès direct.

Toutes les autres VMs qu'on pourrait ensuite déployer s'exécuteront elles dans des domaines dits DomainU, soit des domaines non privilégiés.

La base CentOS 7.0 du Domain0 reste extrêmement customisée et adaptée par Vates, notamment avec un kernel spécifique. Il est possible d'installer des paquets traditionnels sur cette VM, mais il est néanmoins recommandé de ne pas trop la personnaliser et de la laisser au plus près de sa configuration de base.

Installation de l'OS

Pour en revenir à l'installation à partir de l'iSO, une fois mise sur une clef USB, il suffit de booter le serveur dessus (soit pour moi sur mes Lenovo ThinkCenter M920qp présentés précédemment).Reste à suivre le wizard d'installation.

En bref, on fixe un mot de passe et on choisit l'IP d'administration. Ensuite, on laisse se dérouler la copie des binaires sur le disque local.

Pour l'IP, on exploite la carte réseau intégrée des Lenovo. Cela nous permettra d'avoir une interface d'administration dédiée, non mutualisée avec la carte 10Go réservée au flux de production et à la réplication du stockage.

Petite subtilité, néanmoins. Par défaut, en plus de la taille prise par l'installation de base sur le disque (entre 40Go et 70Go), l'installateur va proposer la création d'un SR, (pour Storage Repository), soit l'équivalent d'un datastore chez VMware, dédié à l'hébergement des futures VMs qui s'exécuteront sur le serveur pour lequel on réalise l'installation.

Or, dans mon architecture, je souhaite fixer ce paramétrage plus tard, puisque, comme expliquer dans mon précédent article, je compte séparer l'espace restant sur mes disques système en deux parties:

• Une partie pour un SR local
• Une partie pour un SR reposant sur une technologie de réplication de blocs pour offrir un stockage répliqué entre mes différents serveurs constituant mon pool XCP-ng : on aura l'occasion de voir ce point dans un article dédié.

On va donc décocher la création automatique du SR à l'installation.

Une fois terminé, on peut accéder à la GUI de chaque serveur. En effet, XCP-ng est fourni avec une interface minimaliste, appelée XO-lite qui permet d'avoir une vue sur le serveur et de démarrer de premières opérations, un peu comme un ESXi gratuit.

Le compte à utiliser est celui que vous avez paramétré à l'installation de XCP-ng

Hormis pour vérifier que tout est OK et que les serveurs sont bien en lignes, on va plutôt agir via ssh pour la suite des opérations.

Pour rappel, notre but final n'est pas de traiter chaque serveur individuellement, mais de les agréger dans un pool qu'on pourra administrer via la solution Xen Orchestra, à l'image d'un vCenter pour un cluster VMware.

Premiere connexion et mise à jour

On s'authentifie donc en SSH sur chacun des serveurs déployés (prdxcpsrv001, prdxcpsrv002, prdxcpsrv003) ou plutôt sur chaque VM dom0.

De là les opérations vont être identiques sur chaque serveur et donc à reproduire sur chaque connexion.

Déjà, premier réflexe, on met à jour la distribution. Même si l'installation vient d'être réalisée, des paquets sont très régulièrement corrigés.

Pour cela, rien de plus simple qu'un yum update suivi d'un petit redémarrage de sécurité.

Création du SR Local

Ensuite le but va être de créer un SR local à chaque serveur avec un espace de 150Go (je rappelle que chaque serveur dispose d'un disque SSD de 1TO, dont 46Go environ est déjà pris par l'installation de XCP-ng).

Étant donné qu'on se trouve sur un système Linux du type CentOS, on peut appliquer les méthodes classiques de manipulation des partitions sous ce système d'exploitation. Comme le Dom0 dispose de privilèges spécifiques, il accède directement au matériel du serveur, on peut donc agir directement sur la structure du disque local.

On fait un petit lsblk pour découvrir le partitionnement par défaut.

On voit bien qu'il reste de l'espace et qu'on a simplement quelques partitions de base.

S'agissant d'un disque NVMe, il est référencé sous /dev/nvme0n1. À vous d'adapter en fonction de vos configurations.

On utilise l'outil fdisk pour créer une nouvelle partition qui ne prendra pas tout l'espace disponible, mais qui s'étendra sur 150 Go.

fdisk /dev/nvme0n1

Dans mon cas, il s'agit de la 4e partition du disque.

Côté fdisk, je vais donc enchainer les commandes suivantes

n
4
+150G
t
4
8e
W

Puis on quitte fdisk pour forcer une lecture des partitions.

partprobe /dev/nvme0n1

Pour rester dans le classique, on va enchainer sur l'usage de LVM plutôt que de traiter la partition en direct.

On crée donc un nouveau pv (Physical Volume) rattaché à cette nouvelle partition.

pvcreate /dev/nvme0n1p4

pv qu'on va dédié à un vg (Volume Group)

vgcreate VG_Local_PRD /dev/nvme0n1p4

Nous voilà prêts pour créer notre SR local, et c'est à partir de ce point qu'on rentre dans le spécifique de XCP-ng et de Xen.

D'abord on récupère l'uuid du serveur sur lequel on se trouve. Pour cela, on utilise la commande xe host-list

Ensuite, nous allons exécuter la commande xe sr-create en la configurant pour qu'elle pointe vers notre volume de stockage local (Local-Storage-PRD) et notre identifiant d'hôte unique (ici 503e202a-7ad2-4dbf-a575-ed81df29e89d). Nous la nommerons Local-Storage-PRD et la définirons comme un type LVM avec le périphérique /dev/nvme0n1p4.

xe sr-create name-label="Local-Storage-PRD" \
type=lvm \
device-config:device=/dev/nvme0n1p4 \
host-uuid=503e202a-7ad2-4dbf-a575-ed81df29e89d \
shared=false
            

On peut contrôler la création du sr avec la commande

xe sr-list name-label="Local-Storage-PRD"

On peut obtenir des informations sur la taille et l'usage

xe sr-list uuid=7631f311-da3a-80ee-2db0-024e61da871e params=name-label,physical-size,physical-utilisation

Arrivé à cette étape, on a donc trois SR local à raison d'un par serveur, s'appelant tous Local-Storage-PRD et affichant une volumétrie de 150Go.

On pourrait donc dès à présent monter des VMs, spécifique à chaque node, en les hébergeant sur ce SR.

Déploiement de la VM pour XenOchestra

On va maintenant se focaliser sur le premier serveur (prdxcpsrv001), celui qu'on retiendra par la suite comme master de notre pool XCP-ng et qui va avoir la charge d'exécuter la VM hébergeant la solution de gestion Xen Orchestra.

Xen Orchestra peut être déployée sous forme d'appliance, mais, dans ce cas, une licence est requise pour accéder à toutes ses fonctions (c'est la méthode à privilégier en entreprise). Sinon, elle peut s'exécuter directement sur un serveur Linux à partir des sources du produit. Dans ce second cas, pas besoin de licences pour avoir 100% des fonctions, mais une installation plus complexe et plus longue qui va déjà nécessiter de déployer une VM.

La base OS sera un Rocky Linux 10, qui va s'exécuter sur le premier serveur XCP-ng et qui va exploiter le nouveau SR local à ce dernier.

Mais en plus du besoin de stockage local, il faudra aussi pouvoir monter l'ISO de Rocky Linux 10.

Création du SR pour l'image ISO

C'est pour ça que, sur ce premier serveur XCP-ng, toujours en SSH on va créer un nouveau SR, mais qui lui pointera sur un volume NFS hébergé sur mon NAS (un Terramaster F4) dans lequel se trouvera l'ISO de Rocky Linux 10.

On refait donc appel à la commande xe sr-create mais cette fois-ci avec des arguments différents et pointant vers l'IP du NAS en indiquant le volume à utiliser.

xe sr-create name-label="NFS-ISO-Library" \
type=iso \
device-config:location=192.168.10.152:/Volume1/nfsshare/tools/ISOs \
device-config:nfsversion=3 \
content-type=iso

Noter qu'on précise via l'option content-type qu'il va s'agir d'un SR dédié aux iSOs.

Bien entendu, il faut s'assurer que le volume NFS soit accessible à l'IP du serveur XCP-ng. La configuration dépendra de votre solution NFS.

J'ai déjà placé l'ISO de Rocky Linux dans le dossier partagé. Pour que XCP-NG puisse l'exploiter, il faut d'abord forcer le rafraichissement du contenu avec la commande.

xe sr-scan uuid=$(xe sr-list name-label="NFS-ISO-Library" --minimal)

De là on peut vérifier que l'ISO est bien détectée.

xe vdi-list sr-uuid=$(xe sr-list name-label="NFS-ISO-Library" --minimal)

C'est parfait, tout est prêt pour créer notre première VM, sur le premier serveur XCP-ng qu'on vient de déployer.

Création de la VM

La ligne de commande va continuer d'être notre allié avec les instructions

VM_UUID=$(xe vm-install template="Other install media" new-name-label="prdxcpxor501")

Cette première commande va créer la coquille de la VM, que j'appelle prxcpxor501 et stocker son uuid dans la variable VM_UUID

À noter que Rocky Linux 10 étant assez récent, il ne figure pas dans la liste des gabarits connus de XCP-ng au moment de la rédaction de cet article, d'où l'utilisation du template Other install media.

Dans XCP-ng un template va permettre de reconfigurer une VM avec les bons paramètres matériels en fonction de l'OS qui va s'y exécuter.

Pour autoriser son démarrage, on va configurer l'usage de 2 vCPU

xe vm-param-set uuid=$VM_UUID VCPUs-max=2

xe vm-param-set uuid=$VM_UUID VCPUs-at-startup=2

Côté RAM, par défaut, une limite est à 4Go, liés au template. Mais s'il y avait nécessité, on pourrait utiliser la commande.

xe vm-memory-limits-set uuid=$VM_UUID \
static-min=4GiB \
static-max=4GiB \
dynamic-min=4GiB \
dynamic-max=4GiB

Dans XCP-ng, la gestion de la RAM est un peu plus complexe qu'un simple chiffre, car elle permet la "mémoire dynamique" (Dynamic Memory Control). Voici ce que la commande ci-dessus modifie :

• Static MAX : la limite physique absolue (la VM ne verra jamais plus que ça).
• Dynamic MAX : la limite haute que la VM peut atteindre sans redémarrage.
• Dynamic MIN : le minimum que la VM peut accepter de libérer si l'hôte manque de RAM.
• Static MIN : le seuil de survie en dessous duquel la VM ne peut pas démarrer.

Par défaut, si vous ne travaillez pas avec une mémoire dynamique, il est conseillé de fixer ces quatre valeurs à la même taille (comme dans l'exemple).

On peut lister la VM pour savoir si elle est bien déclarée

xe vm-list name-label="prdxcpxor501"

Création du disque virtuel

On passe à la configuration du disque.

On crée un volume virtuel de 30Go

VDI_UUID=$(xe vdi-create sr-uuid=68fd19d4-ed9d-168f-c178-f6824246043e name-label="prdxcpxor501-boot-disk" type=system virtual-size=30GiB)

À noter que l'option sr-uuid pointe vers l'UUID du sr local créé précédemment associé au serveur et au label Local-Storage-PRD : si vous avez besoin de le retrouver, vous pouvez utiliser la commande xe xr-list name-label="Local-Storage-PRD"

Comme on récupre l'uuid du disque créé, on peut le rattacher à la VM via la commande

xe vbd-create vm-uuid=$VM_UUID vdi-uuid=$VDI_UUID device=0 bootable=true type=Disk

Création de l'interface réseau virtuelle

Vient maintenant le tour du réseau.

Comme il va s'agir de la VM d'administration de XenOrchestra et qu'à ce stade on n'a pas configuré d'autre réseau que celui porté par la carte Ethernet intégrée du serveur, on va commencer par récupérer l'UUID de ce réseau par défaut.

NET_UUID=$(xe network-list name-label="Pool-wide network associated with eth0" --minimal)

Ensuite, on crée une interface virtuelle liée à ce réseau (une vif) qu'on va mapper sur notre VM.

            xe vif-create vm-uuid=$VM_UUID network-uuid=$NET_UUID device=0
            

Mappage de l'ISO

Nous allons également monter l'ISO de Rocky Linux.

Pour ça on récupère l'UUID de cette dernière via la commande

xe vdi-list sr-uuid=$(xe sr-list name-label="NFS-ISO-Library" --minimal)

On identifie l'UUID et on utilise la commande suivante

xe vbd-create vm-uuid=$VM_UUID \
vdi-uuid=889a665e-f230-4235-b994-de243e1f6b06 \
device=3 \
bootable=false \
mode=RO \
type=CD

Paramétrage de boot

Enfin, on va fixer l'ordre de boot avec les commandes

xe vm-param-set uuid=$VM_UUID HVM-boot-policy="BIOS order"
xe vm-param-set uuid=$VM_UUID HVM-boot-params:order=dc

HVM : signifie Hardware Virtual Machine. C'est le mode de virtualisation complet (utilisé pour Windows ou les Linux modernes).

Dans la première commande, on indique à Xen d'utiliser un comportement de bios standard pour cette VM.

Dans la seconde, on fixe l'ordre de boot à

• d : pour le lecteur cdrom, donc l'ISO
• c : pour le disque.

Il est temps de démarrer la VM avec les instructions

xe vm-start uuid=$VM_UUID

Installation de Rocky Linux

À partir de cette étape, on peut exploiter la GUI intégré du premier serveur (XO Lite).

Celle-ci va nous permettre d'accéder à la console de la VM et donc de dérouler le process d'installation de rocky Linux 10

Je ne vais pas le détailler ici, on reprend un déploiement d'un Linux avec les options habituelles.

Je fixe simplement une IP sur mon LAN pour l'accès à la VM en ssh par la suite, en créant mon utilisateur.

Opérations de fin d'installation

Une fois l'installation terminée et le reboot de la VM réalisée.

On peut revenir au shell de XCP-ng, puis éjecter l'ISO

xe vm-list name-label=prdxcpxor501 --minimal
VM_UUID=$(xe vm-list name-label=prdxcpxor501 --minimal)
VBD_CD_UUID=$(xe vbd-list vm-uuid=$VM_UUID type=CD --minimal)
xe vbd-eject uuid=$VBD_CD_UUID

On peut en profiter pour retirer le cdrom de l'option de boot

xe vm-param-set uuid=$VM_UUID HVM-boot-params:order=c

Conclusion

C'est la fin de cette seconde partie décrivant l'installation de mon lab V2.0 sous XCP-ng.

Arrivé à ce stade, je peux accéder en SSH à ma VM prdxcpxor501

Celle-ci a été créée entièrement en ligne de commande via l'usage de la VM Dom0 disponible sur mon premier serveur XCP-ng.

Bien entendu, l'idée n'est pas de construire toutes les futures VMs de cette manière.

Avec prdxcpxor501 fonctionnelle, je peux maintenant installer la solution d'administration centralisée Xen Orchestra pour me permettre de créer mon pool XCP avec mes trois serveurs et de rentrer dans un usage bien plus pratique de création de VMs.

Mais pour ça, il faudra suivre le prochain article qui détaillera l'installation et la configuration de Xen Orchestra.