Étiquette : Prism Central

Le Défi du Déploiement Automatique de NGT avec Prism Central

29 septembre 2023 by mgioia·0 Commentaire

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 598 Vous 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\my
- PS 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 598 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.
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é,Public
  - PS 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.

Nutanix CE 2.0, Part III

6 mars 2023 by mgioia·0 Commentaire

Toujours dans ma série Nutanix CE 2.0, voici la suite de Nutanix CE 2.0, Part II – VM AT WORK.

Avant tout, il convient de finaliser quelques configurations pour le cluster.

Je vais ajouter un nom à mon cluster ainsi qu’une adresse VIP. Cette adresse IP, en plus de toutes les adresses des CVM, permettra de joindre le cluster.

J’ajoute également une adresse pour la distribution du service iSCSI. Bien que cela ne soit pas indispensable pour l’instant, cela me sera utile ultérieurement.

Je vais maintenant déployer mon Prism Central.

Il est à noter qu’un “Small PC” est déjà considérable, il faudrait un PC “tiny” pour les environnements de lab.

Je choisis donc de créer un nouveau réseau avec une configuration minimale, sans activation du VLAN tagging ni gestion avancée des adresses IP.

Je rajoute le masque de sous-réseau, la passerelle et mes DNS, et je laisse le conteneur par défaut.

Enfin, j’attribue un nom original “PrismCentral” à la VM et lui ajoute une adresse IP.

Grâce à ces quelques clics, une appliance va se déployer sur mon environnement.

Après une bonne demi-heure, le déploiement est terminé.

Je me connecte à l’adresse IP https://192.168.0.200:9440 afin de modifier le mot de passe par défaut.

Je peux maintenant interconnecter Prism Element avec Prism Central que je viens d’installer.

Lors de la première connexion, il faudra entrer les informations demandées et accepter le contrat EULA.

Je conserve bien entendu Pulse activé.

Enfin, j’arrive sur le tableau de bord principal de Prism Central. Comme indiqué, j’ai accès à une version d’essai de 90 jours de Prism Ultimate. Nous explorerons cela plus en détail dans les prochains articles pour en optimiser l’utilisation.

Désenregistrer Prism Element d’un Prism Central

13 décembre 2022 by mgioia·0 Commentaire

Depuis Prism Element :

ncli multicluster remove-from-multicluster external-ip-address-or-svm-ips=pc-name-or-ip username=pc-username password=pc-password force=true

nutanix@cvm$ ncli multicluster get-cluster-state

Récupérer l’uuid.

nutanix@cvm$ ncli cluster info

Depuis PC :

nutanix@pcvm$ python /home/nutanix/bin/unregistration_cleanup.py uuid

Récupérer l’uuid.

nutanix@pcvm$ ncli cluster info

Depuis PE:

nutanix@cvm$ python /home/nutanix/bin/unregistration_cleanup.py uuid

AHV VM Templates

29 octobre 2022 by mgioia·0 Commentaire

D’aussi loin que je me souvienne, il y a toujours eu un mécanisme de gestion d’images sur Nutanix. On pouvait y ajouter des ISO, mais aussi des disques. On pouvait aussi préparer une VM pour s’en servir de template et la cloner.

J’ai souvent proposé cette méthode à mes clients pour maintenir à jour une VM qu’on considérait comme un template, et qu’on nommait comme tel pour l’identifier. Le détail de cette méthode est documenté dans la KB8814 – How to create VM template on AHV cluster.

Lors de la création de VM, on a aussi la section Custom Script qui permet la réalisation des opérations de customisations sur la machine avec un script :

Maintenant, ces options de personnalisations sont intégrées dans une fonctionnalité Template apparu avec Prism Central 2022.1.

Depuis la vue VM de Prism Central, sélectionner la VM qui vous intéresse, puis dans le menu du clic droit choisir Create VM Template :

Choisir un nom et une description. C’est la section Guest Customization qui ajoute des options intéressantes en fonction de l’OS :

Pour Windows ce sera Sysprep et pour Linux Cloud-init. Chaque type de script pourra soit être utilisé avec un script personnalisé, soit utiliser la configuration guidée pour choisir les informations de login – mot de passe ou clé SSH, les paramètres régionaux, le nom de l’hôte, la jonction au domaine et la clé de licence.

Exemple de Guide Script pour Windows :

Toujours pour Windows, je vous conseille le site Windows Answer File Generator qui permet de créer simplement un fichier unattend.xml que vous pourrez utiliser dans Custom Script :

Exemple Linux de Guided Script :

Pour Linux, de nombreux exemples sont disponibles sur cloudinit.readthedocs.io dans la section ***Exemples.*** Cela vous donnera une idée des énormes possibilités de personnalisation :

Une fois les personnalisations définies, on arrive sur un résumé puis on peut sauvegarder le template.

Depuis le menu Templates de Prism Central, nous allons pouvoir déployer des VM depuis notre template récemment créé :

Je donne un nom à la ou les futures VM, je sélectionne le cluster de destination du déploiement, j’indique le nombre de machines à déployer et, le cas échant, l’index de numérotation initial pour l’incrémentation :

Pour l’exemple d’après, je sélectionne l’option Advanced Deploy :

Le menu propose maintenant de personnaliser les ressources CPU et Mémoire :

Puis de modifier l’emplacement réseau. Il est possible de fixer une IP statique si on ne crée qu’une VM à la fois :

Dans la 3^e partie, on peut revoir les catégories associées (il faut que la VM qui a servi pour le template soit déjà dans une catégorie) et la timezone, si cela est permis, on peut modifier le script de customisation :

Apres avoir cliqué sur Deploy, une tâche est créé et le provisionnement des VM débute:

Dernier point intéressant : depuis le menu Templates, sélectionner le template à modifier, puis, dans le menu Actions deux options sont disponibles :

Update Guest OS permet de mettre à jour la VM, pour installer des mises à jour de sécurité, par exemple ou pour le déploiement de nouveaux programmes. L’option permet de déployer une machine, de l’éditer, puis d’apporter les modifications au template :

Je mets à jour la machine, puis je l’éteins.

Je retourne dans le menu Templates de Prism Central et, je sélectionne le template que je viens d’éditer. Il est facilement repérable car il a le statut Update Initiated …

Je choisis si je conserve les modifications en cliquant sur Complete Guest OS Update, ou si les annule avec Cancel Guest OS Update :

En choisissant Complete Guest OS Update, je donne un nouveau nom de version, une description claire de ce que j’ai réalisé dans la machine et j’active ce nouveau template:

La version active du template est mise à jour avec nos dernières modifications :

L’autre option du menu Actions consiste à changer les paramètres du template avec Update Configuration :

Ces nouveaux paramètres peuvent s’appliquer soit à la version active soit à n’importe quelle version précédente du template permettant leur réactivation. Ils concernent toutes les étapes, de 1 à 4, de création du template:

Voilà qui conclut notre tour d’horizon des templates à la sauce Nutanix, n’hésitez pas à partager l’article sur les réseaux s’il vous a aidé à y voir plus clair.

Connecter Nutanix CE 2019.11.22 à Prism Central 5.11.2.1

6 février 2020 by mgioia·2 Commentaires

Si comme moi, vous avez un environnement Nutanix CE Nested avec peu de puissance, il n’est pas forcement évident d’héberger une VM Prism Central sur celui-ci, j’ai tenté l’opération à plusieurs reprises et j’ai systématiquement eu un kernel panic sur la VM.

J’ai donc installé le dernier Prism Central sur une autre infrastructure et je souhaite maintenant y connecter la Community Edition. Pour information cette configuration n’est vraiment pas idéale car de nombreuses options de Prism Central ne seront pas disponibles s’il n’est pas hébergé sur le cluster Nutanix.

Normalement il suffit simplement de cliquer sur Register or create new

Comme dit précédemment le Prism Central est déjà installé, je cherche simplement à m’y connecter.

Un résumé de l’impact de l’intégration du Prism Element à Prism central apparaît.

Je rentre les informations de connexion, puis je valide la connexion.

Malheureusement l’opération ne s’exécute pas entièrement.

L’opération échoue dès la vérification des prérequis avec le message d’erreur : The AOS version 2019.11.22 of this cluster is not compatible with the Prism Central version 5.11.2.1

The AOS version 2019.11.22 of this cluster is not compatible with the Prism Central version 5.11.2.1

Pour éviter cette erreur, il faut modifier le fichier json de compatibilité sur la VM Prism Central.

Le fichier se trouve à l'emplacement : 
~/prism/webapps/PrismGateway/WEB-INF/classes/prism_central_compatibility.json

J'en fait une copie par sécurité :
cp ~/prism/webapps/PrismGateway/WEB-INF/classes/prism_central_compatibility.json ~/prism/webapps/PrismGateway/WEB-INF/classes/prism_central_compatibility.json.bck

 puis je modifie comme suit :

{"minimum":"5.5","maximum":"2019.11.22","exceptions":{"versions":["5.6","5.8"]}}

Une fois le fichier modifié et sauvegardé, je retente l’opération qui cette fois est un succès.

Le Prism Element de la Comunity Edition est maintenant connecté à la dernière version en date de Prism Central !