Superviser un hôte Hyper-V : métriques de l'hôte, mémoire dynamique, état du service vmms, supervision des machines invitées et pourquoi les seuils d'un serveur applicatif ne conviennent pas.
Un hôte Hyper-V occupe une place particulière dans un parc : son arrêt n'affecte pas un service, mais tous ceux qu'il héberge. Sa supervision mérite donc un traitement distinct de celui d'un serveur applicatif — avec des seuils différents, et une répartition claire entre ce qui se mesure sur l'hôte et ce qui doit l'être dans les invités.
C'est la confusion la plus fréquente. Superviser l'hôte Hyper-V ne supervise pas les machines virtuelles qu'il héberge.
Depuis l'hôte, vous voyez qu'une machine virtuelle est démarrée et combien de ressources elle consomme. Vous ne voyez pas si son disque système est plein, si son service applicatif est arrêté ou si sa base de données répond. Ces informations n'existent qu'à l'intérieur de l'invité.
La règle pratique : un agent sur l'hôte, et un agent dans chaque machine virtuelle dont le service compte. Les deux périmètres sont complémentaires, aucun ne remplace l'autre.
Un hôte Hyper-V reste un serveur Windows. Espace disque, mémoire, processeur et services s'y surveillent de la même façon que décrit dans comment surveiller Windows Server.
Deux points appellent une attention particulière.
L'espace disque des volumes hébergeant les VHDX. Un volume saturé met en pause toutes les machines virtuelles qui y résident — pas seulement celle qui écrivait. C'est le scénario de panne le plus large possible sur un hyperviseur, et il découle d'une métrique triviale à surveiller.
Les autres services
Superviser un serveur Windows Server 2016 à 2025 : espace disque, mémoire, services, journal d'événements, Active Directory. Quelles métriques suivre, quels seuils, quels événements ignorer.
Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
Installer Zabbix Agent 2 sur Windows Server ou Windows 10/11 : téléchargement du MSI officiel, configuration de zabbix_agent2.conf, chiffrement PSK, ouverture du port 10050 et vérification du service.
Attention aux disques à taille dynamique : un VHDX de 500 Go alloué dynamiquement peut occuper 80 Go aujourd'hui et 400 Go dans six mois. La somme des tailles maximales des disques dépasse souvent la capacité réelle du volume — un surengagement qui ne pose problème que le jour où les invités remplissent réellement leurs disques.
Le service vmms (Gestion des machines virtuelles Hyper-V). Son arrêt affecte la gestion de toutes les machines invitées. C'est le service à surveiller en priorité sur un hôte.
Get-Service vmms
Get-VM | Select-Object Name, State, StatusLa mémoire est la ressource critique d'un hyperviseur, et sa lecture est trompeuse.
Avec la mémoire dynamique, Hyper-V alloue et reprend de la mémoire aux invités selon leurs besoins. Deux indicateurs comptent :
Une machine virtuelle sous pression mémoire persistante ralentit sans qu'aucune alerte ne se déclenche côté hôte : l'hôte, lui, va bien.
Prévoyez toujours une réserve pour l'hôte lui-même. Un hyperviseur dont toute la mémoire est allouée aux invités n'a plus de marge pour ses propres opérations.
Appliquer à un hyperviseur les seuils d'un serveur applicatif garantit des alertes permanentes. Un hôte de virtualisation présente une charge processeur, une activité disque et un trafic réseau structurellement plus élevés : c'est son fonctionnement nominal, pas une anomalie.
Concrètement : relevez les seuils de charge processeur et de trafic réseau sur les hyperviseurs, et gardez des seuils stricts sur l'espace disque et la mémoire disponible — les deux ressources dont l'épuisement affecte réellement les invités.
Chaque machine virtuelle dont le service compte doit recevoir son propre agent, et être supervisée comme un serveur à part entière : disque, mémoire, services applicatifs.
Une métrique spécifique mérite l'attention à l'intérieur des invités : le temps de vol du processeur (steal time sur les invités Linux). Une valeur élevée signale que la machine virtuelle était prête à travailler mais n'a pas obtenu de temps processeur — autrement dit, que l'hôte est surchargé.
C'est un signal précieux : il apparaît dans l'invité, mais la cause et la correction sont sur l'hôte.
L'agent Zabbix installé sur l'hôte remonte nativement les métriques Windows standard : disque, mémoire, processeur, services — ce qui couvre l'essentiel des incidents listés ci-dessus, dont les deux plus fréquents.
Pour les métriques spécifiques à Hyper-V — pression mémoire par invité, état individuel des machines virtuelles — Zabbix ne fournit pas de collecte native. Elles s'obtiennent via des compteurs de performance Windows ou des scripts PowerShell exposés en éléments personnalisés, ce qui suppose un travail de configuration propre à votre installation.
Dans la pratique, la supervision Windows standard de l'hôte plus un agent dans chaque invité couvre la grande majorité des incidents réels. Les métriques Hyper-V spécifiques apportent surtout du confort de diagnostic, rarement de la détection supplémentaire.
L'hôte Hyper-V est supervisé comme un serveur Windows, avec une particularité utile : la présence du service vmms est détectée à l'enrôlement et rattache automatiquement la machine à un groupe d'hyperviseurs, dont les seuils réseau sont assouplis pour tenir compte du trafic structurellement plus élevé.
Les machines invitées reçoivent chacune leur agent et sont supervisées comme des serveurs à part entière.
La présence du service vmms rattache l'hôte au groupe des hyperviseurs à l'enrôlement.
Les seuils de trafic tiennent compte de l'activité structurellement élevée d'un hôte de virtualisation.
Pression mémoire par invité et état individuel des VM demandent des éléments personnalisés.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.