Superviser et piloter Hyper-V sans SCVMM : le guide pratique
Inventaire, performances, actions et analyse d'incident sur des hôtes Hyper-V et des clusters de basculement, sans SCVMM ni rien à installer sur les nœuds : prérequis, droits, pièges et limites.
Hyper-V revient dans beaucoup de plans de sortie de VMware. Les organisations très « Windows » disposent souvent déjà des licences Windows Server Datacenter, qui couvrent un nombre illimité de machines virtuelles Windows Server sur l'hôte licencié. Reste une question pratique : comment superviser et piloter un parc Hyper-V quand on n'a pas, ou plus, System Center Virtual Machine Manager ?
Ce guide montre ce qu'il faut ouvrir, quels droits donner, ce qu'on obtient et ce qui reste hors de portée, sur des hôtes autonomes comme sur des clusters de basculement.
Hyper-V sans SCVMM : ce qu'on perd, ce qu'on garde
Sans SCVMM, l'administration repose sur le Gestionnaire Hyper-V, le Gestionnaire du cluster de basculement, Windows Admin Center et PowerShell. Ces outils font très bien le travail hôte par hôte ou cluster par cluster. Ce qui manque, c'est la vue d'ensemble : un inventaire consolidé, l'historique des performances, les risques, la capacité, et une seule console quand Hyper-V cohabite avec VMware ou Proxmox VE.
SCVMM apporte cette vue, mais au prix d'une infrastructure dédiée (un serveur de gestion et une base SQL Server), d'une licence System Center et d'une expertise que beaucoup d'équipes n'ont pas. C'est cet espace que NaoShift occupe : la supervision et les gestes courants, sans la gestion de la « fabric » propre à SCVMM.
Les prérequis
NaoShift se connecte aux nœuds par WinRM sur HTTPS, depuis son agent sortant installé sur une machine de votre réseau. Rien n'est installé sur les hôtes Hyper-V.
- WinRM en HTTPS (port 5986) sur chaque nœud, avec un certificat dont le nom couvre le FQDN du nœud, et celui du cluster si la connexion vise le cluster. Certificat de votre PKI d'entreprise, ou certificat auto-signé épinglé dans le connecteur par son empreinte SHA-256.
- Le pare-feu n'ouvre le 5986 qu'à l'adresse de la machine qui porte l'agent.
- La résolution DNS des noms des nœuds depuis cette machine.
- Un compte de collecte, de domaine ou local, authentifié en NTLMv2.
Le blocage le plus fréquent que nous rencontrons n'est ni un droit ni un mot de passe : c'est l'écouteur HTTPS de WinRM qui n'existe pas. Par défaut, WinRM n'écoute qu'en HTTP. Exemple de création, une fois le certificat importé dans le magasin de l'ordinateur :
$thumb = (Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like "*$env:COMPUTERNAME*").Thumbprint
New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $thumb -Force
New-NetFirewallRule -Name naoshift-winrm-https -DisplayName "WinRM HTTPS" -Protocol TCP `
-LocalPort 5986 -Direction Inbound -Action Allow -RemoteAddress <adresse de l'agent>
Les droits du compte de collecte, et une limite de Windows
Le compte de collecte appartient, sur chaque nœud, aux groupes Hyper-V Administrators, Remote Management Users, Performance Monitor Users et Event Log Readers. Sur un cluster, il reçoit un accès en lecture seule (Grant-ClusterAccess -ReadOnly).
Pourquoi Hyper-V Administrators pour une simple lecture ? Parce que Windows ne propose pas de rôle Hyper-V en lecture seule. Sans ce groupe, aucun compte ne voit les machines virtuelles, et le piège est sournois : l'interface WMI répond sans erreur, avec zéro machine. Un outil de supervision peut alors afficher un hôte vide comme si de rien n'était. NaoShift signale ce cas comme « non collecté », jamais comme « zéro VM ».
Pour compenser ce droit trop large, la collecte n'exécute qu'un script PowerShell en lecture seule, embarqué dans l'agent, dont les commandes sont contrôlées par une liste blanche.
Ce que la collecte remonte
- Les hôtes : matériel, édition et build de Windows Server, ce qui permet de rapprocher les vulnérabilités publiées par Microsoft.
- Les machines virtuelles : état, vCPU, mémoire de démarrage et mémoire dynamique, génération (donc firmware, Secure Boot, vTPM), version de configuration, services d'intégration, système et adresses IP de l'invité.
- Le stockage : disques VHDX dynamiques, fixes ou différentiels avec leur chaîne, disques pass-through, volumes partagés de cluster (CSV) et leur état.
- Le réseau : commutateurs virtuels, VLAN d'accès ou trunk, cartes physiques.
- La protection : checkpoints, Hyper-V Replica, rôles de cluster avec leur priorité.
- Les performances : CPU, attente CPU, IOPS et débit disque, réseau, mémoire dynamique.
Ce qui n'est pas collecté est dit comme tel : les étiquettes (seul SCVMM en porte), les partitions de l'invité, les licences, les chemins multiples et la santé des disques. Un nœud injoignable est signalé sans faire échouer la collecte du reste du cluster.
Agir depuis la même console
Plus de trente gestes sont disponibles sur Hyper-V : alimentation (avec un arrêt propre par les services d'intégration, jamais une coupure faute d'invité), checkpoints, vCPU et mémoire, renommage, version de configuration, clone depuis un modèle, suppression, disques, cartes réseau et VLAN, médias, migration à chaud entre nœuds, maintenance d'un nœud et haute disponibilité par rôle de cluster.
Les écritures suivent la règle commune à toutes les plateformes : lecture seule par défaut, écriture activée par cible avec un compte dédié, tracée avant exécution. Le compte d'action est distinct du compte de collecte. Chaque geste correspond à un script figé, dont les commandes sont listées une à une et les paramètres validés deux fois.
Une précision utile pour la haute disponibilité : Windows exige les droits d'administrateur local pour protéger une machine par un rôle de cluster, même avec un accès complet au cluster. Ce geste demande donc un compte d'action plus large que les autres.
Comprendre un incident
Quand un nœud ou un cluster tombe, une alerte nomme l'objet et donne les horaires réels. L'analyse de cause racine lit alors, à la demande, les journaux d'événements de chaque nœud : Hyper-V (gestion des machines, processus de travail, haute disponibilité, stockage, réseau), cluster de basculement et journal Système. Elle dit qui a fait quoi, par exemple quel compte a redémarré un nœud et avec quel motif.
Le compte de collecte suffit : son appartenance à Event Log Readers lui donne accès à ces journaux.
Les limites actuelles
Pour être complet : la console distante et le déploiement depuis un modèle ne sont pas encore disponibles sur Hyper-V, et l'authentification Kerberos n'est pas encore prise en charge. NaoShift ne remplace pas non plus la gestion de la fabric de SCVMM : déploiement des hôtes, réseaux logiques, bibliothèque et modèles de services.
Questions fréquentes
Faut-il installer un agent sur les hôtes Hyper-V ?
Non. L'agent NaoShift tourne sur une machine de votre réseau et se connecte aux nœuds par WinRM sur HTTPS. Rien n'est installé sur les hôtes ni dans les machines virtuelles.
NaoShift remplace-t-il SCVMM ?
Pour la supervision, l'inventaire, l'analyse des risques et les gestes courants, oui. Pour la gestion de la fabric (déploiement d'hôtes, réseaux logiques, modèles de services), non : ce n'est pas son rôle.
Les hôtes Hyper-V autonomes sont-ils pris en charge ?
Oui. Un hôte autonome et un cluster de basculement se connectent de la même manière. Pour un cluster, la connexion vise le cluster et chaque nœud est lu dans sa propre session.
Pour aller plus loin
La page Intégrations liste toutes les plateformes prises en charge. Pour brancher vos hôtes Hyper-V à côté de vos autres hyperviseurs, vous pouvez démarrer gratuitement ou nous écrire.