PowerCLI

Il est parfois nécessaire de retrouver qui a fait une modification sur une VM, ne serait-ce que pour s’assurer que c’était bien volontaire, mais aussi éventuellement pour le fouetter nu avec les orties si jamais il a supprimé la VM que vous veniez de finir d’installer. Pour cela, on peut s’appuyer sur les informations renvoyées par Get-VIEvent.

A l’occasion de certaines opérations, comme la suppression d’une VM ou son Storage vMotion, il peut rester des répertoires (contenant ou non des fichiers) qui peuvent alors être source de confusion. Il peut y avoir aussi des répertoires créés manuellement mais qui auraient du disparaître, des VMs qui ont été supprimées de l’inventaire au lieu d’être effacées, etc.

En production, avec une infrastructure importante gérée par plusieurs personnes, il n’est pas rare qu’on s’aperçoive que telle ou telle VM a un snapshot actif sans qu’on sache s’il est toujours nécessaire ou si on peut le supprimer. Le descriptif n’est pas toujours parlant, et il faut donc s’adresser à l’auteur du snapshot. Cependant si lister les snapshots des VMs n’est pas compliqué (un simple « Get-VM | Get-Snapshot » renvoie le résultat), il manque une information importante dans ce que renvoie Get-Snapshot : l’auteur du snapshot.

Il peut arriver qu’une VM ait un snapshot « fantôme ». L’interface ne montre aucun snapshot pour cette VM, et pourtant si on regarde dans le répertoire de la VM sur le datastore, on s’aperçoit qu’il y a bel et bien des disques de snapshot (fichier *-000001.vmdk par exemple).

Dans plusieurs vues il y a une représentation graphique simplifiée de la consommation de certaines ressources. Par exemple, la vue hosts permet de visualiser rapidement la consommation CPU et Mémoire des différents ESXi. Cependant, il n’y a pas d’équivalent pour les datastores : les données de remplissage sont uniquement sous formes de chiffres. De plus, si on a des clusters de datastores, il faut aller dans chaque cluster pour voir le remplissage de chaque datastore.

Les clusters de datastores sont pratiques pour faire de l’équilibrage entre datastores. L’inconvénient est qu’on ne sait pas à première vue sur quel(s) datastore(s) sont les VMs : le réumé de la VM n’affiche que le nom du cluster de datastores. On peut facilement retrouver l’information en éditant les propriétés de la VM, et en consultant l’emplacement du vmx et des vmdk. Cependant, sur un template, il n’est possible pas d’éditer les propriétés. Il faudrait convertir le template en VM puis reconvertir celle-ci en template une fois l’info trouvée.

SSH et le Shell peuvent s’avérer utiles sur les ESXi, cependant il est préférable de les désactiver en environnement de production, pour des raisons de sécurité. Il est bien sûr possible de le faire dans l’onglet Configuration de chaque ESX, section Security Profile, mais avec de nombreux hosts, il est bien plus simple de le faire par script. D’autant que ce script peut être relancé à volonté pour faire le ménage sur les services qu’on a oublié de désactiver.

La synchronisation horaire est souvent un élément important dans une infrastructure. En cas de disparités, on peut rencontrer des problèmes. Par exemple, un trop forte désynchronisation peut poser des problèmes d’authentification avec les services Kerberos de Windows. Mais il est compliqué aussi de rechercher des éléments simultanés dans les logs de plusieurs serveurs s’ils ne sont pas à la même heure.

Lorsque les serveurs de stockage iSCSI changent, il faut supprimer les anciennes cibles dans la configuration des ESXi. La suppression d’une cible iSCSI est une opération longue, et d’autant plus fastidieuse qu’il faut la répéter sur tous les hosts. Avec le risque de cliquer sur la mauvaise ligne et supprimer une cible en cours d’utilisation.

Dans certains cas, un serveur peut avoir besoin de joindre de nombreuses cibles iSCSI. Il faut donc toutes les définir, et sur chacun des hosts. C’est une opération longue, fastidieuse et source d’erreur si on la fait manuellement.

Selon les systèmes de stockage, il peut être nécessaire de configurer le multipathing des datastores en mode Round Robin pour une meilleure gestion des I/O. Et dans ce cas, il peut aussi s’avérer nécessaire de configurer le nombre d’opérations disque à effectuer sur le path en cours avant de passer au path suivant.

Les logs sont utiles aussi bien pour le diagnostic et la recherche de panne que pour les audits. Mais encore faut-il que les logs soient encore disponibles lorsqu’on en a besoin. Il est fréquent qu’on s’aperçoive que les logs recherchées ont disparues, soit du fait de la rotation normale des ficher de logs, soit de la non persistance de leur stockage.