Travailler avec des modèles

Un modèle est une configuration réutilisable pour les machines virtuelles. Quand les utilisateurs lancent des VMs, ils peuvent choisir un modèle depuis une liste dans CloudStack.

Plus spécifiquement, un modèle est une image d’un disque virtuel qui inclue un des nombreux systèmes d’exploitations, des logiciels additionnels optionnels comme des applications de bureautique, et des configurations comme les contrôles d’accès pour déterminer qui peut utiliser le modèle. Chaque modèle est associé à un type d’hyperviseur particulier, qui est spécifié lorsque le modèle est ajouté à CloudStack.

CloudStack est livré avec un modèle par défaut. Dans le but de fournir plus de choix aux utilisateurs, les administrateurs CloudStack et les utilisateurs peuvent créer des modèles et les ajouter à CloudStack.

Créer des modèles : vue d’ensemble

CloudStack est livré avec un modèle par défaut pour le système d’exploitation CentOS. Il y a de nombreuses façon d’ajouter plus de modèles. Les administrateurs et les utilisateurs finaux peuvent ajouter des modèles. La suite typique des évènements est :

  1. Lancer une instance de VM du système d’exploitation que vous voulez. Faire tout changement de configuration désiré à la VM.

  2. Arrêter la VM.

  3. Convertir le volume en modèle.

Il y a d’autres façons d’ajouter des modèles à CloudStack. Par exemple, vous pouvez prendre un instantané du volume de la VM et créer un modèle depuis l’instantané, ou importer un VHD depuis un autre système dans CloudStack.

Les techniques variées pour créer des modèles sont décries dans les quelques sections suivantes.

Conditions requises pour les modèles

  • Pour XenServer, installer les drivers PV / outils Xen sur chaque modèle que vous créez. Ceci va activer la migration à chaud et l’arrêt propre des invités.

  • Pour vSphere, installer les outils VMware sur chaque modèle que vous créez. Cela va permettre à la vue Console de fonctionner correctement.

Meilleurs pratiques pour les modèles

Si vous planifiez d’utiliser des modèles conséquents (100 GB ou plus), assurez vous d’avoir un réseau 10Gbts pour supporter des modèles conséquents. Un réseau plus lent peut entraîner des dépassements de délais et autres erreurs lorsque des modèles plus gros sont utilisés.

Le modèle par défaut

CloudStack inclue un modèle CentOS. Le modèle est téléchargé par la VM de Stockage Secondaire après que le stockage primaire et secondaire aient étés configurés. Vous pouvez utiliser ce modèle dans votre déploiement de production ou vous pouvez le supprimer et utiliser des modèles personnalisés.

Le mot de passe root du modèle par défaut est “password”.

Un modèle par défaut est fourni pour XenServer, KVM et vSphere. Les modèles qui sont téléchargés dépendent du type d’hyperviseur qui est disponible dans votre cloud. Chaque modèle fait une taille d’approximativement 2.5 GB.

Le modèle par défaut inclue les règles standard iptables lesquelles vont bloquer la plupart des accès au modèle en excluant ssh.

# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere        anywhere       icmp any
ACCEPT     esp  --  anywhere        anywhere
ACCEPT     ah   --  anywhere        anywhere
ACCEPT     udp  --  anywhere        224.0.0.251    udp dpt:mdns
ACCEPT     udp  --  anywhere        anywhere       udp dpt:ipp
ACCEPT     tcp  --  anywhere        anywhere       tcp dpt:ipp
ACCEPT     all  --  anywhere        anywhere       state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere        anywhere       state NEW tcp dpt:ssh
REJECT     all  --  anywhere        anywhere       reject-with icmp-host-

Modèles privés et publics

Lorsqu’un utilisateur crée un modèle, il peut être désigné comme privé ou public.

Les modèles privés ne sont disponibles qu’à l’utilisateur qui l’a créé. Par défaut, un modèle téléchargé est privé.

Quand un utilisateur marque un modèle comme “public”, le modèle devient disponible aussi bien pour tous les utilisateurs de tous les comptes du domaine de l’utilisateur que pour les utilisateurs de tous les autres domaines qui ont accès à la Zone dans laquelle le modèle est stocké. Tout dépend si la Zone, à son tour, a été définie comme privée ou public. Une Zone privée est assignée à un seul domaine et une Zone publique est accessible par n’importe quel domaine. Si un modèle public est créé dans une Zone privée, il n’est disponible qu’aux seuls utilisateurs du domaine assigné à cette Zone. Si un modèle public est créé dans une Zone publique, il est disponible à tous les utilisateurs de tous les domaines.

Créer un modèle depuis une machine virtuelle existante

Une fois que vous avez au moins une VM de configurée de la façon que vous voulez, vous pouvez l’utiliser comme prototype pour les autres VMs.

  1. Créer et démarrer une machine virtuelle en utilisant n’importe quelle technique donnée dans “Créer des VMs”.

  2. Faire toutes les changements de configuration désirés sur la VM en cours de fonctionnement, puis cliquer sur Stop.

  3. Attendre l’arrêt de la VM. Quand le statut affiche Stoppée, aller à l’étape suivante.

  4. Aller dans “Voir volumes” et sélectionner le Volume ayant le type “ROOT”.

  5. Cliquer sur Créer un modèle et fournir les informations suivantes :

    • ** Nom et texte affiché**. Ceux-ci seront affichés dans l’interface, alors choisir quelque chose de descriptif.

    • Type d’OS. Ceci aide CloudStack et l’hyperviseur à effectuer certaines opérations et à faire des choix qui améliorent les performances de l’invité. Sélectionner une des options.

      • Si le système d’exploitation de la VM arrêtée est listé, le choisir.

      • Si le type d’OS de la VM stoppée n’est pas listé, choisir Autres.

      • Si vous voulez démarrer depuis ce modèle dans le mode PV, choisir Autre PV (32-bit) ou Autre PV (64-bit). Ce choix n’est disponible que pour XenServer :

        Note

        Généralement vous ne devriez pas choisir une version plus ancienne de l’OS que la version de l’image. Par exemple, choisir Cent0S 5.4 pour supporter une image CentOS 6.2 ne va pas en général fonctionner. Dans ces cas vous devriez choisir Autres.

    • Public. Choisir Oui pour rendre le modèle accessible à tous les utilisateurs de cette installation de CloudStack. Le modèle va apparaître dans la liste Modèles Communautaires. Voir “Modèles privés et publics”.

    • Mot de passe activé. Choisir Oui si votre modèle a le script CloudStack de changement de mot de passe d’installé. Voir Ajouter un mot de passe de gestion à votre modèle.

  6. Cliquer sur Ajouter.

Le nouveau modèle sera visible dans la section Modèles lorsque le processus de création du modèle sera terminé. Le modèle est alors disponible lorss de la création d’une nouvelle VM.

Créer un modèle depuis un instantanné

Si vous ne voulez pas stopper la VM pour créer l’entrée de menu Créer un modèle (comme décris dans “Créer un modèle depuis une machine virtuelle existante”), vous pouvez créer un modèle directement depuis n’importe quel instantané depuis l’interface CloudStack.

Télécharger des modèles

Modèles vSphere et ISOs

Si vous téléchargez un modèle qui a été créé en utilisant un client vSphere, assurez vous que le fichier OVA ne contienne pas d’ISO. Si c’est le cas, le déploiement de VMs depuis le modèle ne fonctionnera pas.

Les modèles sont téléchargés par une URL. HTTP est le protocole d’accès supporté. Les modèles sont souvent de gros fichiers. Vous pouvez optionnellement les gzipper pour réduire les temps de téléchargement.

Pour télécharger un modèle :

  1. Dans la barre de navigation de gauche, cliquer sur Modèles.

  2. Cliquer sur Enregistrer un modèle.

  3. Fournir les informations suivantes :

    • Nom et Description. Ceux-ci seront affichés dans l’interface, alors choisir quelque chose de descriptif.

    • URL. Le serveur de gestion va télécharger le fichier depuis l’URL spécifiée, comme par exemple : http://my.web.server/filename.vhd.gz.

    • Zone. Choisir la zone dans laquelle vous aller rendre le modèle disponible, ou Toutes les Zones pour le rendre disponible dans tout CloudStack.

    • Type d’OS. Ceci aide CloudStack et l’hyperviseur à effectuer certaines opérations et à faire des choix qui améliorent les performances de l’invité. Sélectionner une des options :

      • Si le système d’exploitation de la VM arrêtée est listé, le choisir.

      • Si le type d’OS de la VM stoppée n’est pas listé, choisir Autres.

        Note

        Vous ne devriez pas choisir une version plus ancienne de l’OS que la version de l’image. Par exemple, choisir Cent0S 5.4 pour supporter une image CentOS 6.2 ne va pas en général fonctionner. Dans ces cas vous devriez choisir Autres.

    • Hypervisor : Les hyperviseurs supportés sont listés. Choisir celui désiré.

    • Format. Le format du fichier du modèle téléchargé, comme par exemple VHD ou OVA.

    • Mot de passe activé. Choisir Oui si votre modèle a le script CloudStack de changement de mot de passe d’installé. Voir Ajouter un mot de passe de gestion à votre modèle.

    • Extractible. Choisir Oui si le modèle est disponible pour l’extraction. Si cette option est sélectionnée, les utilisateurs finaux peuvent télécharger une image complète du modèle.

    • Public. Choisir Oui pour rendre le modèle accessible à tous les utilisateurs de cette installation de CloudStack. Le modèle va apparaître dans la liste Modèles Communautaires. Voir “Modèles privés et publics”.

    • Subventionné.Choisir Oui si vous voulez que votre modèle soit mis plus en évidence lors de la sélection par l’utilisateur. Le modèle va apparaître dans la liste des modèles subventionnés. Seul un administrateur peut faire un modèle subventionné.

Exporter des modèles

Les utilisateurs finaux et les administrateurs peuvent exporter des modèles depuis CloudStack. Naviguer jusqu’au modèle dans l’interface et choisir la fonction Télécharger depuis le menu Actions.

Créer un modèle Linux

Les modèles Linux devraient être préparé en utilisant cette documentation dans le but de préparer vos VMs linux pour le déploiement de modèle. Pour les besoins de la documentation, la VM que vous être en train de configurer pour faire office de modèle sera référencer comme “Template Master”. Ce guide pour le moment ne couvre que les configurations n’utilisant pas les UserData et cloud-init et présume qu’un serveur openssh est installé durant l’installation.

Une vue d’ensemble de la procédure est :

  1. Télécharger votre ISO Linux

    Pour plus d’informations, voir “Ajouter une ISO”.

  2. Créer une instance de VM avec cet ISO.

    Pour plus d’informations, voir “Créer des VMs”.

  3. Préparer la VM Linux

  4. Créer un modèle depuis la VM.

    Pour plus d’informations, voir “Créer un modèle depuis une machine virtuelle existante”.

Préparation du système pour Linux

Les étapes suivantes vont préparer une installation Linux basique pour devenir un modèle.

  1. Installation

    C’est une bonne pratique de nommer votre VM avec quelque chose de générique durant l’installation, ce qui va assurer que des composants comme LVM n’apparaisse pas unique à une machine. Il est recommandé que le nom “localhost” soit utilisé pour l’installation.

    Avertissement

    Pour CentOS, il est nécessaire de supprimer l’identifiant unique du fichier de configuration, pour cela éditer le fichier /etc/sysconfig/network-scripts/ifcfg-eth0 et changer le contenu pour celui-ci.

    DEVICE=eth0
    TYPE=Ethernet
    BOOTPROTO=dhcp
    ONBOOT=yes
    

    Les étapes suivantes mettent à jour les paquets sur le modèle maître.

    • Ubuntu

      sudo -i
      apt-get update
      apt-get upgrade -y
      apt-get install -y acpid ntp
      reboot
      
    • CentOS

      ifup eth0
      yum update -y
      reboot
      
  2. Gestion du mot de passe

    Note

    De préférence, les utilisateurs personnalisés (comme comme ceux créés durant l’installation d’Ubuntu) doivent être retirés. D’abord s’assurer que compte de l’utilisateur root est activé en lui donnant un mot de passe et ensuite se connecter en root pour continuer.

    sudo passwd root
    logout
    

    En tant que root, supprimer tous les comptes utilisateurs personnalisés créés durant le processus d’installation.

    deluser myuser --remove-home
    

    Voir Ajouter un mot de passe de gestion à votre modèle pour les instructions pour configurer le script de gestion du mot de passe, qui permettra à CloudStack de changer le mot de passe root depuis l’interface web.

  3. Gestion du nom de machine

    CentOS configure le nom d’hôte par défaut au démarrage. Malheureusement, Ubuntu n’a pas cette fonctionnalité, pour les installations d’Ubuntu utiliser les étapes suivantes :

    • Ubuntu

      Le nom d’hôte d’une VM déployée depuis un modèle est fixé par un script personnalisé dans /etc/dhcp/dhclient-exit-hooks.d, ce script vérifie d’abord si la valeur courante est localhost, si c’est le cas, il va obtenir le nom d’hôte, le nom de domaine et l’adresse IP fixe depuis le fichier de bail DHCP et utiliser ces valeurs pour fixer le nom d’hôte et l’ajouter le fichier /etc/hosts pour la résolution locale du nom d’hôte. Une fois que ce script, ou un utilisateur, a changé le nom d’hôte, il ne va plus ajuster les fichiers systèmes en relation avec son nouveau nom d’hôte. Le script recrée également les clefs du serveur SSH, qui ont été supprimées juste avant la transformation en modèle (voir ci-dessous). Sauvegarder le script suivant sous /etc/dhcp/dhclient-exit-hooks.d/sethostname, et ajuster les permissions.

      #!/bin/sh
      # dhclient change hostname script for Ubuntu
      oldhostname=$(hostname -s)
      if [ $oldhostname = 'localhost' ]
      then
          sleep 10 # Wait for configuration to be written to disk
          hostname=$(cat /var/lib/dhcp/dhclient.eth0.leases  |  awk ' /host-name/ { host = $3 }  END { printf host } ' | sed     's/[";]//g' )
          fqdn="$hostname.$(cat /var/lib/dhcp/dhclient.eth0.leases  |  awk ' /domain-name/ { domain = $3 }  END { printf     domain } ' | sed 's/[";]//g')"
          ip=$(cat /var/lib/dhcp/dhclient.eth0.leases  |  awk ' /fixed-address/ { lease = $2 }  END { printf lease } ' | sed     's/[";]//g')
          echo "cloudstack-hostname: Hostname _localhost_ detected. Changing hostname and adding hosts."
          printf " Hostname: $hostname\n FQDN: $fqdn\n IP: $ip"
          # Update /etc/hosts
          awk -v i="$ip" -v f="$fqdn" -v h="$hostname" "/^127/{x=1} !/^127/ && x { x=0; print i,f,h; } { print $0; }" /etc/hosts > /etc/hosts.dhcp.tmp
          mv /etc/hosts /etc/hosts.dhcp.bak
          mv /etc/hosts.dhcp.tmp /etc/hosts
          # Rename Host
          echo $hostname > /etc/hostname
          hostname -b -F /etc/hostname
          echo $hostname > /proc/sys/kernel/hostname
          # Recreate SSH2
          export DEBIAN_FRONTEND=noninteractive
          dpkg-reconfigure openssh-server
      fi
      ### End of Script ###
      
      chmod 774  /etc/dhcp/dhclient-exit-hooks.d/sethostname
      

    Avertissement

    Les étapes suivantes devraient être lancée lorsque vous être prêt à transformer votre Modèle Maître en modèle. Si le Modèle Maître est redémarré durant ces étapes vous devrez relancer toutes les étapes à nouveau. A la fin de ce processus, le Modèle Maître devrait être arrêté et le modèle créé pour créer et déployer le modèle final.

  4. Supprimer les règles udev des périphériques persistants

    Cet étape retire les informations unique de votre Modèle Maître comme les adresses réseaux MAC, les fichiers de baux et les périphériques de type bloc comme les CD. Les fichiers sont générés automatiquement au démarrage suivant;

    • Ubuntu

      rm -f /etc/udev/rules.d/70*
      rm -f /var/lib/dhcp/dhclient.*
      
    • CentOS

      rm -f /etc/udev/rules.d/70*
      rm -f /var/lib/dhclient/*
      
  5. Supprimer les clefs SSH

    Cet étape s’assure que toutes vos VMs issuent de modèles n’aient pas les mêmes clefs SSH, ce qui réduirait la sécurité de vos machines dramatiquement.

    rm -f /etc/ssh/*key*
    
  6. Nettoyer les fichiers de logs

    C’est une bonne habitude de supprimer les vieux fichiers de logs du Modèle Maître.

    cat /dev/null > /var/log/audit/audit.log 2>/dev/null
    cat /dev/null > /var/log/wtmp 2>/dev/null
    logrotate -f /etc/logrotate.conf 2>/dev/null
    rm -f /var/log/*-* /var/log/*.gz 2>/dev/null
    
  7. Configurer le nom d’hôte

    Pour que le script DHCP pour Ubuntu fonctionne et que le client dhclient de CentOS puisse fixer le nom d’hôte ils nécessitent tous les deux que le nom d’hôte du Modèle Maître soit “localhost”. Lancer les commandes suivantes pour changer le nom d’hôte.

    hostname localhost
    echo "localhost" > /etc/hostname
    
  8. Forcer l’expiration du mot de passe utilisateur

    Cet étape force l’utilisateur à changer le mot de passe de la VM après que le modèle ait été déployé.

    passwd --expire root
    
  9. Nettoyer l’historique utilisateur

    L’étape suivante retire les commandes bash que vous venez de lancer.

    history -c
    unset HISTFILE
    
  10. Éteindre la VM

    Vous êtes maintenant prêt pour éteindre votre Modèle Maître et créer un modèle !

    halt -p
    
  11. Créer le modèle !

    Vous êtes maintenant prêts à créer le modèle, pour plus d’informations voir “Créer un modèle depuis une machine virtuelle existante”.

Note

Les VMs provenant d’un modèle sous Ubuntu ou CentOS peuvent nécessiter un redémarrage après le provisionnement afin de changer le nom d’hôte.

Créer un modèle Windows

Les modèles Windows doivent être préparées avec Sysprep avant de pouvoir être provisionnés sur plusieurs machines. Sysprep vous permet de créer un modèle générique Windows et supprime toute possibilité de conflits de SID.

Note

(XenServer) Les VMs Windows fonctionnant sous XenServer nécessitent des drivers PV, qui peuvent être fourni dans le modèle ou ajouter après que la VM soit créée. Les drivers PV sont nécessaires pour les fonctions essentielles de gesion comme monter des volumes additionels et des images ISO, la migration à chaud, et l’arrêt correcte.

Une vue d’ensemble de la procédure est :

  1. Télécharger votre ISO Windows.

    Pour plus d’informations, voir “Ajouter une ISO”.

  2. Créer une instance de VM avec cet ISO.

    Pour plus d’informations, voir “Créer des VMs”.

  3. Suivre les étapes dans Sysprep pour Windows Server 2008 R2 (ci-dessous) ou Sysprep pour Windows Server 2003 R2, en fonction de votre version de Windows Server.

  4. Les étapes de préparations sont terminées. Vous pouvez maintenant créer un modèle comme décrit dans Créer un modèle Windows.

Préparation du système pour Windows Server 2008 R2

Pour Windows 2008 R2, vous lancer Windows System Image Manager pour créer un fichier XML de réponse sysprep personnalisé. Windows System Image Manager est installé comme partie du Windows Automated Installation Kit (AIK). Windows AIK peut être téléchargé depuis Microsoft Download Center.

Utiliser les étapes suivantes pour lancer sysprep pour Windows 2008 R2 :

Note

Les étapes décrites ici proviennent de l’excellent guide de Charity Shelbourne, publié à l’origine à Windows Server 2008 Sysprep Mini-Setup.

  1. Télécharger et installer Windows AIK

    Note

    Windows AIK ne devrait pas être installé sur la VM Windows 2008 R2 que vous venez de créer. Windows AIK ne devrait pas faire partie d’un modèle que vous créez. Il est juste utilisé pour créer le fichier de réponse sysprep.

  2. Copier le fichier install.wim du répertoire \sources du DVD d’installation Windows 2008 R2 sur le disque dur. C’est un très gros fichier et peut mettre du temps à se copier. Windows AIK nécessite que le fichier WIM soit en écriture.

  3. Démarrer le Windows System Image Manager, qui est une partie du Windows AIK.

  4. Dans le paneau Image Windows, clic-droit sur Sélectionner une image Windows ou sur option Fichier catalogue pour charger le fichier install.wim que vous venez de copier.

  5. Sélectionner Windows 2008 R2 Edition.

    Vous pouvez être avertit par une alerte que le fichier catalogue ne peut pas être ouvert. Cliquer sur Oui pour créer un nouveau fichier catalogue.

  6. Dans le paneau Fichier Réponse, cliquer droit pour créer un nouveau fichier de réponse.

  7. Générer un fichier de réponse depuis Windows System Image Manager en utilisant les étapes suivantes :

    1. La première page que vous devez automatiser est la page de Selection de Langage et de Pays ou de Région. Pour automatiser cela, développer les composants dans votre panneau Image Windows, clic-droit et ajouter le paramètre Microsoft-Windows-International-Core pour passer 7 oobeSystem. Dans votre panneau Fichier de réponse, configurer le InputLocale, SystemLocale, UILanguage et UserLocale avec les paramètres appropriés pour votre langue et pays ou région. Si vous avez une question à propos de n’importe quel paramètre, vous pouver faire un clic-droit sur le paramètre spécifique et sélectionner Aide. Cela va ouvrir le fichier d’aide CHM approprié avec plus d’informations, incluant des examples sur le paramètre que vous êtes en train d’essayer de configurer.

      System Image Manager

    2. Vous devez automatiser la page de Sélection des Termes de Licence Logiciel, aussi connue comme End-User Licence Agreement (EULA). Pour cela, étendre le composant Microsoft-Windows-Shell-Setup. Surligner le paramètre OOBE et ajouter le paramètre à la Pass 7 oobeSystem. Dans paramètres, fixer HideEULAPage à vrai.

      Depicts hiding the EULA page.

    3. Assurez vous que la clé de licence est correctement configurée. Si vous utilisez une clé MAK, vous pouvez juste saisir la clé MAK sur la VM Windows 2008 R2. Vous ne devez pas introduire la MAK dans le Windows System Image Manager. Si vous utilisez un hôte KMS pour l’activation vous ne devez pas saisir de clé de produit. Des détails sur l’activation en volume de Windows peuvent être trouvés ici http://technet.microsoft.com/en-us/library/bb892849.aspx

    4. Vous devez automatiser la page Modifier le mot de passe administrateur. Développez le composant Microsoft-Windows-Shell-Setup (s’il n’est pas encore développé), développez UserAccounts, cliquez avec le bouton droit sur AdministratorPassword et ajoutez le paramètre de configuration Pass 7 oobeSystem de votre fichier de réponses. Sous Paramètres, spécifiez un mot de passe après Valeur.

      Depicts changing the administrator password

      Vous devriez lire la documentation AIK et configurer beaucoup plus d’options pour pour convenir à votre déploiement Les étapes ci-dessus sont le minimum requis pour rendre fonctionnel la configuration sans assistance de Windows.

  8. Sauvegarder le fichier de réponse sous unattend.xml. Vous pouvez ignorer les messages d’alertes qui apparaissent dans la fenêtre de validation.

  9. Copier le fichier unattend.xml sous le dossier c:\windows\system32\sysprep de la machine virtuelle Windows 2008 R2.

  10. Une fois que vous avez placé le fichier unattend.xml dans le dossier c:\windows\system32\sysprep, vous lancer l’outil sysprep comme ci-dessous :

    cd c:\Windows\System32\sysprep
    sysprep.exe /oobe /generalize /shutdown
    

    La VM Windows 2008 R2 va s’éteindre automatiquement après que le sysprep soit terminé.

Préparation du système pour Windows Server 2003 R2

Les versions précédentes de Windows ont un outil sysprep différent. Suivre ces étapes pour Windows Server 2003 R2.

  1. Extrayez le contenu de \support\tools\deploy.cab du CD d’installation de Windows dans le répertoire appelé c:\sysprep dans la VM Windows 2003 R2.

  2. Lancer c:\sysprep\setupmgr.exe pour créer le fichier sysprep.inf.

    1. Sélectionner Créer un nouveau pour créer un nouveau fichier de réponses.

    2. Entrer “Sysprep setup” pour le type de Setup.

    3. Sélectionner la version et l’édition appropriée d’OS.

    4. Dans l’écran Agrément Licence, sélectionner “Oui automatisation complète de l’installation”.

    5. Fournir le nom et l’organisation.

    6. Laisser les paramètres d’affichage par défaut.

    7. Sélectionner la zone horaire appropriée.

    8. Fournir votre clef de produit.

    9. Sélectionner un mode de licence approprié pour votre déploiement

    10. Sélectionner “Générer automatiquement un nom d’ordinateur”.

    11. Saisissez un mot de passe par défaut pour l’administrateur. Si vous activez la fonctionnalité de réinitialisation de mot de passe, les utilisateurs n’utiliseront pas ce mot de passe. Ce mot de passe sera réinitialisé par le gestionnaire d’instance après les démarrage des invités.

    12. Laisser les Composants Réseaux à “Paramètres par défaut”.

    13. Sélectionner l’option “WORKGROUP”.

    14. Laisser les options Téléphonie par défaut.

    15. Sélectionner les paramètres Régionaux appropriés.

    16. Sélectionner les paramètres de langage approprié.

    17. Ne pas installer d’imprimantes.

    18. Ne pas spécifier “Lancer une fois les commandes”.

    19. Vous ne devez pas spécifier une chaîne d’identification.

    20. Sauvegarde le fichier de réponse sous c:\sysprep\sysprep.inf.

  3. Lancer la commande suivante pour syspreper l’image :

    c:\sysprep\sysprep.exe -reseal -mini -activated
    

    Après cette étape la machine va automatiquement s’arrêter

Importer des images de Machines Amazon

The following procedures describe how to import an Amazon Machine Image (AMI) into CloudStack when using the XenServer hypervisor.

Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.

You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.

Note

Lors du copier/coller d’une commande, soyez certain que la commande est collée sur une seule ligne avant de l’exécuter. Certains lecteur de document peuvent introduire un saut de ligne indésirable dans le texte copié.

Pour importer un AMI

  1. Configurer la boucle interne sur le fichier image :

    # mkdir -p /mnt/loop/centos62
    # mount -o loop  CentOS_6.2_x64 /mnt/loop/centos54
    
  2. Install the kernel-xen package into the image. This downloads the PV kernel and ramdisk to the image.

    # yum -c /mnt/loop/centos54/etc/yum.conf --installroot=/mnt/loop/centos62/ -y install kernel-xen
    
  3. Créer une entrée grub dans /boot/grub/grub.conf.

    # mkdir -p /mnt/loop/centos62/boot/grub
    # touch /mnt/loop/centos62/boot/grub/grub.conf
    # echo "" > /mnt/loop/centos62/boot/grub/grub.conf
    
  4. Déterminer le nom du kernel PV qui a été installé dans l’image.

    # cd /mnt/loop/centos62
    # ls lib/modules/
    2.6.16.33-xenU  2.6.16-xenU  2.6.18-164.15.1.el5xen  2.6.18-164.6.1.el5.centos.plus  2.6.18-xenU-ec2-v1.0  2.6.21.7-2.fc8xen  2.6.31-302-ec2
    # ls boot/initrd*
    boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
    # ls boot/vmlinuz*
    boot/vmlinuz-2.6.18-164.15.1.el5xen  boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus  boot/vmlinuz-2.6.18-xenU-ec2-v1.0  boot/vmlinuz-2.6.21-2952.fc8xen
    

    Xen kernels/ramdisk always end with “xen”. For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.

  5. Based on your findings, create an entry in the grub.conf file. Below is an example entry.

    default=0
    timeout=5
    hiddenmenu
    title CentOS (2.6.18-164.15.1.el5xen)
       root (hd0,0)
       kernel /boot/vmlinuz-2.6.18-164.15.1.el5xen ro root=/dev/xvda
       initrd /boot/initrd-2.6.18-164.15.1.el5xen.img
    
  6. Editer le fichier /etc/fstab, changer “sda1” par “svda” et changer “sdb” par “svdb”

    # cat etc/fstab
    /dev/xvda  /         ext3    defaults        1 1
    /dev/xvdb  /mnt      ext3    defaults        0 0
    none       /dev/pts  devpts  gid=5,mode=620  0 0
    none       /proc     proc    defaults        0 0
    none       /sys      sysfs   defaults        0 0
    
  7. Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:

    # grep xvc0 etc/inittab
    co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
    # grep xvc0 etc/securetty
    xvc0
    
  8. Ensure the ramdisk supports PV disk and PV network. Customize this for the kernel version you have determined above.

    # chroot /mnt/loop/centos54
    # cd /boot/
    # mv initrd-2.6.18-164.15.1.el5xen.img initrd-2.6.18-164.15.1.el5xen.img.bak
    # mkinitrd -f /boot/initrd-2.6.18-164.15.1.el5xen.img --with=xennet --preload=xenblk --omit-scsi-modules 2.6.18-164.15.1.el5xen
    
  9. Changer le mot de passe.

    # passwd
    Changing password for user root.
    New UNIX password:
    Retype new UNIX password:
    passwd: all authentication tokens updated successfully.
    
  10. Sortir du chroot.

    # exit
    
  11. Vérifier que /etc/ssh/sshd_config contienne les lignes autorisant la connexion SSH par mot de passe.

    # egrep "PermitRootLogin|PasswordAuthentication" /mnt/loop/centos54/etc/ssh/sshd_config
    PermitRootLogin yes
    PasswordAuthentication yes
    
  12. If you need the template to be enabled to reset passwords from the CloudStack UI or API, install the password change script into the image at this point. See Ajouter un mot de passe de gestion à votre modèle.

  13. Démonter et supprimer le montage en boucle interne.

    # umount /mnt/loop/centos54
    # losetup -d /dev/loop0
    
  14. Copy the image file to your XenServer host’s file-based storage repository. In the example below, the Xenserver is “xenhost”. This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.

    # scp CentOS_6.2_x64 xenhost:/var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799/
    
  15. Log in to the Xenserver and create a VDI the same size as the image.

    [root@xenhost ~]# cd /var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799
    [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]#  ls -lh CentOS_6.2_x64
    -rw-r--r-- 1 root root 10G Mar 16 16:49 CentOS_6.2_x64
    [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-create virtual-size=10GiB sr-uuid=a9c5b8c8-536b-a193-a6dc-51af3e5ff799 type=user name-label="Centos 6.2 x86_64"
    cad7317c-258b-4ef7-b207-cdf0283a7923
    
  16. Importer le fichier image dans le VDI. Cela peut prendre 10-20 minutes.

    [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-import filename=CentOS_6.2_x64 uuid=cad7317c-258b-4ef7-b207-cdf0283a7923
    
  17. Locate a the VHD file. This is the file with the VDI’s UUID as its name. Compress it and upload it to your web server.

    [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# bzip2 -c cad7317c-258b-4ef7-b207-cdf0283a7923.vhd > CentOS_6.2_x64.vhd.bz2
    [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# scp CentOS_6.2_x64.vhd.bz2 webserver:/var/www/html/templates/
    

Convertir une VM Hyper-V en modèle

To convert a Hyper-V VM to a XenServer-compatible CloudStack template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with CloudStack, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.

For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:

  1. From the linux_ic/drivers/dist directory, run make uninstall (where “linux_ic” is the path to the copied Hyper-V Integration Components files).
  2. Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
  3. Remove the “hdX=noprobe” entries from /boot/grub/menu.lst.
  4. Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID. You can get that information with the blkid command.

The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.

Option une :

  1. Importer le VHD en utilisant XenCenter. Dans XenCenter, aller à Outils>Outils d’Appliance Virtuelle>Importation d’image disque.

  2. Choose the VHD, then click Next.
  3. Name the VM, choose the NFS VHD SR under Storage, enable “Run Operating System Fixups” and choose the NFS ISO SR.
  4. Click Next, then Finish. A VM should be created.

Option deux :

  1. Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
  2. Choose the VHD, then click Next.
  3. Input the XenServer host info, then click Next.
  4. Name the VM, then click Next, then Convert. A VM should be created.

Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:

  1. Boot the VM, uninstall Hyper-V Integration Services, and reboot.
  2. Install XenServer Tools, then reboot.
  3. Prepare the VM as desired. For example, run sysprep on Windows VMs. See “Creating a Windows Template”.

Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.

  1. Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
  2. In CloudStack, create a new template using the following values:
    • URL. Give the URL for the VHD
    • OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
    • Hyperviseur. XenServer

    • Format. VHD

The template will be created, and you can create instances from it.

Ajouter un mot de passe de gestion à votre modèle

CloudStack fourni une fonctionnalité optionnelle de réinitialisation de mot de passe qui permet aux utilisateurs de fournir un mot de passe root ou admin temporaire ou de réinitialiser un mot de passe root ou admin existant depuis l’interface CloudStack.

Pour activer la fonctionnalité de Réinitialisation de Mot de passe, vous aurez besoin de télécharger un script additionnel pour patcher votre modèle. Lorsque plus tard vous téléchargerez votre modèle dans CloudStack, vous pourrez spécifier si la fonctionnalité de réinitailisation de mot de passe admin/root doit être activée pour ce modèle.

La fonctionnalité de mot de passe de gestion fonctionne toujours par réinitialisation du mot de passe du compte lors du démarrage de l’instance. Le script effectue un appel HTTP au routeur virtuel pour recupérer le mot de passe du compte qui doit être changé. Aussi longtemps que le routeur virtuel est accessible l’invité aura accès au mot de passe du compte qui doit être utilisé. Quand l’utilisateur demande une réinitialisation du mot de passe, le serveur de gestion génère et envoie un nouveau mot de passe au routeur virtuel pour ce compte. Ainsi un redémarrage de l’instance est nécessaire pour effectuer un changement de mot de passe.

Si le script n’est pas capable de contacter le routeur virtuel durant le démarrage de l’instance le mot de passe ne sera pas réinitialisé mais le démarrage va continuer normalement.

Installation d’un OS Linux

Utiliser les étapes suivantes pour commencer l’installation d’un OS Linux :

  1. Télécharger le fichier du script cloud-set-guest-password :

  2. Renommer le fichier :

    mv cloud-set-guest-password.in cloud-set-guest-password
    
  3. Copier ce fichier sous /etc/init.d.

    Sur certaines distributions Linux, copier le fichier sous /etc/rc.d/init.d.

  4. Lancer la commande suivante pour rendre le script exécutable :

    chmod +x /etc/init.d/cloud-set-guest-password
    
  5. En fonction de la distribution Linux, continuer avec l’étape appropriée.

    Sous Fedora, CentOS/RHEL et Debian, lancer :

    chkconfig --add cloud-set-guest-password
    

Installation d’un OS Windows

Télécharger l’installateur, CloudInstanceManager.msi depuis la page de Téléchargement et lancer l’installateur dans la VM windows nouvellement créée.

Supprimer des modèles

Des modèles peuvent être supprimés. En général, lorsqu’un modèle concerne plusieurs zones, seule la copie qui est selectionnée pour la suppression sera supprimée ; le même modèle dans les autres zones ne seront pas supprimés. Le modèle CentOS fourni est une exception à cela. Si le modèle CentOS fourni est supprimé, il sera supprimé de toutes les zones.

Quand un modèle est supprimé, les VMs instanciées depuis celui-ci continueront de fonctionner. Toutefois, les nouvelles VMs ne pourront plus être créées en se basant sur le modèle supprimé.