Objectifs d'apprentissage
À la fin de ce cours, l'apprenant peut :
- expliquer le rôle de l'hyperviseur et sa relation avec vCenter ;
- lister les exigences matérielles de l'ESX 9.0 et ce qu'elles impliquent pour le démarrage et le disque de boot ;
- décrire les options d'installation (interactive, scriptée, Auto Deploy) sans en lancer une ;
- expliquer datastores (VMFS, NFS, vSAN, vVol), multipath et snapshots de machines virtuelles ;
- appliquer la procédure de mise en maintenance d'un hôte et en connaître les préconditions et les effets ;
- distinguer les opérations de lecture de celles qui détruisent des données (suppression de datastore, retrait d'hôte) ;
- utiliser ESXCLI en lecture pour diagnostiquer, sans modifier.
Prérequis
- Notions de virtualisation (hôte, machine virtuelle, disque virtuel).
- Notions de réseau IP et de stockage (LUN, iSCSI, FC, NFS).
- Savoir lire un résultat en ligne de commande.
- Aucun accès à un hôte réel n'est requis ; si Stéphane souhaite pratiquer, uniquement sur un laboratoire isolé.
Parcours et chapitres
1. Hyperviseur et plateforme vSphere
D'après « Introduction to vSphere Deployment and Setup » (9.0) : les deux composants centraux de vSphere sont ESX, plateforme de virtualisation sur laquelle on crée et exécute des machines virtuelles et des appliances, et vCenter, service qui sert d'administrateur central des hôtes ESX connectés en réseau et permet de mettre en commun les ressources de plusieurs hôtes.
Un hôte peut être géré seul (via le VMware Host Client, interface web de l'hôte) ou par vCenter. Le cours « vCenter » traite la gestion centralisée.
Licences : la même page indique que depuis ESX 9.0, les hôtes ne sont plus licenciés avec le vSphere Client ; le guide « Licensing » est à consulter (non lu : détails de licence non vérifiés).
Vérification : expliquer à l'oral la différence ESX / vCenter / machine virtuelle en trois phrases.
2. Exigences matérielles et démarrage (ESX 9.0)
La page « ESX Hardware Requirements » (9.0) indique :
- plate-forme serveur prise en charge : voir le Broadcom Compatibility Guide (c'est lui qui fait foi pour matériel et pilotes) ;
- au moins deux cœurs CPU ; processeurs x86 64 bits ; bit NX/XD activé dans le BIOS ;
- au moins 8 Go de RAM ; au moins 12 Go recommandés pour exécuter des machines virtuelles en production typique ;
- virtualisation matérielle (Intel VT-x ou AMD RVI) activée pour les VM 64 bits ;
- un ou plusieurs contrôleurs Ethernet Gigabit ou plus rapides ;
- un disque de boot d'au moins 32 Go de stockage persistant (HDD, SSD ou NVMe) ; un périphérique de boot ne doit pas être partagé entre hôtes ESX ;
- support du BIOS hérité limité ; démarrage UEFI recommandé ; avec des DPU, seulement UEFI.
La page précise que les disques SATA sont considérés comme distants et ne servent pas de partition scratch par défaut.
Les exigences d'ESXi 8.0 n'ont pas été relues : non vérifié pour la 8.0.
Exercice (papier) : pour un serveur fictif (2 cœurs, 6 Go RAM, 16 Go de disque), dire quelles exigences ne sont pas remplies.
3. Options d'installation
La documentation 9.0 distingue l'installation interactive, scriptée et par vSphere Auto Deploy (démarrage et provisionnement par le réseau, UEFI pris en charge), ainsi que la personnalisation d'images avec l'Image Builder. Le démarrage réseau de l'installateur existe en variantes (par exemple iPXE et HTTP).
Ce cours ne donne aucune procédure d'installation : elle dépend de la version, du matériel et de la politique de l'entreprise, et une installation efface le disque de boot ciblé. Sa lecture se fait dans « ESX Installation and Setup » (source 2).
Effet à retenir : une installation ou une mise à niveau est une opération à effet notable (contexte : console physique ou BMC ; droits : accès console ; retour arrière : image/sauvegarde de configuration — non détaillée). Ne jamais lancer en production sans validation.
4. Datastores et stockage
La page « Working with Datastores » (9.0) indique que les datastores sont des conteneurs logiques qui masquent les spécificités du stockage physique et que ESX et vCenter prennent en charge quatre types :
| Type | Description lue |
|---|---|
| VMFS (versions 5 et 6) | système de fichiers vSphere sur périphériques bloc |
| NFS (3 et 4.1) | client NFS intégré à ESX, volume exporté par un serveur NAS |
| vSAN | agrège les disques locaux des hôtes d'un cluster vSAN |
| vVol | conteneur de stockage Virtual Volumes |
Les opérations de base : renommer, démonter (unmount), supprimer (VMFS seulement), monter. Le chapitre « Stockage bloc NetApp » traite la baie ; ici on traite le côté hôte.
iSCSI. La page « Using ESX with iSCSI SAN » décrit l'initiateur iSCSI sur l'hôte, les cibles, le multi-chemin, et la prise en charge d'iSER (iSCSI sur RDMA).
Multi-chemin. « Understanding Multipathing and Failover » indique qu'ESX supporte le multi-chemin (plusieurs chemins physiques entre hôte et périphérique) pour la tolérance de panne (failover) et la répartition de charge, et que les E/S d'une VM peuvent être retardées jusqu'à 60 secondes pendant un basculement de chemin. ESX gère les pannes d'HBA et de processeur de stockage. Pour iSCSI, la page précise des cas de combinaison non pris en charge (par exemple adaptateur matériel indépendant avec iSCSI logiciel) ; lire la page avant de concevoir.
Suppression d'un datastore. La page « Remove VMFS Datastores » (9.0) : la suppression détruit le datastore, qui disparaît de tous les hôtes ayant accès ; elle supprime définitivement tous les fichiers des machines virtuelles du datastore. Prérequis cités : retirer ou migrer les VM, démonter le datastore de tous les hôtes, désactiver Storage DRS et Storage I/O Control pour ce datastore, vérifier qu'il n'est pas utilisé pour les heartbeats vSphere HA. Le démontage est préférable avant suppression. Cette opération s'effectue dans le vSphere Client (via vCenter) ou le Host Client.
- Contexte : vSphere Client sur vCenter 9.0 (ou Host Client 9.0).
- Droits : rôle autorisant la suppression de datastores (non détaillé : non vérifié).
- Effet : destruction du datastore et des fichiers de VM.
- Vérification : le datastore n'apparaît plus dans l'inventaire.
- Retour arrière : aucun sans sauvegarde ; la donnée est perdue.
- Ne jamais lancer en production sans validation.
Vérification : classer « renommer », « démonter », « monter », « supprimer » par ordre de risque et justifier.
5. Machines virtuelles, snapshots et migration
Snapshots. « Manage Virtual Machines With Snapshots » (9.0) : un snapshot préserve l'état et les données d'une VM à un instant donné, il s'applique à une VM (un snapshot par VM pour plusieurs VM) et la page le présente comme une solution à court terme pour des tests ou des mises à jour. Les opérations listées : prendre, revenir en arrière (revert), supprimer, consolider. La recherche web a résumé que des disques delta redondants peuvent dégrader les performances : point de la page 8.0/7.0 non relu en 9.0. Un snapshot de VM n'est pas un snapshot de baie (voir le cours NetApp).
Migration. « vSphere Virtual Machines Migration » : la migration à chaud (vSphere vMotion) déplace une VM allumée d'une ressource de calcul ou d'un stockage à un autre sans interruption de disponibilité ; la migration à froid concerne une VM éteinte ou suspendue. Usage cité : vider un hôte pour une maintenance.
Vérification : expliquer pourquoi un snapshot de VM conservé plusieurs semaines est une mauvaise pratique selon la présentation « court terme » de la documentation.
6. Maintenance d'un hôte
La page « Place an ESX Host in Maintenance Mode in the VMware Host Client » (9.0) indique :
- le mode maintenance est utilisé par exemple pour mettre à niveau ou ajouter de la mémoire ;
- avant d'y entrer, il faut éteindre toutes les VM de l'hôte ou les migrer (à la main ou via DRS) ;
- l'hôte reste « en entrée de maintenance » tant que des VM sont actives ; une fois en maintenance, il ne permet plus de déployer ni d'allumer une VM ;
- on y reste jusqu'à une action « Exit maintenance mode » ;
- si DRS doit évacuer les VM et qu'un délai expire, une erreur apparaît.
Pour un hôte géré par vCenter, la page « How to Remove an ESX Host from Your vCenter Instance » (9.0) précise que si l'hôte est dans un cluster, on le met d'abord en maintenance ; dans un cluster DRS, vSphere tente d'évacuer les VM allumées par vMotion.
- Contexte : Host Client ou vSphere Client, 9.0.
- Droits : administrateur de l'hôte ou rôle vCenter adapté (détail non vérifié).
- Effet : évacuation ou arrêt des VM ; hôte indisponible pour de nouveaux déploiements.
- Vérification : l'icône et le résumé de l'hôte indiquent la maintenance.
- Retour arrière : « Exit maintenance mode ».
- Ne jamais lancer en production sans validation (fenêtre, capacité restante du cluster, règles d'affinité).
Redémarrer ou arrêter un hôte. La page 8.0 « How to Reboot or Shut Down Your ESXi Host » demande d'éteindre ou migrer les VM puis de mettre l'hôte en maintenance, et mentionne ESXCLI pour l'arrêt/redémarrage ; la page 9.0 équivalente n'a pas pu être lue (contenu vide à l'extraction) : comportement en 9.0 non vérifié. Éteindre un hôte le déconnecte de vCenter mais ne le retire pas de l'inventaire.
7. Retirer un hôte de vCenter
La page 9.0 : retirer un hôte arrête la gestion par vCenter. Préconditions : montages NFS actifs (sinon l'opération échoue), hôte retiré d'un commutateur distribué, idéalement hôte connecté ; retirer un hôte déconnecté ne supprime pas l'agent vCenter sur l'hôte. Effet : vCenter retire l'hôte et les machines virtuelles associées de l'inventaire vCenter et libère les licences. Ce n'est pas une destruction des VM sur l'hôte, mais l'inventaire vCenter (dossiers, permissions, historique) est perdu pour ces objets : à valider avant. Ne jamais lancer en production sans validation.
8. ESXCLI : diagnostic en lecture
La référence ESXCLI (9.1.0 la plus récente, 9.0.0 disponible) précise que l'ensemble de commandes permet d'exécuter des commandes d'administration courantes, que la liste dépend du système, et d'utiliser esxcli --help.
Commandes de lecture citées par les pages NetApp pour ESXi (non exécutées ici) :
esxcli storage nmp device list -d <identifiant-naa-synthétique>esxcli storage nmp path list -d <identifiant-naa-synthétique>esxcli nvme adapter listesxcli nvme info getesxcfg-mpath -bBloc actif : la touche C copie la commande seule, sans invite ni sortie.
- Contexte : shell de l'hôte (SSH ou console) activé selon la politique de sécurité, ou ESXCLI à distance ; syntaxe issue de pages ESXi 8.x.
- Droits : utilisateur de l'hôte avec droits d'administration.
- Effet : lecture de l'état multi-chemin/NVMe.
- Vérification : sortie cohérente avec l'inventaire du stockage.
- Retour arrière : sans objet (lecture seule).
- Précaution : l'activation de SSH/ESXi Shell est une décision de sécurité (non détaillée ici : non vérifié dans les pages lues).
La plupart des autres commandes ESXCLI (storage, network, system) ont des effets d'écriture ; ne les utiliser qu'après lecture de la référence.
9. Cycle de vérification
Rouvrir les pages, noter les versions présentes dans le sélecteur, comparer à la version de Stéphane (à fournir), revalider les exigences (compatibilité matérielle via le Broadcom Compatibility Guide), garder ce document en brouillon.
Exercices et vérifications de fin de cours
Tous sont sur papier ou en lecture seule.
- Nommage. Pour 8.0 et 9.0, relever dans la documentation le nom du produit hyperviseur et celui du serveur de gestion.
- Exigences. Remplir un tableau {CPU, RAM, disque de boot, boot UEFI} pour ESX 9.0, avec la page source de chaque ligne.
- Datastore. Écrire la liste de contrôle avant la suppression d'un datastore VMFS fictif (cinq prérequis cités).
- Maintenance. Décrire dans l'ordre les états d'un hôte fictif d'un cluster de trois hôtes qui entre en maintenance, en citant les effets.
- Snapshots. Expliquer pourquoi un snapshot de VM ne remplace pas une sauvegarde (en citant la formule « court terme » de la documentation).
- Multipath. Interpréter la sortie fictive de la page NetApp « vSphere 8.x avec ONTAP » : combien de chemins optimisés ?
Critères de réussite
- Distinguer ESXi (8.0) et ESX (9.0) et les situer dans la documentation.
- Citer les prérequis d'une suppression de datastore et de la mise en maintenance.
- Dire ce qui n'a pas été vérifié (9.1, licences, redémarrage en 9.0).
- Ne jamais confondre version documentée et version en production.
Sources officielles
Toutes consultées le 17 octobre 2026.
Points non vérifiés
- Pages vSphere 9.1 ; compatibilité 9.1 avec la 9.0.
- Exigences matérielles ESXi 8.0 ; fin de support de chaque version.
- Licences, rôles et permissions détaillés ; activation de SSH.
- Redémarrage/arrêt en 9.0 (page 9.0 non extraite).
- Raisons du changement de nom ESXi -> ESX.