VMware Manager : console de supervision et d'administration ESXi sans vCenter

Objectifs

• Superviser plusieurs hôtes ESXi depuis une console unique : inventaire, métriques, événements et alertes.
• Mesurer ce que la licence Free autorise réellement, canal par canal, avant d'implémenter quoi que ce soit.
• Agir sur les machines virtuelles par le seul canal d'écriture disponible, le shell de l'hôte, sans jamais composer une commande dynamiquement.
• Conserver l'historique que l'hyperviseur ne garde pas : métriques dans la durée et événements avant rotation.
• N'afficher une action que si elle a été mesurée comme possible sur l'hôte concerné.
• Installer et exploiter la solution en une commande, secrets générés et documentation d'exploitation à l'appui.

Architecture

L'application est découpée en couches : un modèle métier qui ne connaît aucun type VMware, un adaptateur qui porte la frontière avec l'hyperviseur, et deux transports derrière ce même adaptateur. La lecture passe par l'API SOAP de vSphere, seule voie disponible sous licence Free ; l'écriture passe par le shell de l'hôte en SSH. Un collecteur autonome interroge les hôtes en boucle et écrit dans la base ce que l'hyperviseur ne conserve pas. Le serveur est le seul composant qui parle aux hyperviseurs : le navigateur ne parle qu'à lui, et un seul flux entrant est nécessaire, le HTTPS de l'interface. Cette séparation correspond à la topologie visée, où les hôtes ESXi sont sur un réseau distinct de celui qu'atteignent les administrateurs.

Étapes de réalisation

Configurations

• Registre de commandes fermé, aucune chaîne construite

  Agir par le shell d'un hyperviseur revient à exécuter des commandes privilégiées à distance : c'est le point le plus sensible de l'architecture. Aucune commande n'est composée dynamiquement. Un registre déclaratif liste chaque commande autorisée avec ses paramètres typés et bornés, la capacité qu'elle exige et son délai maximal ; toute commande absente du registre est impossible à exécuter, et il n'existe aucune API générique « exécuter une commande ». Le protocole SSH ne transportant qu'une chaîne interprétée par le shell distant, la sécurité repose sur deux couches indépendantes : validation typée des paramètres, puis échappement de chaque argument.

• Certificat et clé d'hôte épinglés au premier contact

  Un ESXi est livré avec un certificat auto-signé. Trois modes sont proposés à l'ajout d'un hôte : vérification stricte contre une autorité d'entreprise, épinglage de l'empreinte relevée au premier contact, ou désactivation, réservée au laboratoire et accompagnée d'un avertissement permanent et d'une trace d'audit. Le même principe s'applique à la clé d'hôte SSH : relevée au premier contact, épinglée, puis exigée avant tout envoi d'identifiant. Une clé qui ne correspond plus fait échouer la tâche avant l'authentification.

• Capacités mesurées plutôt que supposées

  Une fonction dont la disponibilité n'a pas été mesurée sur l'hôte n'est pas offerte : l'état « inconnu » n'est jamais traité comme permissif. Une fonctionnalité indisponible sous licence Free n'est ni implémentée, ni simulée, ni affichée. C'est ce qui évite le défaut classique d'une console d'administration : proposer un bouton qui échoue au moment où on l'utilise.

• Secrets, journalisation et confirmations

  Les identifiants des hyperviseurs sont chiffrés avec une clé maître qui vit hors du code, dans un fichier de configuration en droits restreints. Un processeur de rédaction empêche tout mot de passe ou toute clé d'atteindre les journaux. Les actions destructives demandent une double confirmation avec saisie du nom de la machine, et une seule action d'alimentation peut être en vol par machine virtuelle. Si le canal d'écriture devient indisponible, l'hôte bascule de lui-même en lecture seule au lieu de renvoyer des erreurs.

Procédures

• Monter une maquette avant de conclure quoi que ce soit

  Sans matériel dédié, l'hyperviseur d'essai est installé en machine virtuelle sur un hôte support. Le script qui prépare la maquette n'agit qu'avec un drapeau explicite et affiche d'abord ce qu'il ferait, l'hôte support étant le plus souvent un serveur en service. Il crée un groupe de ports dédié plutôt que d'assouplir la politique d'un groupe existant, qui exposerait les machines déjà rattachées.

• Sonder un hôte réel sans rien casser

  Le sondeur s'exécute depuis une machine ayant une route vers le réseau des hyperviseurs, le mot de passe étant saisi masqué, absent de l'historique du shell comme de la liste des processus. Il ne procède à aucune écriture par défaut ; la sonde d'écriture démarre réellement la machine désignée, et n'est donc utilisée que sur une machine dédiée, éteinte et sans données.

• Sauvegarde et restauration de la console

  La console est la mémoire du système : elle conserve les métriques et les événements que l'hyperviseur perd. La procédure de sauvegarde et de restauration couvre les hôtes, les machines virtuelles, les événements, les métriques, les agrégats continus et le journal d'audit ; elle a été rejouée intégralement le 16 septembre 2026.

Environnement

• VMware ESXi 8.0.3 build 24677879 sous licence vSphere 8 Hypervisor (Free)
• Maquette ESXi imbriquée, montée sur un hôte support pour éprouver la licence
• Serveur en Python : FastAPI, pyVmomi pour la lecture SOAP, SSH pour l'écriture
• PostgreSQL 16 avec TimescaleDB pour les métriques et les événements
• Interface TypeScript, servie par Caddy en HTTPS
• Quatre conteneurs Docker Compose : web, api, collector, base de données

Technologies

• VMware
• Docker
• Python
• TypeScript
• Caddy
• Git

Tests réalisés

• Mesure méthode par méthode de ce que la licence refuse

  Dix-neuf méthodes d'écriture ont été appelées une à une sur l'hôte réel. L'hypothèse de départ, « toute écriture par API échoue », s'est révélée fausse dans sa généralité et vraie pour tout ce qui touche aux machines virtuelles : démarrage, arrêt, suspension, réinitialisation, instantanés, reconfiguration et création sont refusés, quand le mode maintenance de l'hôte et le dépôt de fichier sur une banque de données sont acceptés. La conséquence pour le produit est nulle, mais l'analyse de départ a été corrigée par la mesure.

• Validation du canal d'écriture, y compris son refus

  Les six actions d'alimentation et le cycle complet des instantanés ont été exécutés par l'API du produit sur une machine réelle, chaque résultat étant confronté à une lecture indépendante de l'hôte. Le cas d'échec a été testé autant que le cas nominal : avec une clé d'hôte volontairement fausse, la tâche échoue avant toute authentification, le journal de l'hyperviseur montre le rejet, et la machine n'a pas bougé.

• Collecte continue et mode dégradé

  Quarante-cinq minutes de collecte ininterrompue, trente-sept cycles d'événements, mille trois cent quarante-quatre événements tous distincts, aucun trou, aucune session laissée ouverte sur l'hôte. Un hôte pointé vers une adresse morte bascule hors ligne avec la cause, ses capacités sont retirées, son inventaire purgé, une alerte critique ouverte et plus aucune action n'est proposée.

• Interface éprouvée dans un navigateur

  Quinze tests de bout en bout sur la pile déployée, puis un parcours manuel : la fiche d'un hôte montre les capacités réellement mesurées, l'édition de licence et l'empreinte de la clé SSH avec la commande permettant de la vérifier depuis la console de l'hôte.

Résultats obtenus

• Console multi-hôtes fonctionnelle sans vCenter : inventaire, métriques, événements, alertes, journal d'audit et actions sur les machines virtuelles.
• Licence Free mesurée méthode par méthode sur un hôte réel, et non supposée : l'analyse initiale a été corrigée par la mesure.
• Six actions d'alimentation et cycle complet des instantanés validés sur une machine réelle, par l'API du produit, chaque résultat confronté à une lecture indépendante de l'hôte.
• Refus du canal d'écriture éprouvé : une clé d'hôte fausse fait échouer la tâche avant authentification, sans effet sur la machine visée.
• Quarante-cinq minutes de collecte continue sans trou ni erreur, et mode dégradé vérifié sur un hôte injoignable.
• Huit défauts du code révélés par le passage sur un hyperviseur réel, tous corrigés, dont deux qui rendaient la collecte inexploitable.
• Installation en une commande, idempotente, secrets générés et jamais régénérés ; sauvegarde et restauration rejouées intégralement.
• Documentation écrite avant le code et tenue à jour : analyse de licence, matrice de capacités, architecture, pile technique, exploitation et relevé de mesures.
• [À COMPLÉTER — MISE EN SERVICE SUR L'INFRASTRUCTURE CIBLE]

Difficultés rencontrées et solutions apportées

• Ce qu'un hyperviseur simulé ne peut pas apprendre

  Le développement s'est fait contre un ESXi simulé, ce qui permet de travailler sans matériel mais ne dit rien du comportement réel. Le premier hôte réel a révélé huit défauts, dont deux qui rendaient le produit inutilisable sans qu'aucun test ne le signale : le collecteur ne recueillait aucun événement, parce que la méthode de lecture employée n'existe pas sur un hôte autonome, et le canal d'écriture se déclarait indisponible sur tout hôte réel, parce qu'il demandait à un outil de l'hyperviseur un format de sortie que celui-ci ne propose pas.

• Des débits affichés cent fois trop petits

  Les compteurs de performance de l'hyperviseur ne partagent pas une unité commune : la charge processeur et la mémoire sont en centièmes de pourcent, quand le réseau et le disque sont en kilo-octets par seconde. Une conversion uniforme rendait donc les débits cent fois trop petits, sans qu'aucune erreur n'apparaisse. La conversion est désormais fondée sur l'unité déclarée par le compteur lui-même.

• Des identifiants d'événements qui repartent de zéro

  L'hyperviseur numérote ses événements, et cette numérotation recommence à un au redémarrage de l'hôte. La déduplication par numéro écartait donc en silence tous les événements postérieurs au redémarrage. L'unicité porte maintenant sur l'hôte, le numéro et l'horodatage, et un redémarrage est reconnu comme tel. La même campagne a montré que la rétention des événements se compte en nombre et non en durée, contrairement à ce qu'annonce la documentation publique.

• Une restauration d'instantané qui rallumait la machine

  Restaurer un instantané pris avec la mémoire rallume la machine virtuelle par défaut. Une restauration pouvait donc démarrer une machine sans que personne ne l'ait demandé, ce qui, sur une infrastructure de production, est exactement le genre d'effet de bord qu'une console d'administration ne doit pas avoir.

• Une horloge d'hôte en retard de près d'une heure

  Métriques et événements sont horodatés par l'hyperviseur. Sans service de temps configuré, l'hôte de laboratoire était en retard de cinquante-quatre minutes : un point de mesure tout juste relevé paraissait vieux d'autant, et la fenêtre d'une heure de l'écran des métriques n'en montrait que six. Le curseur de lecture des événements ne doit donc jamais dépendre de l'horloge locale, et le service de temps devient un prérequis d'exploitation.

Bilan

À compléterbilan et recul sur la réalisation

Liens