Comment effectuer la configuration minimale des Guest OS (reseau et hostname) avec vRealize Automation (Aria Automation)

vRealize Automation (vRA), faisant désormais partie de la gamme ‘Aria’ et récemment renommé en « Aria Automation », est un outil reconnu pour automatiser le déploiement des VMs dans les environnements multi-vCenter et multi-clouds.

Une étape indispensable est souvent source de difficultés et de confusions : il s’agit de la configuration des Guest OS déployés, c’est-à-dire le remplacement du hostname et la configuration IP de la VM clonée.

Cet article a pour but de faire le point et de tenter de clarifier les méthodes de configurations des Operating System Windows et Linux déployés depuis VMware Aria Automation. Vous pouvez aussi accéder directement au tableau récapitulatif que vous trouverez en fin d’article.

Définissons ce qu’est la 'configuration minimale des Guest OS'

Dans l’environnement virtuel on va favoriser le déploiement d’une nouvelle machine virtuelle par clone d’un template.  Ainsi, on obtient une nouvelle VM qui dispose des mêmes attributs que le template d’origine (même IP, même hostname, même configuration système…).

Dans la majorité des cas le clone ne suffit pas et il est indispensable de remplacer la configuration OS (SID, hostname, IP, masque, gateway, DNS server, DNS suffix, DNS search domain) provenant du template par les nouvelles propriétés de configuration de la VM déployée.  C’est ce que j’appelle la « configuration minimale des Guest OS »: les configurations indispensables pour l’identité de la VM (SID, hostname) et pour obtenir la communication réseaux.

A noter donc que certaines autres configurations (SSH, compte, groupe, cron, services…) bien que concernant le Guest OS sont exclues de cette dénomination arbitraire : « configuration minimale des Guest OS ». 

Méthodes possibles pour la 'configuration minimale des Guest OS'

La configuration minimale des Guest OS peut être réalisée de différentes manières :

1/ Script de ‘post install’ :  il s’agit d’exécuter des commandes (netplan nmcli…), a posteriori, apres le démarrage de la VM pour modifier la configuration: Méthode à oublier car non fiable, complexe et spécifique OS/Distrib/version. Je n’en parlerai donc pas.

2/ Configuration via vCenter : il s’agit de la configuration habituelle et historique effectuée par vCenter et que l’on va déclencher depuis « Aria Automation » en envoyant automatiquement toutes les propriétés de la VM.

    -  Nécessite un template de configuration sur vCenter « VM Customization Specifications» et la présence des VMtools dans la VM.

    -  Méthode intéressante si on est seulement VMware et si on ne connait pas cloud-init/cloudbase-init

3/ Configuration via Cloud-init / Cloudbase-init :  il s’agit des méthodes standards des guest OS respectifs Linux et Windows. Comme avec la configuration via vCenter, « Aria Automation » va automatiquement envoyer les propriétés de la VM.

   -   Impose une montée en compétence sur cloud-init/cloudbase-init

   -   Universel et très puissants

Remarques :

• Les scripts ‘runcmd’ lancés depuis cloud-init ou cloudbase-init sont des scripts de post-install et font donc bien partie de cette première catégorie. S'ils sont non recommandés pour les configurations Hostname & Réseaux, ils sont tout à fait appropriés pour d’autres tâches.
• Il est recommandé de ne pas mélanger ces méthodes de configuration. Soit on choisit de faire la configuration minimale des Guest OS par vCenter soit par Cloud-init/Cloudbase-init.

Configuration via vCenter 

Elle est très fiable, utilisée depuis longtemps et fonctionne avec tous les OS supportés par le vCenter. Le template VM doit avoir les VMtools installés et il est nécessaire de définir dans vCenter un fichier de configuration « VM Customization Specifications ».  Il faut bien comprendre que ce fichier n’est pas la configuration définitive, puisque les propriétés provenant d’Aria Automation (vRA) vont venir écraser ces configurations. Aria Automation va notamment envoyer les informations de hostname, d’IP, ainsi que les gateway, masque et DNS qu’il va trouver dans les « network profiles ».  Vous pouvez donc très simplement faire un seul « VM Customization Specifications » pour tous les Windows et un autre pour tous les Linux, en configuration DHCP. Et ce, même si les VMs déployées ne sont pas sur le même subnet, si on rajoute des vmnics, ou si on passe en IP statique… 

Dans ce cas de figure, il faut préciser dans le blueprint ( aka cloud template) d’Aria Automation (vRA)

1. - Qu’on effectue la configuration minimale via vCenter et pour cela on utilise la propriété  customizationSpec: true.
2. - Ne pas désactiver la configuration du Guest OS et donc mettre customizeGuestOs: true ou l'omettre. Bien entendu, il ne faut pas la mettre à 'false'. En réalité cette propriété sert surtout à désactiver facilement la Guest OS custom depuis le blueprint.

Configuration via Cloud-init / Cloudbase-init 

Cloud-init et Cloudbase-init sont cousins et adressent le même objectif : Le premier effectue la configuration des Guest OS Linux et le second celle des Guest OS Windows. Il faut donc dans le Template VM, installer et configurer Cloud-init/Cloudbase-init. Les VMtools doivent aussi être présents.

Elle est parfaitement décrite ici et ne nécessite donc pas de détail complementaire: https://docs.vmware.com/en/vRealize-Automation/8.9/Using-and-Managing-Cloud-Assembly/GUID-6A17EBEA-F9C3-486F-81DD-210EA065E92F.html

Elle est peut-être légèrement plus complexe. Il faut :

1. 1/ Installer le package cloud-init sur le Linux, si possible en dernière version
2. 2/ Configurer cloud-init dans le template :  /etc/cloud/cloud.cfg :
3.          - Avoir :  datasource_list: [ OVF ]   En mettre d’autres inutilement peu ralentir cloud-init (timeout)
4.          - Préférable de mettre disable_vmware_customization: false (voir ici)
5.          - La configuration réseau ne doit pas être désactivée (voir ici)
6.         - (optionnel) disable_root : false ou true   (Activer / Désactiver le login root)
7.         - (optionnel) ssh_pwauth: true  (acces SSH avec password)
8.  3/ Il est recommandé de mettre le CD virtuel de la VM qui deviendra Template en ‘passthrough’ : voir ici

Dans le cas de la configuration via cloud-init, un CD va être monté dans la VM pour passer les paramètres spécifiques provenant de vRA (Aria Automation).

Concernant le blueprint Aria Automation, dans ce cas de figure (cloud-init/cloudbase-init):

1. - « customizationSpec » doit être absent car on fait appel à cloud-init et pas à la config vCenter
2. - « customizeGuestOs » n’est pas à false car on ne veut pas désactiver la configuration du guest OS. Donc il est a ‘true’ ou est absent.

Enfin, sur les linux, pour éviter de faire une exécution de cloud-init à chaque reboot, il faut exécuter dans le « runcmd » de cloud-init:    touch /etc/cloud/cloud-init.disabled

Voici un exemple de blueprint utilisant la configuration cloud-init:

Résumé :

On peut résumer tout cela dans le tableau suivant :