VMWare ESXi sur Nuc 9 & SSD firmware...

Comme je vous en avait parlé ici, j'ai remplacé mon serveur ESXi HP ML350p par un Nuc 9. Depuis plus de 6 mois ça fonctionne très bien.

Dans ce Nuc j'ai installé deux SSD NVMe Samsung 980 Pro. Les performance sont au top, mais voilà que plusieurs utilisateurs se plaignent que leurs SSD s'usent prématurément et finissent par passer en R/O. C'est d'autant plus fâcheux que sous ESX on ne dispose de rien pour surveiller les disques sur un NUC, celui ci ne remontant pas de données IPML comme le ferait un vrai serveur. Après avoir fait un peu la sourde oreille, Samsung a fini par sortir la mise à jour idoine.

Sous Windows il est très facile de mettre à jour (ou de migrer) un SSD, il suffit de lancer Samsung Magician et le tour est joué ! Sous VMWare ESXi rien de tout ça et il va falloir le faire à la mano. Heureusement pour cela Samsung fournit également les firmawares sous la forme d'une ISO, il suffit, en principe, de le griller sur une clé USB et de booter avec et de faire la mise à jour. Mais ça c'est la théorie. Dans la pratique j'ai appris à mes dépends que cette clé basée sur un vieux Linux était incapable de booter sur du matériel moderne, et quand elle boote certains disent même qu'elle ne reconnait que les claviers PS2... Allons donc !

Après quelques recherches j'ai découvert qu'il existait un contournement possible mis en pratique par la communauté Linux, mais nullement supportée par Samsung qui doit considérer que ses SSD sont destinés uniquement à l'environnement Windows, tout comme VMWare qui a sa liste de hardware supporté...

L'astuce consiste à booter sous Linux, un Live CD Ubuntu. Facile, non pas si simple car ce live CD ne voulait lui non plus pas booter. Le bios de ce Nuc n'étant pas de toute fraicheur j'en profite pour le mettre à jour sans plus de succès.

J'ai fini par trouver que pour booter sous Ubuntu il fallait désactiver TPM et SGX. Ca ne s'invente pas mais j'ai fini par pouvoir booter mon Ubuntu Live.

Une fois sur le desktop de mon Ubuntu je copie l'ISO de mise à jour (Samsung_SSD_980_PRO_5B2QGXA7.iso) que j'ai au préalable préparée sur une autre clé USB vers le répertoire Home et je monte le volume. Ensuite toujours depuis l'interface graphique j'extrait le fichier initrd un répertoire (/home/samsung par exemple). Ensuite je vais jusqu'à /home/samsung/initrd/root/fumagician et je peux lancer la mise à jour de mes SSD :

sudo ./fumagicien

Je fais la mise à jour de mes deux SSD et je relance le Nuc. Attention, le bon numéro de version n'apparaitra qu'âpres le prochain redémarrage. Donc même si c'est un peu fastidieux, je vous conseille de relancer le Live CD pour vérifier. De même si vous avez d'autres machines à mettre à jour, vous pouvez sauvegarder fumagician sur une clé pour éviter l'étape de l'extraction. 

Il existe une autre méthode en CLI pour les barbus, elle demandera toutefois de connecter le Live CE au réseau si on veut éviter l'étape de la clé USB, mais in fine ça revient au même :

wget https://semiconductor.samsung.com/resources/software-resources/Samsung_SSD_980_PRO_5B2QGXA7.iso
apt-get -y install gzip unzip wget cpio
mkdir /mnt/iso
sudo mount -o loop ./Samsung_SSD_980_PRO_5B2QGXA7.iso /mnt/iso/
mkdir /tmp/fwupdate
cd /tmp/fwupdate
gzip -dc /mnt/iso/initrd | cpio -idv --no-absolute-filenames
cd root/fumagician/
sudo ./fumagician

Voilà comment occuper (perdre) un après-midi d'hiver !

Attention toutefois, si vous avez créé un volume RAID, ce qui est discutable avec des SSD, il semblerait que vous ne puissiez les voir sans repasser le bios en AHCI.

Sources

 

VMWare ESXi 7 sur Intel Nuc 9

Afin de faciliter mes bricolages j'ai chez moi un gros (il est imposant) serveur HPE ML350p avec deux CPU Xeon et 128 GO de mémoire. Un peu surdimensionné, mais ça fait très bien le job pour mon home lab, d’autant plus qu’on me l’a donné il y a quelques années. Sauf que ça chauffe le garage et ça consomme beaucoup trop (200 watts sans charge). Autant dire que quand nos gouvernants nous appellent à débrancher le WI-FI ça me fait doucement rigoler dans ma barbe, mais je suis moins hilaire quand je reçoit la facture. Comme quoi l'écologie et la sobriété énergétique passe bien souvent par le porte monnaie. J'envisage des panneaux solaires, mais dans tous les cas, je cherchait une alternative moins énergivore.

J’ai vu pas mal de choses, les HPE MicroServer sont limités à 32 Go de mémoire, il y a des choses chez SuperMicro mais au niveau conso on doit pas être loin d'un HPE DL360gen8 qui sera moins cher en reconditionné.

Et puis je me suis dit qu'il restait l'option NUC. Ca fait un peu jouet quand on l'habitude de vrais serveurs et je trouvais ça un un peu léger coté ram et stockage, moi qui suis un vieil habitué du RAID (pas la maréchaussée, hein). Et puis sur les NUC il y a souvent qu'une seule interface LAN, sauf à passer sur des modèles extrêmes par le cout. Et puis je suis tombé sur le Nuc 9 qui est intéressant car on peut y coller 3 SSD M2, 64 GO de RAM, il dispose de deux ports Ethernet et même deux slots PCI. Ce n'est pas la dernière génération et on le trouve en version i7 à 500 € ce qui est un tarif très acceptable. Tarif auquel il faudra ajouter la RAM et les SSD. (Il y existe en i5 un peu moins cher, et même en i9 ou Xeon, mais bien plus couteux.

Un des intérêts du Nuc 9 est qu'il supporte nativement VMWare ESXi v7u3 et que l'on peut faire du RAID 1 matériel qui sera vu par ESXi. Et surtout coté consommation j'ai relevé de 15 à 50 watts (selon la charge), on est très loin des 200/350 watts du HPE ML 350p !

La liste des courses

J'ai profité des PrimeDays pour faire quelques économies :

Installation

La machine est compacte mais tous les composants s'installent facilement. J'ai installé deux SSD M2 sur la carte principale et on peut éventuellement en ajouter un de plus sous les slots PCI. Et comme je ne vais pas y coller une super carte graphique ces slots pourraient héberger une carte SSD ou réseau 10 GB. Encore que l'on dispose également de deux slots Thunderbolt en USB-C...

Avant de commencer on va désactiver le "secure boot" dans le bios, éventuellement le mettre à jour, et activer le boot USB. Pour le reste on laisse tout par défaut mais on notera pas mal de possibilités, notamment au niveau réseau ou il est possible de rattacher directement du iSCSI au niveau du bios. A tester avec un SAN ou un NAS.

Ensuite la partie est classique. On télécharge ESXi chez VMWare et on crée une clé USB sur laquelle on va booter. Contrairement aux anciennes génération de NUC celui ci est compatible de base, donc aucun besoin d'y injecter des drivers. En quelques minutes et un peu de configuration très basique (IP, etc.) notre serveur est prêt et n'y a plus qu'à s'y connecter. Pour le reste vous connaissez et la migration peut commencer.

Personnellement avant de migrer je préfère installer une nouvelle VM et laisser tourner la chose quelques jours à blanc, ce qui m'a également permis de débrancher un peu moi même.

Migration

Il y a plusieurs façons de migrer des VM d'un hyperviseur à un autre. En datacenter un héberge généralement pas les VM sur des disques locaux mais sur des SAN/NAS en iSCSI ou NFS. Et dans ce cas on ne bouge pas les fichiers des VM, on ne fait que les réimporter d'un hyperviseur à un autre. Tout ça peut aussi se faire avec vCenter, mais vu l'usine je vous déconseille en homelab.

Ici pour passer les VM sur mon nouveau serveur j'aurai pu simplement y déplacer les fichiers manuellement. Mais on peut faire ça plus facilement avec Veeam Quick Migration. Veeam est une solution d'entreprise loin d'être donnée, mais la version gratuite fera parfaitement le travail et vous aidera dans pas mal de taches.

Ajustements

Réseaux

Sur mon ancien ESXi j'avais plusieurs cartes réseau et donc plusieurs réseaux logiques. Avant la migration il faudra les recréer à l'identique, si par exemple on avait appelé le réseau WAN VM Network WAN il faudra que le nouveau ait exactement le même nom sans quoi il faudra éditer la configuration de la VM, supprimer la carte et la recréer. J'en parle d'expérience car je me suis fait avoir.

Version HW

Ceux qui pratiquent ESXi savent que chaque VM à son numéro de version de matériel virtuel et que de cette version dépend la possibilité d'ajuster le bon O/S afin de ne pas avoir de message d'erreur vous disant que le bon O/S n'est pas configuré. Dans la pratique je n'ai jamais vu d'erreurs liée à ça et mon vieil ESXi 5.0 (jamais mis à jour, oui je sais ce n'est pas une bonne pratique) faisait tourner des VM Windows 2019 déclarées en Windows 2008R2 depuis des lustres. Il y a surement un peu de marketing dans cette affaire... Mais on peut ajuster :

  • On crée un snapshot
  • On mets à jour les VMWare Tools (dans l'ordre car si vous mettez à niveau le matériel VM avant d'installer la dernière version de VMware Tools, les paramètres réseau peuvent être réinitialisés dans la machine virtuelle invitée Windows).
  • Et ensuite clic droit sur la VM et mise à niveau et édition de la configuration pour ajuster l'O/S.

Les détails sont ici. On peut revenir en arrière si on devait transporter la VM sur une ancienne version d'ESXi, mais c'est plus compliqué et non supporté officiellement.

Migration Veeam

La migration des VM est très facile avec Veeam mais si on le fait tourner dans une VM à migrer on va forcément avoir une erreur quand elle va se migrer elle même. Pas de panique, sur la cible on restaure le snapshot et on renomme avant de la faire redémarrer.

Il n'y a plus qu'à ajuster le plan de sauvegarde. Les anciennes VM apparaissent en VM_Migrated, on les supprime et on ajoute celles qui correspondent au nouvel hyperviseur.

Conclusion

Ca me fait bizarre d'abandonner mon vieux gros HPE ! Pour autant je n'ai pas l'impression de perdre en puissance. Certes je serais plus limité en mémoire, mais je n'ai pas le sentiment de manque de CPU et surtout il y a une très grande différence entre les disques mécaniques, qui étaient pourtant es SAS 1.5 K et mes nouveaux SSD M2 très véloces. Et ça change vraiment tout ! Pour l'instant il n'a même pas rejoint le garage ou il fait très chaud, il est sur mon bureau et pas un bruit avec pourtant pas moins de 20 VM actives....

Et pour le fun je vais vous en narrer une bien bonne...

Quand on crée un serveur ESXi on installe une partition de boot que l'on installait jadis sur une carte SD prévue à cet effet sur les vrais serveurs. Solution maintenant abandonnée au profit d'une petite partition dédiée, 120 GO par défaut mais que l'on peut réduire lors de l'installation. Bref, sur mon ancien HPE je ne devais pas avoir de carte SD sous la main et sans faire gaffe je lui avait laissé 800 GO de partition système, ce qui sur 4 disques de 600 GO en RAID 5 me laissait peu de place pour les VM.... Flemme de refaire tout ça je m'étais contenté il y a plus de 10 ans de rajouter deux disques de 2 TO en RAID 1....

Me voici donc avec un serveur HPE ML350p Gen 8 (2 x Xeon12 CPUs x Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz), de la RAM et plein de disques à céder.

EDIT'S

10/08/2022 : J'ai fait un autre test en ajoutant à cette machine une carte graphique 3060 TI de chez Asus. Ca rentre.

26/092024 : Que le temps passe ! Autre test avec une GPU de type 4060 TI (je me refuse à dépenser + de 500 € pour une carte graphique). Le problème il faut que la carte rentre dans le boitier du Nuc 9. Après deux retours chez Amazon je suis tombé sur cette carte MSI 4060 TI qui la seule aux bonnes dimensions avec deux ventilateurs. Il existe également les cartes Palit StormX 4060/4060TI en mono ventilateur qui m'ont moins inspiré confiance.

Sources

 

Exploiter un serveur dédié chez Online

Je dispose depuis des années, entre autres, d’un serveur dédié sur Online / Scaleway. Pourquoi eux ? Pour le service toujours très réactif, ils répondent au téléphone tout de suite, et par exemple hier soir j’ouvre un ticket à 3 heures du matin et en 5 minutes j’avais ma réponse. Bref, on n’est pas chez OVH ! A l’occasion d’une promo je commande un nouveau serveur avec une belle remise, je me trompe en en choisissant un sans RAID hardware, un coup de fil et c’est réglé et remboursé et je n’ai plus qu’à recommander le bon serveur, avec du RAID car je veux faire de l’ESX.

Vous allez me demander pourquoi je ne prends pas simplement des instance cloud, simplement parce que c'est bien plus coûteux et surtout j'aime bien avoir la main sur toute la chaîne.

Installer un hyperviseur sur ce genre de serveur permet de mutualiser plusieurs VM dont j’aurais besoin. Pour accéder à ces VM Online propose des IP Failover facturées en sus, que l’on affecte généralement à chaque VM, qui seront de fait exposée sur le net avec leur IP. Cela pose deux problèmes, outre le coût (1.99 € / mois par IP) qui n’est pas le plus important, la sécurité du serveur hébergé sur la VM n’est assurée que par le firewall de l’O/S, ce qui reste léger et potentiellement vulnérable.

J’ai donc fait le choix cette fois de ne pas exposer mes VM et d’installer une VM frontale qui servira de reverse proxy et qui sera la seule vue de l’extérieur, donc je n’aurais besoin que d’une seule IP Failover. Il existe plusieurs solutions pour faire ça, Traefik, Ngnix par exemple, j’ai choisi pfSense avec le plugin HAProxy qui est simple à déployer et qui en plus gère très bien les certificats Lets Encrypt via le plugin Acme.

Dans la pratique on installe ESX en quelques clics via la console Online, ensuite on crée sur ESX un LAN qui n’est connecté à aucune carte réseau (on doit pouvoir utiliser le même swich virtuel que pour le WAN avec un VLAN, mais ce serait se compliquer la vie). Dans la console Online on achète une IP Failover, on l’associe au serveur dédié et on lui attribue une adresse MAC que l’on reportera sur le WAN de la VM pfSense. (je trouve le client vSphère plus intuitif que la version web pour faire ce genre de réglages).

On installe pfSense à partir d’une ISO dans une VM avec une patte WAN (sans oublier d'y reporter la MAC adresse de l'IP Faiover), et une patte LAN. Pour ces deux interfaces on prend une carte réseau VMXNet3 pour de meilleures performances.

Une fois l’installation terminée, depuis la console ont défini VMX0 sur le WAN et VMX1 sur le LAN et on configure les adresses IP correspondantes, l’IP Failover sur le WAN (SANS GATEWAY, c’est important) et une IP LAN, 192.168.x.1 par exemple et sans passerelle puisque c’est le LAN. On n’active pas le serveur DHCP.

Ensuite on passe dans le shell de la console (ce n’est pas du Linux mais du FreeBSD) et c’est là qu’il y a une particularité qui est propre à certains hébergeurs, ici pour Online, mais il y a une variante OVH par exemple. pfSense ne permet pas d’avoir une passerelle en dehors du masque de son IP WAN, il va donc falloir ruser en la définissant via le shell :

route del default (pour retirer les passerelles existantes)
route add -net 62.210.0.1/32 -iface vmx0
route add default 62.210.0.1

A partir de là on peut se connecter à pfSense avec un navigateur et se laisser guider par le wizard. On confirmera l’IP Failover mais toujours sans passerelle (ni MAC). On teste avec les diag en faisant un ping vers 1.1.1.1 et on crée une règle pour autoriser le trafic sortant depuis notre LAN. Pour la suite de la configuration cherchez vous un tuto sur pfSense !

Voilà, il ne reste plus qu’à installer nos VM et les publier via HAProxy dans pfSense.

Bonus

  • Mettre des ACL sur le firewall d’ESX pour limiter l’admin uniquement depuis certaines IP
  • Rendre l'accès à la configuration pfSense accessible uniquement depuis le LAN
  • Installer une VM Zerotier site-to-site afin de pouvoir accéder aux VM (en RDP ou SSH par exemple) ainsi qu'à l’admin de pfSense qui ne sera exposée que sur le LAN.
  • Sur pfSense installer le package Open-VM-Tools
  • Sur pfSense installer le package Shellcmd afin de figer les routes spécifiques exposées ci-dessus.

J’ai fait ça sur un serveur un peu costaud, mais c’est jouable sur les petits serveurs Avoton d'entrée de gamme qui étaient soldés à 4 € avec 16 GO…

Sources