Comment surveiller un hyperviseur Hyper-V
Superviser un hôte Hyper-V : métriques de l'hôte, mémoire dynamique, état du service vmms, supervision des systèmes invités et pourquoi les seuils d'un serveur applicatif ne conviennent pas.
Protégez votre infrastructure dès aujourd'hui
Démarrez gratuitement, sans carte bancaire requise
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.
Le principe : l'hôte et les invités sont deux périmètres
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.
Ce qu'il faut mesurer sur l'hôte
Les métriques Windows standard
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.
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 tous les systèmes invités. C'est le service à surveiller en priorité sur un hôte.
Get-Service vmms
Get-VM | Select-Object Name, State, StatusLa mémoire, cas particulier
La 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 :
- la mémoire disponible sur l'hôte — si elle tombe trop bas, les invités ne pourront plus obtenir la mémoire dont ils ont besoin
- la pression mémoire de chaque invité, qui indique s'il obtient ce qu'il demande
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.
Les seuils, à adapter
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.
Ce qui doit être mesuré dans 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.
Les incidents typiques d'un hôte Hyper-V
- Le volume des VHDX saturé : toutes les machines virtuelles du volume se mettent en pause. Le plus large et le plus évitable.
- Les instantanés oubliés (points de contrôle) : un instantané conservé plusieurs mois peut dépasser la taille du disque d'origine et remplir le volume à lui seul.
- Le surengagement mémoire : plus de mémoire promise aux invités que l'hôte n'en possède. Fonctionne tant que les invités n'utilisent pas tout, jusqu'au jour où si.
- Les sauvegardes qui bloquent des instantanés : une sauvegarde interrompue peut laisser un point de contrôle qui grossit indéfiniment.
- Le service vmms arrêté : la gestion des machines virtuelles devient impossible, même si les invités continuent de tourner.
Comment collecter ces métriques
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.
Avec Logiserv
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 le système à un groupe d'hyperviseurs, dont les seuils réseau sont assouplis pour tenir compte du trafic structurellement plus élevé.
Les systèmes invités reçoivent chacun leur agent et sont supervisés comme des serveurs à part entière.
- Détection du rôle
- Automatique
- Seuils hyperviseur
- Réseau assoupli
- Métriques Hyper-V natives
- Non couvertes
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.
Pour aller plus loin
- Comment surveiller Windows Server — la base, valable pour l'hôte
- Surveiller l'espace disque d'un serveur — la métrique critique sur un hyperviseur
- Installer Zabbix Agent 2 sur Windows — sur l'hôte comme dans les invités
- Quelles métriques surveiller sur un serveur — le plan général
- Supervision serveur Windows et Linux : le guide — la démarche complète
Protégez votre infrastructure dès aujourd'hui
Démarrez gratuitement, sans carte bancaire requise
Les autres services
Comment surveiller Windows Server : métriques et alertes utiles
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.
Quelles métriques surveiller sur un serveur ? Le plan essentiel
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 en 15 min
Installer Zabbix Agent 2 sur Windows Server ou Windows 10/11 en 15 minutes : MSI officiel, service Windows, zabbix_agent2.conf, chiffrement PSK, port 10050 et commandes de vérification.