Comment créer et installer des machines virtuelles invitées dans XenServer - Partie 5
Poursuivant la progression 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 plateforme XenServer 7. Pour l'installation, suivez : Nouvelle installation de XenServer 7.
Cet article supposera que tous les articles précédents traitant de la mise en réseau, des correctifs et du stockage ont été terminés. Heureusement, il n’est plus vraiment nécessaire 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 d'aperçu rapide de ce qui a été configuré et de l'article sur lequel le sujet a été abordé.
- XenServer 6.5 a été installé sur le serveur
- https://linux-console.net/citrix-xenserver-installation-and-network-configuration-in-linux/
- Tous les correctifs XenServer 6.5 ont été appliqués
- https://linux-console.net/install-xenserver-patches-in-linux/
- Des équipes d'interface réseau et des VLAN ont été créés
- https://linux-console.net/xenserver-network-lacp-bond-vlan-and-bonding-configuration/
- Des référentiels de stockage iSCSI et ISO ont été créés pour contenir les fichiers d'installation du système d'exploitation et les disques durs virtuels utilisés par les invités.
- 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 réellement la machine invitée nouvellement créée et installer un système d'exploitation. Assurez-vous 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 disque dur, l'architecture du processeur et la quantité de RAM disponible, entre autres options.
Ces options peuvent être modifiées manuellement ultérieurement, mais pour l'instant, un simple modèle sera utilisé pour illustrer leur utilisation. Pour obtenir la liste des modèles disponibles, la commande traditionnelle 'xe' peut recevoir différents arguments pour inviter le système à renvoyer les modèles disponibles.
xe template-list
Cette commande est susceptible de renvoyer beaucoup de résultats. Pour rendre le résultat plus facile à lire, il est suggéré que le résultat soit redirigé vers « moins » comme suit :
xe template-list | less
Cela permettra une analyse plus facile des modèles disponibles pour localiser les informations UUID nécessaires. Cet article fonctionnera 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 actuel. (La capture d'écran ci-dessous a utilisé le UUID dans la commande pour supprimer 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 existe quelques étapes d’entretien ménager qui peuvent potentiellement faciliter les choses à l’avenir. La première consiste à fournir une étiquette de nom au VDI nouvellement créé et la seconde consiste à modifier l'une des spécifications matérielles par défaut fournies par le modèle.
Pour comprendre pourquoi il serait important de nommer le VDI, jetez un œil à ce que le système attribuera automatiquement au VDI lors de son provisionnement à 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 consiste à rassembler les deux informations en utilisant la commande suivante :
xe vm-disk-list vm=TecmintVM
La partie en jaune est le souci. Pour de nombreuses personnes, ce problème est mineur, mais à des fins de gestion interne, un nom plus descriptif est souhaité 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 à définir, mais d'après l'expérience, cela a évité un problème grave lors du détachement 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 de l'invité n'a pas pu être restaurée sur le nouveau XenServer et heureusement, en nommant le VDI sur chacun des invités, le mappage approprié de l'invité à son VDI a pu être effectué simplement par le nom-étiquette.
La prochaine étape de gestion de cet article consiste à fournir à cet invité particulier plus de ressources. Tel qu'il est configuré, cet invité ne disposera que d'une valeur d'environ 256 Mio (Mébioctets) de mémoire. Pour la plupart des invités, cela ne suffit pas, il est donc utile de savoir comment augmenter la mémoire disponible d'un invité. Comme pour tout 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, cela serait acceptable, 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 avec l'invité é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
Remarquez que cela réservera tout le temps deux Gio de RAM à cet invité.
Cet invité particulier est désormais prêt à installer un système d’exploitation. Dans l'article précédent sur les référentiels 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
Assurez-vous de remplacer <servername> par le nom du serveur Samba approprié pour l'environnement dans lequel cette configuration s'effectue. 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 supposera que l'ISO du programme d'installation Debian Net existe sur le référentiel 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 répertorient 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 demande à l'invité d'utiliser le CD-ROM comme méthode d'installation du système d'exploitation. L'UUID de l'invité Tecmint est surligné en jaune dans la capture d'écran ci-dessus.
La dernière étape de la configuration de l'invité consiste à attacher une interface réseau virtuelle (VIF). Ceci est particulièrement important pour cette méthode d'installation puisque l'installateur Réseau Debian est utilisé et devra extraire les paquets des dépôts Debian.
En repensant à l'article sur la mise en réseau de 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 est utilisée pour créer une carte réseau pour l'invité et connecter la carte réseau au réseau approprié.
Félicitations ! À ce stade, la machine virtuelle est prête à démarrer et à s'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é avec la commande 'xe' suivante :
xe vm-list name-label=TecmintVM
Maintenant la grande question. Comment accéder à l'installateur ? C'est une question valide. 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 besoin de 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 depuis l'ordinateur Linux vers l'hôte XenServer, puis le transfert 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 grâce à l’utilisation 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é. La sortie de cette commande fournit le port VNC qui peut être utilisé pour se connecter à la sortie vidéo de cet invité particulier.
Une fois les informations ci-dessus obtenues, il est temps de passer à une station Linux et de vous connecter au XenServer pour afficher la session console de cet invité. Pour ce faire, un tunnel SSH sera créé et une redirection de port sera configurée pour diriger une connexion VNC locale via le tunnel SSH. Cette connexion se fera depuis 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. Sous 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 la redirection 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, il s'agit du port XenServer VNC de TecmintVM. fort>.
Le 'root@
sudo lsof -i | grep 5902
Ici, le tunnel est configuré et écoute les connexions. Il est maintenant temps d'ouvrir une connexion VNC avec l'invité sur le XenServer. L'utilitaire installé est 'xvncviewer' et la connexion SSH pour transférer le trafic vers XenServer écoute sur 'localhost:5902' afin que la commande appropriée puisse être créée.
xvncviewer localhost:5902
Voilà ! La session de console TecmintVM exécute le programme d'installation réseau Debian en attente du début du processus d'installation. À ce stade, l'installation se déroule comme n'importe quelle autre installation Debian.
Jusqu'à présent, tout avec XenServer a été fait via l'interface de ligne de commande (CLI). Bien que de nombreux utilisateurs Linux apprécient la CLI, il existe des utilitaires pour simplifier 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 CLI.