Introduction
Monter un environnement de virtualisation ne nécessite pas forcément un serveur rackable, plusieurs milliers d'euros de matériel ou une infrastructure professionnelle.
Pour ce premier homelab, l'objectif était simple : réutiliser un Dell Latitude 5430 pour héberger VMware ESXi 8 et disposer d'une plateforme de test pour Windows Server, Active Directory et, à terme, Parallels RAS.
Sur le papier, l'installation semblait relativement simple. Dans les faits, plusieurs obstacles sont apparus : incompatibilité du processeur hybride, particularités de l'installateur, configuration réseau, authentification administrateur et partitionnement du SSD.
Voici le retour d'expérience complet.
Présentation du matériel
Le matériel utilisé est un ordinateur portable Dell Latitude 5430, initialement destiné à un usage bureautique.
| Composant | Configuration |
|---|---|
| Modèle | Dell Latitude 5430 |
| Processeur | Intel Core i5-1245U, 12e génération |
| Mémoire | 16 Go de RAM |
| Stockage | Samsung PM991a NVMe, 256 Go |
| Réseau | Intel Ethernet I219-LM, 1 Gbit/s |
| Hyperviseur | VMware ESXi 8.0 Update 3e |
| Build ESXi | 24677879 |
Ce matériel n'est pas officiellement certifié pour ESXi. L'installation relève donc d'un usage expérimental, adapté à un homelab mais déconseillé pour un environnement de production.
L'objectif est de disposer d'une infrastructure fonctionnelle sans investissement important.
Préparation du BIOS et de la clé USB
Avant l'installation, plusieurs paramètres du BIOS ont été vérifiés :
- Activation de la virtualisation Intel VT-x.
- Activation de VT-d.
- Vérification du mode de fonctionnement du contrôleur de stockage.
- Démarrage sur une clé USB préparée avec Rufus.
L'image utilisée est :
VMware-VMvisor-Installer-8.0U3e-24677879.x86_64.iso
Une fois la clé USB préparée, le Dell démarre sur l'installateur VMware ESXi.
C'est à ce moment qu'apparaît le premier obstacle.
Premier problème : écran violet au démarrage
Au lancement de l'installateur, ESXi provoque un écran violet (Purple Screen of Death, ou PSOD).
Le message d'erreur indique notamment :
Fatal CPU mismatch on feature "Hyperthreads per core"
Comprendre le problème
Le processeur Intel Core i5-1245U utilise une architecture hybride associant des cœurs performants (P-cores) et des cœurs économes (E-cores).
Ces cœurs ne présentent pas nécessairement la même topologie matérielle, notamment concernant l'Hyper-Threading.
ESXi détecte cette différence et peut interrompre son démarrage lors de ses vérifications d'uniformité CPU.
Contournement utilisé
Au menu de démarrage ESXi :
- Appuyer sur
Shift + O. - Conserver les options déjà présentes.
- Ajouter le paramètre suivant :
cpuUniformityHardCheckPanic=FALSE
- Valider avec Entrée.
L'installateur a alors pu poursuivre son démarrage.
Attention : ce paramètre contourne une vérification de sécurité et de compatibilité CPU. Il ne rend pas le matériel officiellement compatible et ne garantit pas sa stabilité dans toutes les situations.
Installation d'ESXi sur le SSD NVMe
Après application du contournement CPU, l'installateur a reconnu le SSD Samsung PM991a.
L'installation a été réalisée sur ce disque, avec suppression de l'installation Windows précédente.
Les étapes principales ont été :
- Sélection du SSD NVMe.
- Choix de la disposition de clavier française.
- Configuration du compte administrateur
root. - Confirmation de l'installation.
- Redémarrage sur le SSD.
À l'issue de cette opération, VMware ESXi 8.0.3 était installé.
Le premier redémarrage nécessitait toutefois de réutiliser le paramètre CPU, puisqu'il n'avait pas encore été enregistré de manière permanente.
Configuration réseau : Intel I219-LM et switch Gigabit
Lors du premier démarrage, ESXi affichait :
https://0.0.0.0/
Waiting for DHCP...
DHCP lookup failed.
La carte réseau était pourtant reconnue par l'hyperviseur.
Depuis l'environnement de l'installateur, la commande suivante avait permis de vérifier sa présence :
localcli network nic list
L'interface vmnic0 apparaissait avec le pilote ne1000.
Link Status Down. Cliquer sur la photo pour l’ouvrir en grand dans un nouvel onglet.Le problème provenait simplement de l'absence de liaison Ethernet active.
Mise en place du réseau
Un switch manageable NETGEAR GS305E à cinq ports Gigabit a été ajouté à l'installation, accompagné de câbles RJ45 Cat 6.
Le coût total de cette petite infrastructure réseau a été de 35 €.
Le switch a été raccordé à une prise Ethernet murale, elle-même reliée à la box Internet par le câblage du logement.
Le Dell ESXi a ensuite été connecté au switch.
Une adresse IPv4 a été automatiquement attribuée par DHCP :
192.168.1.24
L'interface d'administration est devenue accessible à l'adresse :
https://192.168.1.24/ui
Cette adresse est propre au réseau de test et peut varier selon l'environnement.
Authentification root : un incident inattendu
Un autre problème est apparu lors de la première connexion à l'interface Web.
Malgré les identifiants attendus, l'authentification échouait.
L'investigation a révélé deux éléments :
- Une incohérence de disposition du clavier entre certaines étapes de configuration.
- Plusieurs tentatives de connexion infructueuses ayant alimenté le compteur d'échecs du compte
root.
Depuis la console locale ESXi, le mot de passe administrateur a été vérifié et reconfiguré.
Le compteur des tentatives a également été examiné :
pam_tally2 --user root
root affiche neuf échecs de connexion avant sa réinitialisation. Cliquer sur la photo pour l’ouvrir en grand dans un nouvel onglet.Puis réinitialisé :
pam_tally2 --user root --reset
Après correction du mot de passe et réinitialisation du compteur, l'accès à l'interface Web a fonctionné.
Point de vigilance : avant de multiplier les tentatives d'authentification, vérifier la disposition du clavier et les éventuels mécanismes de verrouillage du compte.
Rendre le contournement CPU permanent
Saisir manuellement cpuUniformityHardCheckPanic=FALSE à chaque démarrage n'était évidemment pas une solution satisfaisante.
Une fois l'accès SSH activé depuis les services ESXi, la connexion à l'hyperviseur a été réalisée depuis PowerShell :
ssh root@192.168.1.24
Le paramètre a ensuite été configuré :
esxcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE
Pour vérifier la configuration :
esxcli system settings kernel list -o cpuUniformityHardCheckPanic
Le résultat indiquait :
| Champ | Valeur |
|---|---|
| Configured | FALSE |
| Runtime | FALSE |
| Default | TRUE |
La configuration a ensuite été sauvegardée :
/sbin/auto-backup.sh
Enfin, un redémarrage complet a été effectué sans utiliser Shift + O.
Résultat : ESXi a démarré normalement, et les valeurs Configured et Runtime sont restées à FALSE.
Le contournement est donc bien persistant sur cette installation.
Pour réduire la surface d'attaque, les services SSH et ESXi Shell peuvent ensuite être arrêtés lorsqu'ils ne sont plus nécessaires.
Vérification de la licence gratuite ESXi 8
Une interrogation subsistait concernant la licence.
L'installateur avait affiché un message évoquant une période d'évaluation de 60 jours.
Pourtant, dans l'interface d'administration, la section Hôte → Gérer → Licences indiquait :
| Information | Valeur |
|---|---|
| Édition | vSphere 8 Hypervisor |
| Expiration | Jamais |
| Limite par VM | 8 vCPU |
L'installation disposait donc bien d'une licence gratuite sans expiration, correspondant à l'édition gratuite d'ESXi 8.
Cette licence présente des limitations fonctionnelles par rapport aux éditions commerciales. Elle reste néanmoins adaptée aux premiers besoins du homelab.
Stockage : pourquoi seulement 110 Go disponibles ?
Le SSD physique possède une capacité commerciale de 256 Go.
Pourtant, après installation, le datastore principal affichait seulement :
- Capacité totale : 110,25 Gio.
- Espace libre : environ 108,84 Gio.
L'analyse du partitionnement a permis de comprendre cette différence.
ESXi 8 réserve notamment une partition importante à ses données système, appelée ESX-OSData.
La répartition observée comprenait approximativement :
| Partition | Capacité |
|---|---|
| ESX-OSData | 119,8 Gio |
| Datastore VMFS6 | 110,2 Gio |
| Bootbanks | 8 Gio au total |
| Autres partitions | Espace restant |
La partition OSDATA occupait donc presque autant d'espace que le datastore destiné aux machines virtuelles.
Une optimisation possible à l'installation
ESXi dispose d'un paramètre permettant de demander une taille système minimale :
systemMediaSize=min
Ce paramètre doit être transmis au démarrage de l'installateur, et non exécuté dans le terminal SSH d'un ESXi déjà installé.
Il permet d'envisager un partitionnement plus adapté à un petit SSD, sous réserve des exigences de stockage et de support applicables.
Dans notre cas, le choix a été de conserver le premier hyperviseur en l'état, puisqu'il était désormais fonctionnel.
L'optimisation sera étudiée lors de l'installation du deuxième Dell.
Faire fonctionner ESXi avec le capot fermé
L'objectif final est de conserver les ordinateurs portables fermés, à la manière de petits serveurs.
Un premier test a été réalisé depuis un autre ordinateur du réseau :
ping 192.168.1.24 -t
Le principe consiste à fermer le capot du Dell, puis à vérifier que l'hyperviseur continue de répondre au ping et que son interface Web reste accessible.
Ce test permet de contrôler le comportement de l'alimentation à la fermeture de l'écran.
Il ne dispense toutefois pas de surveiller les températures, notamment lorsque plusieurs machines virtuelles seront actives.
Les aérations doivent rester dégagées.
Bilan de l'installation
À l'issue de cette première phase, le Dell Latitude 5430 dispose d'un hyperviseur ESXi 8 opérationnel.
| Élément | État |
|---|---|
| Installation ESXi 8.0.3 | Validée |
| Reconnaissance du SSD NVMe | Validée |
| Reconnaissance Ethernet Intel | Validée |
| Réseau Gigabit | Fonctionnel |
| Interface Web ESXi | Accessible |
| Contournement CPU permanent | Validé après redémarrage |
| Licence gratuite | Sans expiration |
| Datastore VMFS6 | 110 Go |
| Première VM | À déployer |
| Accès VPN extérieur | À étudier |
Le budget réseau engagé est limité à 35 €, le Dell étant du matériel réutilisé.
Les prochaines étapes
Le projet ne s'arrête évidemment pas à l'installation de l'hyperviseur.
La suite consistera à :
- Installer un deuxième hôte ESXi, avec un partitionnement du SSD optimisé.
- Déployer une première machine virtuelle Windows Server.
- Construire un environnement Active Directory et DNS.
- Tester Parallels RAS.
- Mettre en place un accès VPN sécurisé pour administrer le laboratoire depuis l'extérieur.
L'interface d'administration ESXi ne sera pas exposée directement sur Internet.
Conclusion
Ce premier déploiement démontre qu'un ordinateur portable professionnel réutilisé peut constituer une plateforme de virtualisation intéressante pour un laboratoire personnel.
L'installation n'a pas été totalement transparente : processeur hybride non pris en charge officiellement, configuration de démarrage spécifique, authentification administrateur et partitionnement système ont nécessité plusieurs investigations.
Mais c'est précisément l'intérêt d'un homelab : expérimenter, diagnostiquer, comprendre et documenter.
Avec un Dell Latitude 5430, 16 Go de RAM et une infrastructure réseau à 35 €, nous disposons désormais d'une première base pour construire un environnement de tests Microsoft et virtualisation.
La prochaine étape sera de donner vie à cet hyperviseur avec ses premières machines virtuelles.
Article basé sur une installation réelle. Les manipulations décrites concernent un environnement de laboratoire non certifié et ne constituent pas des recommandations de déploiement en production.