Plusieurs articles parlent de ce sujet dans la blogosphère, comme ici, mais le produit évoluant rapidement, chaque version a ses propres vérités. Ainsi, pour mettre en œuvre cette automatisation dans la version 3.4.1 du produit OVM (Oracle VM), il a fallu quelques adaptations et un peu de sueur… Voici de quoi éviter quelques pertes de temps.

 
 
Le point de départ est la mise en place d’une architecture de virtualisation sous Oracle VM en utilisant la dernière version du produit (3.4.1).
 
 
Une fois que tout est prêt, c’est à dire :

• OVM Manager installé
• Premier serveur physique découvert
• Vision de vos volumes SAN dans OVM à travers ce serveur
• Premier Pool de serveur créé (Serveur Pool repository associé – LUN de 30Go)
• Premier repositoy créé et associé au Pool de serveurs (Lund de 500 Go).
• Template de VM importé avec le fichier .ova (section Assembly et non Template)
• Bonding créés
• VLAN créés
• Réseaux créés

… ce qui nécessite déjà une bonne compréhension de votre architecture et quelques heures de travail, il reste à déployer une ou plusieurs VM, le but ultime de l’opération.
La création peut se faire à partir d’un template (téléchargé depuis le site edelivery.oracle.com et importé dans le repository en tant qu’appliance), on associe un réseau à la VM (par exemple le réseau DEV – dédié aux machines de développement) et on démarre cette VM.
Si toutes les étapes précédentes se déroulent assez facilement, la dernière consistant en la configuration initiale après le premier boot peut se révéler agaçante.
Pourquoi :
Après le démarrage, il faut ouvrir la console de la VM depuis l’interface OVM manager :

Ceci se fait au travers d’un plugin JAVA pour lequel votre navigateur n’est peut être pas correctement configuré (version, sécurité), ce qui fait que vous bataillez dans la configuration et le téléchargement de la bonne version et qu’une fois tous ces points résolus, la console s’ouvre enfin et une fois la séquence de démarrage système terminée entre dans les shells de configuration qui vont vous demander d’entrer le nom du serveur, son domaine, l’adresse IP de l’interface configuré, …
Bien sûr, vous avez déjà réuni tous ces éléments et la difficulté n’est pas la, le problème est ailleurs :
Tout d’abord, la console n’est pas mappée avec votre clavier français mais avec un qwerty américain de base, c’est donc une sacré gymnastique pour entrer vos données surtout si comme moi vous faites une erreur tous les 5 caractères et que vous utilisez régulièrement la touche « Delete » ou le « Backspace » ! Courage ici avec l’utilisation de « \ » sans effacement à l’écran des caractères pour la correction de votre saisie.

Ensuite, impossible d’envisager cette méthode pour déployer et configurer rapidement vos multiples VM.
L’automatisation de cette partie est donc primordiale, voici comment vous pouvez faire quelque chose d’opérationnel :

1) Installation des guests Tools dans une VM qui vous servira ensuite de modèle pour les autres

• Démarrer une VM depuis le template initial
• Configurer Yum pour qu’il puisse accéder au site public (utiliser un proxy si votre VM n’accède pas directement à internet)
• Télécharger et installer les rpms suivant :

  # yum install libovmapi xenstoreprovider ovmd python-simplejson

• Suite à l’installation, le processus « ovmd » doit être en cours d’exécution, procéder à sa réinitialisation :

# ovmd -s cleanup

• Positionner le drapeau de lancement de la configuration au futur démarrage de la VM :
  Modifier la valeur de INITIAL_CONFIG=no vers « yes » dans le fichier /etc/sysconfig/ovm-template-initial-config
• Arrêter la VM et créer votre template à partir de celle-ci (vous pourriez à ce moment faire d’autres éléments de personnalisation, comme ajouter un autre logiciel, créer des arborescences, …)

# shutdown -h now

2) Configurer le démon SSH utiliser par OVM manager ligne de commande (OVMCLI) pour se passer de mot de passe à la connexion

Référence note MOS 2163220.1

• Création de clé ssh public/privé pour l’utilisateur « admin » :

# ssh-keygen -t rsa -f ~/.ssh/admin

• Mise en place de la clé publique dans le répertoire home du compte oracle et ajout de la clé au fichier d’autorisation :

# cp ~/.ssh/admin.pub /home/oracle/.ssh/
# cd /home/oracle/.ssh/
# cat admin.pub >> ovmcli_authorized_keys

• Démarrage du démon ssh avec ce mode d’authentification :
  Mise en place du mode dans le fichier profile du compte root.
  Ajout dans le fichier .profile des lignes suivantes :

SSH_ENV="$HOME/.ssh/environment"
function start_agent {
echo "Initialising new SSH agent..."
/usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
echo succeeded
chmod 600 "${SSH_ENV}"
. "${SSH_ENV}" > /dev/null
/usr/bin/ssh-add ~/.ssh/admin;
}
# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
 . "${SSH_ENV}" > /dev/null
ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
  start_agent;
  }
else
  start_agent;
fi

• Sourcer le fichier profile et se connecter une première fois pour valider l’échange des clés :

# ssh -l admin localhost -p 10000

• Répondre « Yes » au prompt de la demande

3) Créer un fichier modèle qui contiendra toutes les informations pour configurer une de vos VM

• Variables à minima positionnées dans un fichier texte :

# OVM user
ovmUser=admin
# OVM Host
adminServer=localhost
# The virtual machine name that should be allocated to a virtual machine.
VMname=JCP_vm1.0
# The hostname name
hostName=
interface1=eth0
ipAddr=
NetMask=< masque du réseau pour votre VM>
GateWay=< adresse IP de votre passerelle >
Dns1=
VmPassword=

• Positionner ce fichier sous la distribution à l’endroit où se trouve le fichier common.sh : dans notre cas, il est nommé FirstBoot-VM.properties

4) Créer, dans le même répertoire, le shell qui va réaliser la configuration en envoyant les clés/valeurs au processus OVMD de la VM en attente de configuration.

Le script utilise la fonction présente dans common.sh
Voici celui que nous avons utilisé et qui fonctionne :

#######################################################
# The script uses the key-based authentication (i.e. no expect, no passwords in script)
. FirstBoot-VM.properties
. common.sh
showInfo "A script that configure VM at first Boot \n"
#################### Credential info  ##################
#getPass ovmServerPassword
#################### Execute Command passed in ##################
echo "## Starting Configure VM... ##"
echo "## 1.  Hostname"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.hostname  message='$hostName' log=no"
echo "## 2.  Interface eth0"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.device.0  message='$interface1' log=no"
echo "## 3.  Ifcfg-eth0"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.onboot.0  message='yes' log=no"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.bootproto.0  message='static' log=no"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.ipaddr.0  message='$ipAddr' log=no"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.netmask.0  message='$NetMask' log=no"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.gateway.0  message='$GateWay' log=no"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.network.dns-servers.0  message='$Dns1' log=no"
echo "## 4.  Finalisation"
validateCLI "sendVmMessage vm name='$VMname' key=com.oracle.linux.root-password  message='$VmPassword' log=no"
echo "Script executed successfully."

A noter que la configuration effective ne se déroule qu’après l’envoi du mot de passe, c’est cela le déclencheur.
Si vous avez des doutes sur le nom des clés (comme nous avons eu pour la mise au point), démarrer le modèle (configurer le avec la console !), connecter vous et faites la commande suivante :

# ovm-template-config --human-readable --enumerate configure

5) Démarrer votre VM en la créant à partir de votre template précédent (par l’interface graphique OVM Manager)

6) Depuis le serveur OVM Manager, se connecter en tant que root, exécuter le script

Votre VM est configurée vous pouvez l’accéder par ssh sur le réseau et l’adresse définie.
Les outils « guests tools » permettent de réaliser une configuration plus complète et personnalisée selon vos besoin, reportez-vous à la documentation pour cela.
La construction du fichier FirstBoot-VM.properties peut se faire à partir de saisie graphique ou autre pour de l’industrialisation.
On peut se poser la question du pourquoi pas plus d’intégration dans le produit ? Peut être pour vous pousser à utiliser EM13C qui possède, lui, tous les assistants pour réaliser graphiquement ou automatiquement la configuration, mais ça c’est une autre histoire…
Hope that helps !