Comment créer et installer des machines virtuelles invitées dans XenServer - Partie 5

Poursuivant sur la lancée de la série XenServer, cet article abordera la création des invités eux-mêmes (souvent appelés machines virtuelles).

Mise à jour : En mai 2016, Citrix a publié la nouvelle version de la plate-forme XenServer 7. Pour l’installation, suivez : Nouvelle installation de XenServer 7.

Cet article suppose que tous les articles précédents couvrant la mise en réseau, l’application de correctifs et le stockage ont été terminés. Heureusement, il n’y a plus vraiment besoin de discuter de nouvelle terminologie et la création des invités peut commencer !

Examen du système

À ce stade, beaucoup de choses ont été configurées sur cet hôte XenServer. Cela servira de révision rapide de ce qui a été configuré et de l’article sur lequel le sujet a été abordé.

1. XenServer 6.5 a été installé sur le serveur
1. https://linux-console.net/citrix-xenserver-installation-and-network-configuration-in-linux/
2. Tous les correctifs de XenServer 6.5 ont été appliqués
1. https://linux-console.net/install-xenserver-patches-in-linux/
3. L’association d’interfaces réseau et les VLAN ont été créés
1. https://linux-console.net/xenserver-network-lacp-bond-vlan-and-bonding-configuration/
4. Des référentiels de stockage iSCSI et ISO ont été créés pour stocker les fichiers d’installation du système d’exploitation et les disques durs virtuels utilisés par les invités
1. https://linux-console.net/xenserver-create-and-add-storage-repository/

Création d’invités virtuels dans XenServer

Cette partie du guide s’appuiera sur les installateurs ISO pour démarrer la machine invitée nouvellement créée et installer un système d’exploitation. N’oubliez pas de consulter le quatrième article pour plus d’informations sur la création d’un référentiel ISO.

XenServer est livré avec une série de modèles qui peuvent être utilisés pour provisionner rapidement un invité virtuel. Ces modèles fournissent des options communes pour le système d’exploitation choisi. Les options incluent des éléments tels que l’espace sur le disque dur, l’architecture du processeur et la quantité de RAM disponible, entre autres options.

Ces options peuvent être modifiées manuellement par la suite, mais pour l’instant, un modèle simple sera utilisé pour illustrer leur utilisation. Pour obtenir la liste des modèles disponibles, la commande traditionnelle 'xe' peut être passée en différents arguments pour inciter le système à renvoyer les modèles disponibles.

xe template-list

Cette commande est susceptible de renvoyer beaucoup de sortie. Pour faciliter la lecture de la sortie, il est suggéré de la canaliser dans 'less' comme suit :

xe template-list | less

Cela permettra d’analyser plus facilement les modèles disponibles pour localiser les informations UUID nécessaires. Cet article va fonctionner avec Debian 8 Jessie, mais nécessitera l’utilisation de l’ancien modèle Debian 7 Wheezy jusqu’à ce que Citrix publie le nouveau modèle.

La sélection de Debian 7 n’affectera rien au fonctionnement du système d’exploitation réel. (La capture d’écran ci-dessous a utilisé l’UUID dans la commande pour couper une partie de la sortie normale).

xe sr-list name-label=”Tecmint iSCSI Storage”

Avec cet UUID, toutes les informations initiales pour configurer cet invité ont été obtenues. Comme pour presque tout dans XenServer, une autre commande 'xe' sera utilisée pour provisionner le nouvel invité.

xe vm-install template=”Debian Wheezy 7.0 (64-bit)” new-name-label="TecmintVM" sr-uuid=bea6caa4-ecab-8509-33a4-2cda2599fb75

L’UUID en surbrillance est l’UUID de l’invité nouvellement provisionné. Il y a quelques étapes d’entretien ménager qui peuvent potentiellement faciliter les choses à l’avenir. La première consiste à fournir une étiquette de nom à la VDI nouvellement créée et la seconde à modifier l’une des spécifications matérielles par défaut provisionnées par le modèle.

Pour comprendre pourquoi il serait important de nommer le VDI, examinez ce que le système attribue automatiquement au VDI lorsqu’il est provisionné à l’aide des commandes « xe » suivantes :

xe vbd-list vm-name-label=TecmintVM – Used to get the VDI UUID
xe vdi-list vbd-uuids=2eac0d98-485a-7c22-216c-caa920b10ea9    [Used to show naming issue]

Une autre option disponible est de rassembler les deux éléments d’information à l’aide de la commande suivante :

xe vm-disk-list vm=TecmintVM

La partie en jaune est le souci. Pour beaucoup de gens, ce problème est mineur, mais à des fins d’entretien ménager, un nom plus descriptif est souhaitable pour garder une trace de l’objectif de ce VDI particulier. Pour renommer ce VDI particulier, l’UUID dans la sortie ci-dessus est nécessaire et une autre commande 'xe' doit être créée.

xe vdi-param-set uuid=90611915-fb7e-485b-a0a8-31c84a59b9d8 name-label="TecmintVM Disk 0 VDI"
xe vm-disk-list vm=TecmintVM

Cela peut sembler trivial à configurer, mais par expérience, cela a permis d’éviter un problème sérieux lors de la déconnexion d’un référentiel de stockage d’un XenServer et de la tentative de l’attacher à un autre XenServer. Dans ce scénario particulier, une sauvegarde des métadonnées de toutes les informations sur les invités n’a pas pu être restaurée sur le nouveau XenServer et, heureusement, en nommant le VDI sur chacun des invités, le mappage correct de l’invité à son VDI a pu être effectué simplement par l’étiquette de nom.

La prochaine étape de ménage pour cet article est de fournir à cet invité particulier plus de ressources. Tel qu’il est provisionné, cet invité ne disposera que d’environ 256 Mio (Mébioctets) de mémoire. Pour la plupart des clients, ce n’est pas suffisant, il est donc utile de savoir comment augmenter la mémoire disponible d’un client. Comme pour tout ce qui se trouve dans XenServer, cela peut être accompli avec les commandes 'xe'.

xe vm-param-list uuid=6eab5bdd-c277-e55d-0363-dcfd186c8e8e | grep -i memory

La case en vert ci-dessus indique que la mémoire maximale que cet invité particulier pourrait avoir est d’environ 256 Mio. À des fins de test, ce serait bien, mais pour tout type de système à usage intensif, cela s’avérerait insuffisant.

Pour modifier cette valeur afin de donner à l’invité l’accès à plus de RAM, une simple commande « xe » peut être émise lorsque l’invité est éteint. Dans cet exemple, la quantité de RAM à donner à cette machine sera représentée en octets mais sera égale à 2 Gibioctets de RAM.

xe vm-memory-limits-set dynamic-max=2147483648 dynamic-min=2147483648 static-max=2147483648 static-min=2147483648 name-label=TecmintVM

Notez que cela réservera deux Go de RAM pour cet invité tout le temps.

Maintenant, cet invité particulier est prêt à avoir un système d’exploitation installé. D’après l’article précédent sur les dépôts de stockage, un partage Samba a été ajouté à ce XenServer pour stocker les fichiers d’installation ISO. Cela peut être confirmé avec la commande 'xe' suivante :

xe sr-list name-label=Remote\ ISO\ Library\ on:\ //<servername>/ISO

Veillez à remplacer <servername> par le nom du serveur Samba approprié pour l’environnement dans lequel cette configuration a lieu. Une fois que XenServer est confirmé pour voir le référentiel de stockage ISO, un CD-ROM virtuel doit être ajouté à l’invité afin de démarrer le fichier ISO. Ce guide suppose que l’ISO de l’installateur réseau Debian existe sur le dépôt de stockage ISO.

xe cd-list | grep debian

xe vm-cd-add vm=TecmintVM cd-name=debian-8-netinst.iso device=3
xe vbd-list vm-name-label=TecmintVM userdevice=3

Les commandes ci-dessus indiquent d’abord le nom de l’ISO Debian. La commande suivante ajoutera un périphérique CD-ROM virtuel à l’invité TecmintVM et lui attribuera l’ID de périphérique 3.

La troisième commande est utilisée pour déterminer l’UUID du CD-ROM nouvellement ajouté afin de continuer à configurer le périphérique pour démarrer l’ISO Debian.

L’étape suivante consiste à rendre le CD-ROM amorçable et à demander à l’invité d’installer un système d’exploitation à partir du CD-ROM.

xe vbd-param-set uuid=3836851f-928e-599f-dc3b-3d8d8879dd18 bootable=true
xe vm-param-set uuid=6eab5bdd-c277-e55d-0363-dcfd186c8e8e other-config:install-repository=cdrom

La première commande ci-dessus définit le CD-ROM pour qu’il soit amorçable en utilisant son UUID surligné en vert dans la capture d’écran ci-dessus. La deuxième commande indique à l’invité d’utiliser le CD-ROM comme méthode d’installation du système d’exploitation. L’UUID de l’invité Tecmint est mis en évidence dans la capture d’écran ci-dessus en jaune.

La dernière étape de la configuration de l’invité consiste à attacher une interface réseau virtuelle (VIF). C’est particulièrement important pour cette méthode d’installation, car l’installateur du réseau Debian est utilisé et devra extraire des paquets des dépôts Debian.

En revenant à l’article sur le réseau XenServer, un VLAN spécial a déjà été créé pour cet invité et il s’agissait du VLAN 10. À l’aide de 'xe', l’interface réseau nécessaire peut être créée et attribuée à cet invité.

xe network-list name-description="Tecmint test VLAN 10"
xe vif-create vm-uuid=6eab5bdd-c277-e55d-0363-dcfd186c8e8e network-uuid=cfe987f0-b37c-dbd7-39be-36e7bfd94cef device=0

La première commande permet d’obtenir l’UUID du réseau créé pour cet invité. La commande suivante permet de créer une carte réseau pour l’invité et de connecter la carte réseau au réseau approprié.

Félicitations! À ce stade, la machine virtuelle est prête à démarrer et à installer ! Pour démarrer l’invité, exécutez la commande 'xe' suivante.

xe vm-start name-label=TecmintVM

Si le terminal ne produit aucune erreur, l’invité a démarré avec succès. Le bon démarrage de l’invité peut être confirmé à l’aide de la commande 'xe' suivante :

xe vm-list name-label=TecmintVM

Maintenant, la grande question. Comment accéder à l’installateur ? C’est une question légitime. La méthode approuvée par Citrix consiste à utiliser XenCenter. Le problème ici est que XenCenter ne fonctionne pas sous Linux ! Il existe donc une solution de contournement pour que les utilisateurs n’aient pas à créer une station Windows spéciale simplement pour accéder à la console d’un invité en cours d’exécution.

Ce processus implique la création d’un tunnel SSH entre l’ordinateur Linux et l’hôte XenServer, puis la redirection de port d’une connexion VNC via ce tunnel. C’est très intelligent et fonctionne à merveille, mais cette méthode suppose que l’utilisateur peut accéder au XenServer via SSH.

La première étape consiste à déterminer le numéro de domaine de l’invité sur le XenServer. Cela se fait à l’aide de plusieurs commandes différentes.

xe vm-list params=dom-id name-label=TecmintVM
xenstore-read /local/domain/1/console/vnc-port

L’ordre de ces commandes est important ! La première commande renverra un numéro nécessaire pour la deuxième commande.

Le résultat des deux commandes est important. La première sortie indique l’ID de domaine dans lequel l’invité s’exécute ; 1 dans ce cas. La commande suivante nécessite ce numéro afin de déterminer le port VNC pour la session de console invitée. La sortie de cette commande fournit le port VNC qui peut être utilisé pour se connecter à la vidéo de cet invité particulier.

Avec les informations ci-dessus obtenues, il est temps de passer à une station Linux et de se connecter au XenServer pour afficher la session de console de cet invité. Pour ce faire, un tunnel SSH sera créé et la redirection de port sera configurée pour diriger une connexion VNC locale via le tunnel SSH. Cette connexion se fera à partir d’un poste de travail Linux Mint 17.2 mais devrait être similaire pour les autres distributions.

La première étape consiste à s’assurer que le client OpenSSH et xtightnvcviewer sont installés sur l’hôte Linux. Dans Linux Mint, cela peut être accompli avec la commande suivante :

sudo apt-get install openssh-client xtightvncviewer

Cette commande installera les utilitaires nécessaires. L’étape suivante consiste à créer un tunnel SSH vers l’hôte XenServer et à configurer le transfert de port vers le port VNC déterminé précédemment sur l’hôte XenServer (5902).

ssh -L <any_port>:localhost:<VM_Port_Above> root@<server> -N
ssh -L 5902:localhost:5902 root@<servername> -N

L’option '-L’indique à ssh de transférer le port. Le premier port peut être n’importe quel port supérieur à 1024 qui n’est pas utilisé sur la machine Linux Mint. Le 'localhost :5902' indique que le trafic doit être transféré vers le port localhost distant 5902, dans ce cas, c’est-à-dire le port VNC XenServer du TecmintVM.

Le « root@< serveur > » est les identifiants de connexion pour SSH dans l’hôte XenServer. Enfin, le '-N’indique à SSH d’ouvrir simplement une connexion de redirection de port. En utilisant la commande 'lsof', le tunnel peut être visualisé dans la sortie.

sudo lsof -i | grep 5902

Ici, le tunnel est configuré et à l’écoute des connexions. Il est maintenant temps d’ouvrir une connexion VNC à l’invité sur le XenServer. L’utilitaire installé est 'xvncviewer' et la connexion ssh pour transférer le trafic vers le XenServer est à l’écoute sur 'localhost :5902' afin que la commande appropriée puisse être construite.

xvncviewer localhost:5902

Voilà ! Il y a la session de console TecmintVM exécutant l’installateur réseau Debian qui attend que le processus d’installation commence. À ce stade, l’installation se poursuit comme n’importe quelle autre installation de Debian.

Jusqu’à présent, tout avec XenServer se faisait via l’interface de ligne de commande (CLI). Bien que de nombreux utilisateurs de Linux apprécient l’interface de ligne de commande, il existe des utilitaires qui simplifient le processus de gestion des hôtes et des pools XenServer. Le prochain article de cette série couvrira l’installation de ces outils pour les utilisateurs qui souhaitent utiliser des systèmes graphiques plutôt que des CLI.