Temps de lecture estimé: 4 minutes
C’était le weekend mises à jour !!
Après avoir mis à jour mon serveur principal et réglé ces problèmes de clé GPG pour Gitlab, je me suis ensuite penché sur Nakivo Backup et j’ai fini par le gros morceau, la mise à jour de mon serveur de virtualisation Vmware Esxi.
La vérité je vous le dis, ça ne me sert pas à grand-chose de faire la mise à jour…
Comme on dit dans l’IT : « If it works, don’t fix it » .
Mais comme je ne peux pas m’en empêcher et que j’aime bien avoir tout à jour (et que ça n’impacte que moi et pas de client), j’ai fait la mise à jour.
Je n’avais pas encore de licence (gratuite) pour la version 7 de Esxi, alors j’en ai demandé une.
Il y a ensuite (au 18/04/2020):
- le choix compliqué: l’image iso qu’il faudrait
graver sur un CDmettre sur une clé USB pour booter sur la machine. Ça ne m’arrange pas vu que ma machine (mac mini dans le salon) est headless (sans écran et sans clavier). - le choix facile: le bundle offline qui permet de faire l’update à distance en ligne de commande avec esxcli .
La théorie
Je télécharge donc le bundle VMware-ESXi-7.0.0-15843807-depot.zip que je place dans le store, à un endroit accessible par le serveur esxi. Après avoir pris soin d’éteindre proprement les machines virtuelles qui tournent encore et de mettre l’hôte en mode maintenance sur l’interface web:
Ou en ligne de commande:
esxcli system maintenanceMode set -e true
Une fois connecté en ssh sur la machine, la promesse était simple, juste un petit:
esxcli software vib update -d /vmfs/volumes/VM-Store/iso/VMware-ESXi-7.0.0-15843807-depot.zip
Et le tour devait être joué. J’ai même eu au bout de quelques minutes le message suivant:
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
Je me dis que tout c’est bien passé et que je ne suis qu’à un reboot d’avoir une machine toute propre à jour …
Sauf que tu t’en doutes… Là, c’est le drame… la machine ne rebootera jamais…
La pratique
Ne paniquant et ne m’énervant (pratiquement) pas, je me dis avec des termes moins édulcorés :
« mince je vais devoir débrancher tout et amener le mac dans mon bureau pour le connecter à un clavier (sans fil) et à un écran HDMI en espérant que le HDMI fonctionne par défaut et en espérant aussi pouvoir utiliser le clavier out of the box ».
Sauf que, spoiler alert!! Le clavier sans fil ne fonctionne pas et que je n’en ai pas d’autre. Je me retrouve donc avec un bel écran Mac m’indiquant que le démarrage ne se passe pas comme prévu avec lequel je ne peux pas interagir.
Et après recherches (premièrement sur la possibilité de faire fonctionner un clavier sans fil), je découvre qu’on peut installer Vmware Esxi (comme d’autres distributions Linux) avec un système de script lancé au boot, Kickstart.
D’abord j’ai téléchargé l’iso sur le site de Vmware dans le but d’en faire une clé USB bootable (le choix compliqué de tout à l’heure).
Clé USB Bootable avec l’iso Vmware Esxi 7.0
Pour faire une clé USB bootable, il vous faudra un outil pour copier l’iso sur la clé et la rendre bootable. De mon côté j’ai utilisé Rufus.
- Je sélectionne la clé que je veux rendre bootable
- Je sélectionne le fichier image iso de Vmware Esxi 7
- Je sélectionne le schéma de partition Master Boot Record (MBR)
- Je sélectionne le système de fichier Fat32
- Et pour finir, tout est prêt, je peux cliquer sur démarrer
Script Kickstart et installation automatique
Une fois que la clé est prête, il va falloir modifier le fichier de boot boot.cfg.
Mais attention, dans mon cas, il y avait 2 fichiers boot.cfg et j’ai cherché beaucoup de temps avant de comprendre qu’il fallait modifier le fichier boot.cfg dans le dossier efi et non celui à la racine de la clé.
Dans ce fichier, il y a une ligne d’option:
kernelopt=cdromBoot runweasel
Pour spécifier qu’il y a un script kickstart qui se trouve sur la clé USB dans /ks.cfg (c’est à adapter suivant les besoins de chacun. Ça peut être un chemin sur la clé, sur un autre filesystem, une adresse http, ftp etc), il faut la remplacer par:
kernelopt=ks=usb:/ks.cfg
Ensuite, pour le fichier de kickstart, il faut créer un fichier ks.cfg à l’endroit spécifié dans le boot.cfg plus haut (pour moi c’est donc à la racine de la clé usb /ks.cfg)
Il y a pour la suite là aussi quelques subtilités qui m’ont valu quelques longues minutes de recherche et d’incompréhension. Je ne suis pas tombé dessus directement, mais un fichier d’exemple et de la documentation sont disponibles sur le site de Vmware.
La première subtilité c’est que pour moi, le serveur n’a pas de disque dur, l’installation doit se faire sur clé USB. Je dois donc spécifier:
--firstdisk=usb
Avec usb en minuscule, sinon ce n’est pas pris en compte….
Ensuite, je voulais l’installer sur une autre clé que celle de boot.
Seulement, –firstdisk=usb ne signifie pas « le premier disque USB que je trouve EN PLUS DE LA CLÉ D’INSTALLATION » mais bien le premier disque USB trouvé. J’ai donc dû recommencer depuis l’étape précédente avec la bonne clé.
Et comme la clé USB ne le prend pas en charge, je dois spécifier:
--novmfsondisk
Voilà à quoi ressemble mon fichier ks.cfg:
vmaccepteula
rootpw myp@ssw0rd
install --firstdisk=usb --novmfsondisk
network --bootproto=dhcp --device=vmnic0
reboot
À partir de là, tout est rentré dans l’ordre. L’inconvénient d’une réinstallation au lieu d’une mise à jour c’est que j’ai dû tout reparamétrer, mais c’est aller assez vite.
Ajouter le datastore à partir du montage NFS sur le Nas, importer la VM de mon webserver et Go!!
Voilà! Ça a été une petite galère pour moi, mais je m’en suis sorti et en plus j’ai appris une nouvelle chose, que l’installation pouvait être scriptée avec un fichier kickstart.
La prochaine étape pour moi et ce serveur Vmware Esxi sera de mettre un disque dur SSD pour y faire tourner ma VM principale (pour gagner en perf) et ne faire sur le Nas que la sauvegarde.