Lors d’une session de formation partenaire chez Nutanix, un problème a fréquemment été soulevé par de nombreux consultants présents : le non-fonctionnement de l’option de déploiement automatique en masse des Nutanix Guest Tools (NGT) via Prism Central. Ce sujet est crucial car le déploiement des NGT est souvent une étape essentielle dans l’optimisation des environnements Nutanix.
La nécessité d’utiliser le port 2074 pour la communication réseau est bien connue, car avant la version AOS 6.6, les machines virtuelles (VMs) avaient besoin de communiquer avec les Controller VMs (CVMs) via ce port, ce qui pouvait représenter une contrainte significative dans certains environnements.
Cependant, il existe également des prérequis spécifiques liés au système d’exploitation invité (Guest OS) qui ne sont pas toujours clairement indiqués. Bonne nouvelle : ces contraintes sont allégées avec la sortie de la version AOS 6.6.
Pour ceux qui déploient des serveurs Windows, il y a une autre considération technique à prendre en compte : Windows Remote Manager Service (WinRM). Selon la documentation officielle de Nutanix :
Note: Windows Remote Manager Service (winrm) is required to install NGT from Prism Central only. It is not required when you upgrade NGT or install NGT manually by logging in to the guest VM.
Cependant, ce qui n’est pas forcément évident, c’est le détail du protocole de communication que WinRM utilise. Comme indiqué dans la base de connaissances de Nutanix sur “How To Configure WinRM for Remote Management“, Windows est configuré par défaut pour utiliser le protocole HTTP, qui opère sur le port 5985. Or, Prism Central s’attend à une communication sur le port 5986, qui utilise le protocole HTTPS, plus sécurisé.
Ce petit détail peut être source de complications lors de tentatives de déploiement automatique de NGT depuis Prism Central. Il est donc essentiel de configurer WinRM pour utiliser HTTPS afin d’assurer une communication fluide et sécurisée.
Mais comme indiqué dans la KB How To Configure WinRM for Remote Management, par défaut Windows est configuré en HTTP qui correspond au port 5985, mais comme vous pouvez le voir sur le tableau du dessus, Prism s’attend à communiquer sur le port 5986 donc en HTTPS.
Toutes les commandes de cet article sont exécutées depuis une invite PowerShell élevée.
Solution : Configurer le transport HTTPS
- Lancez PowerShell en tant qu’administrateur.
- Listez la configuration WinRM actuelle. Par défaut (nouvelle installation), seul le listener HTTP doit être configuré
PS C:\> winrm e winrm/config/listener - Liste des sockets ouverts. Par défaut (nouvelle installation), vous devriez voir le port 5985 en écoute :
PS C:\> netstat -na | findstr 598Vous devriez avoir un listener HTTP configuré avec les paramètres par défaut et le port 5985 en écoute. - Autoconfigurez WinRM. Cela réinitialise le listener HTTP existant aux paramètres par défaut et effectue d’autres opérations de configuration nécessaires.
PS C:\> winrm quickconfig - Activez l’authentification de base pour WinRM
PS C:\> winrm set winrm/config/service/auth "@{Basic=""true""}" - Créez un certificat SSL auto-signé et configurez le transport HTTPS de WinRM. Les trois commandes ci-dessous se basent les unes sur les autres.
PS C:\> $my_hostname = [system.net.dns]::gethostname()PS C:\> $my_certificate = new-selfsignedcertificate -dnsname $my_hostname -certstorelocation cert:\localmachine\myPS C:\> winrm create winrm/config/listener?address=*+transport=https "@{hostname=""$my_hostname"";certificatethumbprint=""$($my_certificate.thumbprint)""}"
- Validez à nouveau avec
PS C:\> winrm e winrm/config/listener PS C:\> netstat -na | findstr 598Vous devriez maintenant avoir des listeners HTTP et HTTPS configurés avec les paramètres par défaut et les ports 5985 et 5986 en écoute. - Validez et/ou configurez le pare-feu Windows pour autoriser les connexions entrantes.
- Expérimentez et déterminez pour quel(s) profil(s) vous souhaitez autoriser l’accès. Pour cet article, les commandes ci-dessus ajoutent les règles aux trois profils.
- Liste des règles de pare-feu existantes. Recherchez les règles répertoriées pour les ports 5985 et 5986 et vérifiez qu’elles sont activées pour tous les profils
PS C:\> Get-NetFirewallPortFilter -Protocol TCP | Where { $_.localport -match '598' } | Get-NetFirewallRule- Si les ports de l’étape précédente sont absents, ajoutez l’une ou l’autre des nouvelles règles de pare-feu ci-dessous (en fonction de ce qui manque ci-dessus)
PS C:\> New-NetFirewallRule -name "Windows Remote Management (HTTP-In)" -displayname "Windows Remote Management (HTTP-In)" -description "Règle entrante pour la gestion à distance de Windows via WS-Management. [TCP 5985]" -group "Gestion à distance de Windows" -Program "System" -protocol TCP -localport "5985" -action Allow -profile Domaine,Privé,PublicPS C:\> New-NetFirewallRule -name "Windows Remote Management (HTTPS-In)" -displayname "Windows Remote Management (HTTPS-In)" -description "Règle entrante pour la gestion à distance de Windows via WS-Management. [TCP 5986]" -group "Gestion à distance de Windows" -Program "System" -protocol TCP -localport "5986" -action Allow -profile Domaine,Privé,Public
- Vous devriez maintenant avoir des listeners HTTP et HTTPS configurés avec les paramètres par défaut et les ports 5985 et 5986 en écoute. Utilisez l’étape 1 ci-dessus pour valider l’ajout de ces règles après avoir exécuté ces éléments.
Une fois WinRM correctement configuré pour accepter les demandes HTTPS, les obstacles au déploiement de NGT via Prism Central devraient être significativement réduits. Assurez-vous simplement de respecter les autres prérequis systèmes et réseau, même si WinRM est souvent le point bloquant dans ce processus.
Astuce : Le port 5986 doit être ouvert pour permettre la communication HTTPS entre Prism Central et les serveurs Windows.
Pour les administrateurs qui déploient NGT sur des serveurs Linux, la tâche est généralement plus simple. Le seul prérequis clé est l’ouverture du port 22, ce qui facilite grandement le processus de déploiement.
