Notes de mise à jour du correctif VMware Integrated OpenStack 2.0.1

VMware Integrated OpenStack 2.0.1 | 10 décembre 2015 | Build 3302254

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

À propos de VMware Integrated OpenStack

VMware Integrated OpenStack simplifie grandement le déploiement d'une infrastructure cloud OpenStack en rationalisant le processus d'intégration. VMware Integrated OpenStack offre une fonctionnalité OpenStack prête à l'emploi et un workflow de configuration simple via un vApp gestionnaire de déploiement qui s'exécute directement dans vCenter.

Langues prises en charge

VMware Integrated OpenStack version 2.0.x est disponible en anglais et dans six autres langues : chinois simplifié, chinois traditionnel, japonais, coréen, français et allemand. Vous devez utiliser les caractères ASCII pour toutes les entrées et les conventions d'attribution de nom des ressources OpenStack (noms de projet, noms d'utilisateur, noms d'image, etc.) et pour les composants d'infrastructure sous-jacents (noms d'hôte ESXi, noms de groupe de ports vSwitch, noms de centre de données, noms de banque de données, etc.).

Mise à jour Nouvelles fonctionnalités de cette version

VMware Integrated OpenStack facilite le déploiement rapide d'OpenStack sur une plate-forme virtuelle VMware vSphere. Cette version fournit les nouvelles fonctionnalités et améliorations suivantes.

  • Prise en charge de plusieurs contrôleurs de domaine. Vous pouvez connecter votre déploiement à Active Directory avec plusieurs contrôleurs de domaine en modifiant le paramètre ldap_url dans le fichier custom.yml. Pour cela, répertoriez les URL de chaque contrôleur de domaine en les séparant par une virgule. Par exemple :

    ldap_url: ldaps://domain1.acme.com:636,ldaps://domain2.acme.com:636

    Vous devez ajouter et modifier le fichier custom.yml pour utiliser cette fonctionnalité. Reportez-vous à la section Personnalisation améliorée.

  • Nouvelle interface pour la mise à jour du serveur DNS. Les utilisateurs peuvent directement modifier le serveur DNS que le déploiement OpenStack utilise. Dans vSphere Web Client, cliquez sur l'icône VMware Integrated OpenStack dans la page Inventaires, puis sélectionnez Gérer > Réseaux. Sélectionnez le réseau cible, puis Toutes les actions > Modifier le DNS.

  • Migration de volumes Cinder. VMware Integrated OpenStack 2.0.1 prend en charge la migration des volumes Cinder, même lorsqu'ils sont associés à une instance Nova en cours d'exécution. Vous pouvez désormais supprimer les disques des machines virtuelles Cinder dans certaines banques de données. À la fin de cette procédure, vous pouvez migrer les machines virtuelles vers une autre banque de données. Une fois que le disque supprimé est dissocié d'OpenStack, il est automatiquement corrigé.

    1. Connectez-vous en tant qu'administrateur au gestionnaire VMware Integrated OpenStack.

    2. Passez à l'utilisateur racine.

      sudo su -

    3. Préparez une banque de données pour la maintenance.

      viocli ds-migrate-prep [-d DEPLOYMENT] DC_NAME DS_NAME

      • -d DEPLOYMENT : spécifie le nom du déploiement VMware Integrated OpenStack.

      • DC_NAME : spécifie le nom du centre de données.

      • DS_NAME : spécifie le nom de la banque de données.

    Vous pouvez activer le mode de maintenance de la banque de données ou migrer les volumes Cinder vers une autre banque de données.

  • Configuration étendue des paramètres du serveur Syslog. La configuration du serveur Syslog a été étendue afin d'inclure les paramètres de protocole et de port.

  • Prise en charge du pont L2 VXLAN/VLAN. Dans une infrastructure feuille/épine, le cluster de calcul OpenStack ne peut pas accéder aux machines virtuelles sur un VLAN. Pour contourner cette limitation, créez un réseau VXLAN et un pont L2 VXLAN/VLAN. Remarque : les procédures concernées sont détaillées dans la section Configuration de la prise en charge du pont L2 VXLAN/VLAN.

  • Les nœuds NSX-V Edge prennent désormais en charge la haute disponibilité. Vous pouvez configurer la haute disponibilité des services de mise en réseau provisionnés à partir du plug-in NSX-v Neutron. La haute disponibilité est désactivée par défaut sur les nœuds Edge. Vous devez ajouter et modifier le fichier custom.yml pour utiliser cette fonctionnalité. Reportez-vous à la section Personnalisation améliorée.

    Pour activer la haute disponibilité Edge avant l'installation de VMware Integrated OpenStack :

    1. Déployez le fichier OVA de VMware Integrated OpenStack sur vSphere, mais n'installez pas VMware Integrated OpenStack.

    2. Modifiez le fichier /opt/vmware/vio/custom/custom.yml en annulant la mise en commentaire de l'option nsxv_edge_ha, puis en la définissant sur True.

      nsxv_edge_ha: True

    3. Enregistrez le fichier.

    4. Installez VMware Integrated OpenStack sur vSphere.

    Pour activer la haute disponibilité Edge après l'installation de VMware Integrated OpenStack :

    1. Modifiez le fichier /opt/vmware/vio/custom/custom.yml en annulant la mise en commentaire du paramètre nsxv_edge_ha, puis en le définissant sur True.

      nsxv_edge_ha: True
      Le paramètre nsxv_edge_ha se trouve dans la section des options NSX-V du fichier custom.yml.

    2. Enregistrez le fichier.

    3. Dans le contrôleur VMware Integrated OpenStack, répertoriez tous les nœuds Edge en cours d'exécution et les valeurs de edge-id correspondantes.

      nsxadmin -r edges -o list

    4. Activez la haute disponibilité sur un nœud Edge. Pour cela, spécifiez la valeur de la propriété edge-id correspondante.

      nsxadmin -r edges -o nsx-update \
      --property highavailability=True \
      --property edge-id=<edge-id>

    5. Répétez l'étape précédente pour chaque nœud Edge.

    6. Transférez la nouvelle configuration vers le déploiement VMware Integrated OpenStack.

      viocli deployment -v configure

      IMPORTANT : cette commande met à jour la totalité du déploiement et peut entraîner de brèves interruptions des opérations.

  • Amélioration des services facultatifs de collecte de journaux. Ces services ont été ajoutés dans la version 1.0.3 et migrés vers la version 2.0.1.

    • Option de collecte des journaux non cumulés uniquement.

      viogetlogs -nrl

      ou

      viogetlogs --non-rollover-log-only

    • Option de collecte des journaux de services spécifiques.

      viogetlogs -svc [composant OpenStack tel que Nova, base de données ou autre]

      ou

      viogetlogs --service-only [composant OpenStack tel que Nova, base de données ou autre]

  • Balisage des journaux propre au déploiement. Les utilisateurs disposant de plusieurs déploiements VMware Integrated OpenStack peuvent personnaliser le balisage des journaux pour chaque déploiement. La balise définie est appliquée à tous les journaux du déploiement, ce qui permet aux utilisateurs de les différencier des journaux des autres déploiements. Vous devez ajouter et modifier le fichier custom.yml sur chaque déploiement pour utiliser cette fonctionnalité. Reportez-vous à la section Personnalisation améliorée.

    Pour configurer des balises personnalisées pour les journaux, répétez la procédure suivante sur chaque déploiement VMware Integrated OpenStack.

    1. Modifiez le fichier /opt/vmware/vio/custom/custom.yml afin d'y inclure le paramètre syslog_server_tag.

    2. Entrez une étiquette unique pour baliser tous les journaux du déploiement. Par exemple :

      syslog_server_tag: VIO_123
      Cette étiquette peut inclure une combinaison de caractères alphanumériques, de traits de soulignement (_) ou de points (.). Aucun espace n'est permis.

    3. Enregistrez le fichier.

    4. Transférez la nouvelle configuration vers le déploiement VMware Integrated OpenStack.

      viocli deployment configure -v --tags configure_rsyslog

  • La règle du groupe de sécurité a été étendue afin de spécifier le préfixe de l'adresse IP locale des règles d'entrée. La commande de CLI Neutron security-group-rule-create a été étendue afin de spécifier le paramètre --local-ip-prefix pour le trafic entrant.

  • Personnalisation améliorée. Plusieurs nouvelles fonctionnalités peuvent être configurées en implémentant et en modifiant le fichier custom.yml. Pour implémenter le fichier, connectez-vous au gestionnaire VMware Integrated OpenStack et copiez le modèle dans votre déploiement.

    sudo mkdir -p /opt/vmware/vio/custom
    sudo cp /var/lib/vio/ansible/custom/custom.yml.sample /opt/vmware/vio/custom/custom.yml

    L'implémentation du fichier n'affecte pas le déploiement, car tous les paramètres sont mis en commentaire par défaut.

    AVERTISSEMENT : la modification des paramètres dans le fichier custom.yml peut affecter votre déploiement. Modifiez les paramètres uniquement dans le cadre de procédures spécifiques ou si vous êtes conseillé par un ingénieur VMware.

  • Gestion basée sur des stratégies pour définir le stockage Nova par défaut. VMware Integrated OpenStack vous permet d'appliquer des paramètres de stratégie SPBM aux instances créées par OpenStack et de vérifier que les instances démarrées à partir d'un volume utilisent le type de volume approprié. Vous devez implémenter et modifier le fichier custom.yml pour utiliser cette fonctionnalité. Reportez-vous à la section Personnalisation améliorée.

    Pour définir le stockage Nova par défaut pour les instances VMware Integrated OpenStack :

    1. Si vous ne l'avez pas déjà fait, implémentez le fichier custom.yml

      sudo mkdir -p /opt/vmware/vio/custom
      sudo cp /var/lib/vio/ansible/custom/custom.yml.sample /opt/vmware/vio/custom/custom.yml

    2. Modifiez le fichier /opt/vmware/vio/custom/custom.yml afin d'annuler la mise en commentaire des options PBM.

      ##############################
      # Options PBM 
      ##############################
      
      # (chaîne) Stratégie PBM par défaut à utiliser lorsqu'aucune stratégie n'est associée à un type (obligatoire) si nova_pbm_enabled est défini sur True.
      nova_pbm_default_policy: nova
      
      # (booléen) État de PBM. Définissez cette valeur sur True pour activer les stratégies de stockage pour les types Nova.
      nova_pbm_enabled : False
      

    3. Définissez le paramètre nova_pbm_enabled sur True.

           nova_pbm_enabled : True

    4. Enregistrez le fichier custom.yml.

    5. Pour appliquer cette stratégie à un type, modifiez la configuration correspondante en ajoutant les spécifications suivantes à ses métadonnées.

      vmware:storage_policy=nova 

      Lorsqu'une instance est créée à l'aide de cette configuration, la stratégie de stockage est appliquée.

Compatibilité

La Matrice d'interopérabilité des produits VMware fournit des détails sur la compatibilité de la version en cours de VMware Integrated OpenStack avec les composants VMware vSphere, dont ESXi, VMware vCenter Server, vSphere Web Client et les produits VMware facultatifs. Pour plus d'informations sur les agents de gestion et de sauvegarde pris en charge, consultez également la Matrice d'interopérabilité des produits VMware avant d'installer VMware Integrated OpenStack ou d'autres produits VMware.

Composants en libre accès pour VMware Integrated OpenStack 2.0

Les déclarations de copyright et les licences applicables aux composants logiciels en libre accès distribués dans VMware Integrated OpenStack 2.0.1 sont accessibles sous l'onglet Open Source de la page de téléchargement du produit. Vous pouvez également télécharger les fichiers source pour une licence GPL, LGPL ou d'autres licences semblables pour lesquelles le code source ou les modifications du code source doivent être accessibles pour la dernière version disponible de VMware Integrated OpenStack.

Mise à niveau de la version 2.0 vers la version 2.0.1

Pour effectuer la mise à niveau de la version 2.0 vers la version 2.0.1, installez le correctif 2.0.1 (2.0.1, build 3309787) sur la version 2.0.

Pour effectuer les procédures suivantes, vous devez avoir installé la version 2.0. Le correctif met à jour l'interface utilisateur du produit et doit par conséquent être installé à l'aide des instructions relatives à l'interface de ligne de commande documentées ci-dessous.

  1. Récupérez le correctif (build 2.0.1.3309787).

    • Connectez-vous au serveur de gestion VMware Integrated OpenStack.

    • Téléchargez le fichier Debian pour le correctif.

    • Ajoutez le correctif à l'aide de la commande suivante :

      viopatch add -l [chemin vers le fichier debian]

      REMARQUE : un bogue Adobe existant peut empêcher le téléchargement du fichier lors de l'utilisation de Firefox. Pour plus d'informations, reportez-vous à la section Problème de téléchargement du fichier de correctif dans le navigateur Firefox.

    • Vérifiez que le correctif a été correctement ajouté :

      viopatch list

      Cette commande renvoie une liste des correctifs disponibles, leur numéro de version, leur type et leur état actuel.

  2. Installez le correctif.

    • Assurez-vous que le service VMware Integrated OpenStack est en cours d'exécution ou pas encore déployé.

      Si le service VMware Integrated OpenStack se trouve dans un autre état, la mise à niveau va échouer.

    • Connectez-vous au serveur de gestion VMware Integrated OpenStack et exécutez la commande suivante :

      viopatch install --patch vio-patch-x --version 2.0.1.3309787

      La durée de l'installation du correctif peut atteindre 10 minutes.

      REMARQUE : lors de l'installation du correctif, le point de terminaison de l'API est automatiquement désactivé. Par conséquent, tous les appels d'API au cours de l'installation renverront une erreur 503.

  3. Pour terminer la mise à jour, déconnectez-vous de vSphere Web Client, puis reconnectez-vous.

    Vous pouvez ignorer les messages d'erreur que vous obtenez lors de la reconnexion.

  4. Le cas échéant, vous pouvez restaurer une version de correctif antérieure en désinstallant le correctif.

    • Connectez-vous au serveur de gestion VMware Integrated OpenStack et exécutez la commande suivante :

      viopatch uninstall -p vio-patch-201 -v 2.0.1.3309787

      Le processus de restauration a une durée comprise entre 5 et 10 minutes.

    • Une fois que le correctif est désinstallé, redémarrez le service vSphere Web Client sur vCenter Server pour rétrograder le plug-in VMware Integrated OpenStack.

      Pour en savoir plus sur le redémarrage des services vCenter Server Appliance, consultez l'article VMware KB 2054085.

Mise à niveau de la version 1.0.x vers la version 2.0.1

Pour procéder à la mise à niveau de la version 1.0.x vers la version 2.0.1, effectuez la procédure directement dans le gestionnaire VMware Integrated OpenStack. vSphere devant tenir compte du déploiement existant et des fichiers de mise à niveau, le processus de mise à niveau vous oblige à doubler de manière temporaire les ressources de la banque de données.

REMARQUE : pour en savoir plus sur la procédure générale de mise à niveau, reportez-vous au Guide de l'administrateur de VMware Integrated OpenStack.

Conditions requises

  • Doublez les ressources de la banque de données dédiées à votre déploiement VMware Integrated OpenStack actuel.
  • Vérifiez que vous avez doublé le nombre requis d'adresses IP disponibles.
  • Par mesure de sécurité, sauvegardez votre déploiement actuel. Pour plus de détails, reportez-vous au Guide de l'administrateur de VMware Integrated OpenStack.
  • Conservez la configuration de votre déploiement actuel VMware Integrated OpenStack en l'exportant comme modèle.

Pour procéder à la mise à niveau vers VMware Integrated OpenStack 2.0.1 :

  1. Dans le gestionnaire VMware OpenStack, ajoutez des plages d'adresses IP aux réseaux de gestion et d'API. Le nombre d'adresses IP que vous ajoutez doit correspondre au nombre d'adresses configurées pour le réseau existant. Reportez-vous à la rubrique Ajout d'adresses IP à la configuration réseau du Guide de l'administrateur de VMware Integrated OpenStack.

  2. Récupérez et installez le correctif Debian pour la mise à niveau. Reportez-vous à la rubrique Installer le correctif de mise à niveau vers VMware Integrated OpenStack 2.0 du Guide de l'administrateur de VMware Integrated OpenStack.

  3. Dans vSphere Web Client, sélectionnez Accueil > Inventaires, puis cliquez sur l'icône VMware Integrated OpenStack.

  4. Cliquez sur l'onglet Gérer, puis sur l'onglet Mises à jour.

  5. Cliquez sur l’onglet Mises à niveau.

    Cet onglet spécifie le déploiement VMware Integrated OpenStack actuel.

  6. Cliquez avec le bouton droit sur le nom du déploiement et sélectionnez Mise à niveau dans le menu déroulant.

  7. Entrez le nom du nouveau déploiement, puis cliquez sur Suivant.

    Pour les clients disposant de plusieurs déploiements, ce nom est utilisé pour baliser les journaux afin de faciliter leur identification.

  8. Configurez les paramètres VIP public et privé du service d'équilibrage de charge.

    • Adresse IP virtuelle publique Cette valeur doit être sur le même sous-réseau que le réseau d'accès aux API OpenStack et ne doit pas être comprise dans la plage d'adresses IP spécifiée pour le réseau d'accès aux API OpenStack.

    • Adresse IP virtuelle privée Cette adresse IP se connecte à l'interface de l'équilibrage de charge avec le réseau de gestion.

  9. Cliquez sur Suivant.

  10. Vérifiez la configuration proposée, puis cliquez sur Terminer.

  11. Dans l'onglet Mises à niveau, cliquez avec le bouton droit sur le nom du déploiement 1.0.x et sélectionnez Migrer les données.

    Une fois la migration terminée, le statut du déploiement 2.0 dans l'onglet Mises à niveau passe à Migré.

  12. Dans l'onglet Mises à niveau, cliquez avec le bouton droit sur le nom du déploiement 1.0.x et sélectionnez Basculer vers le nouveau déploiement.

    Une fois le basculement vers le déploiement terminé, le statut du déploiement 2.0 dans l'onglet Mises à niveau passe à En cours d'exécution. Le déploiement de la version 1.0.x affiche un statut Arrêté.

  13. Vous pouvez vous connecter au gestionnaire VMware Integrated OpenStack pour migrer les personnalisations du déploiement 1.0.3 vers le nouveau déploiement 2.0.1.

    vioconfig configure
    
    REMARQUE : cette étape s'applique uniquement si vous avez modifié le fichier custom.yml dans la version 1.0.3.

Configuration de la prise en charge du pont L2 VXLAN/VLAN

Dans une infrastructure feuille/épine, le cluster de calcul OpenStack ne peut pas accéder aux machines virtuelles sur un VLAN. Pour contourner cette limitation, créez un réseau VXLAN et un pont L2 VXLAN/VLAN. Remarque : le groupe de ports VDS pour le réseau VXLAN doit être créé avant d'effectuer la configuration.

  1. Connectez-vous en tant qu'administrateur au nœud du contrôleur OpenStack via une connexion SSH.
  2. Créez la passerelle logique L2 sur Neutron.
    neutron-l2gw l2-gateway-create <gateway-name> \
    --device name=<device-name1>,interface_names="<interface-name1>[|<seg-id1>]"
    • <gateway-name> : spécifie le nom de la nouvelle passerelle.

    • <device-name1> : spécifie le nom du périphérique. Ce nom est factice. Le plug-in NSX-V crée un DLR dédié.

    • <interface-name1> : spécifie l'ID MOB du groupe de ports distribué comme nom d'interface.

    • <seg-id1> : spécifie l'ID de segmentation du groupe de ports distribué.

    À partir du pool Edge de sauvegarde, NSX-V crée le DLR dédié L2 bridging-{gateway-id} et transmet l'ID Edge à l'opération suivante.

  3. Créez la connexion de passerelle logique L2 sur Neutron.
    neutron-l2gw l2-gateway-connection-create <gateway-name/uuid> <network-name/uuid> \
    [--default-segmentation-id=<seg-id>]
    • <gateway-name/uuid> : spécifie le nom de la passerelle existante.

    • <network-name/uuid> : spécifie le nom du réseau. Ce nom est factice. Le plug-in NSX-V crée un DLR dédié.

    • default-segmentation-id=<seg-id1> : spécifie l'ID de segmentation du groupe de ports distribué par défaut.

    Cette opération connecte le réseau OpenStack au réseau VLAN du fournisseur.

Mise à jour Problèmes connus

Les problèmes suivants ont été identifiés dans VMware Integrated OpenStack 2.0.1. Si vous rencontrez un problème qui n'apparaît pas dans cette liste des problèmes connus, faites une recherche dans la Base de connaissances VMware ou contactez l'assistance technique de VMware.

  • Mise à jour La fonction de restauration échoue suite à l'échec d'une mise à niveau.
    Ce problème a été constaté lors de la mise à niveau de la version 1.0.3 vers la version 2.0.1. En cas d'échec du processus de mise à niveau, il est possible que vous ne parveniez pas à restaurer la version antérieure. OpenStack renvoie le message suivant : « Lost connection to MySQL server at \'reading initial communication packet\', system error: 0 "Internal error/check (Not system error)" ».

    Solution : restaurez manuellement la version antérieure avant de recommencer la mise à niveau :

    1. Dans le panneau Gérer > Mises à niveau, supprimez la nouvelle version.

    2. Désinstallez le correctif.

    3. Redémarrez manuellement le déploiement existant.

    4. Utilisez SSH pour accéder à l'interface de ligne de commande du gestionnaire OpenStack, puis exécutez la commande vioconfig configure.

    Une fois l'ancien déploiement restauré, vous pouvez recommencer le processus de mise à niveau.

  • Problèmes de connectivité réseau
    Si des échecs se produisent lors de la connexion ou de la reconnexion de machines virtuelles à un commutateur logique, NSX-V peut en être la cause. Il s'agit d'un problème connu qui se manifeste après la mise à niveau ou la repréparation des hôtes ESXi dans NSX-V.

    Solution : reportez-vous à l'article VMware KB 2107951.

  • Impossible de modifier les paramètres syslog à la suite du déploiement dans l'interface de VIO Manager.
    Après le déploiement de VIO, vous ne pouvez pas modifier la configuration du serveur syslog à l'aide des paramètres de l'interface de VIO Manager (VMware Integrated OpenStack >Serveur de gestion > Modifier les paramètres > Options vApp).

    Solution : modifiez la configuration ici : VMware Integrated OpenStack > Cluster OpenStack > Gérer > LogInsight.

  • Le tableau de bord peut afficher un volume comme étant attaché, même si l'attachement a échoué.
    Il s'agit d'un problème connu sur OpenStack, qui a été signalé pour la première fois dans la version Icehouse.

  • De longs délais de téléchargement d'images peuvent générer un échec NotAuthenticated.
    Il s'agit d'un problème connu sur OpenStack (https://bugs.launchpad.net/glance/+bug/1371121), qui a été signalé pour la première fois dans la version Icehouse.

  • Le détachement d'un volume échoue avec une erreur FileNotFoundException.
    Lors du détachement d'un volume, le déplacement de la machine virtuelle fantôme échoue si Storage DRS (SDRS) a déplacé le disque virtuel. La procédure de dépannage suivante fonctionne uniquement si le volume ne contient pas de snapshots.

    Solution : la procédure suivante fonctionne uniquement si le volume ne contient pas de snapshots.

    1. Dans detach_volume, reconfigurez la machine virtuelle fantôme afin de supprimer son disque de machine virtuelle.

      REMARQUE : ne définissez pas l'option qui permet de supprimer les fichiers.

      Ceci supprimera le périphérique de disque même si les fichiers de sauvegarde n'existent pas et que la machine virtuelle est maintenant prête à être déplacée.

    2. Détruisez le disque de machine virtuelle du volume.

      REMARQUE : ignorez l'exception filenotfound. Ceci implique que SDRS a déplacé le disque de machine virtuelle au lieu de le copier ; du fait qu'il n'existe aucune référence au disque de machine virtuelle, vous devez le supprimer de manière explicite.

    3. Déplacez la machine virtuelle fantôme vers la banque de données de l'instance.

    4. Reconfigurez la machine virtuelle fantôme de façon à attacher la dernière copie du disque de machine virtuelle du volume.

    5. Reconfigurez l'instance de façon à supprimer le disque de machine virtuelle du volume.

  • L'extension d'un volume échoue si une machine virtuelle fantôme a une chaîne de disques.
    La fonctionnalité d'extension de volume n'est pas prise en charge lorsque le volume contient un ou plusieurs snapshots.

  • Le tableau de bord OpenStack ne reflète pas immédiatement l'extension d'un volume.
    Si vous augmentez la taille d'un volume, le tableau de bord peut continuer d'afficher la taille précédant l'extension. La taille correcte s'affiche finalement.

  • Le composant Nova est bloqué, puis devient inaccessible et expire.
    Lorsque Nova est bloqué pendant un long moment, la file d'attente des messages principaux devient inaccessible sous la référence « NovaServers.boot_and_delete_servers ».

    Solution : redémarrez nova-conductor sur les deux nœuds de contrôleur, puis redémarrez nova-compute sur le nœud de calcul.

  • Le service de gestion OpenStack ne redémarre pas après un événement vSphere HA.
    Si vSphere connaît un événement HA (par exemple, l'hôte ESXi qui héberge le serveur de gestion OpenStack), lorsque vSphere HA redémarre, le service de gestion OpenStack n'est pas redémarré. Ce problème a été constaté dans vCenter Server 5.5.

    Solution : si un événement vSphere HA affecte le déploiement OpenStack, assurez-vous que le service de gestion OpenStack a redémarré. Redémarrez manuellement si nécessaire.

  • L'échec du nœud de base de données peut bloquer l'accès au tableau de bord pendant 30 minutes.
    Si le nœud principal de base de données échoue et redémarre, il est possible que les utilisateurs ne puissent pas se connecter au tableau de bord VMware Integrated OpenStack (Horizon) pendant 30 minutes. Ce problème a été constaté dans vCenter Server 5.5.

  • Le programme d'installation donne la priorité au stockage local par défaut.
    Lors du provisionnement des banques de données des trois machines virtuelles de base de données, le programme d'installation de VMware Integrated OpenStack donne automatiquement la priorité au stockage local pour améliorer les performances d'E/S. Pour davantage de résilience, les utilisateurs peuvent préférer le stockage partagé, mais le programme d'installation n'explique pas clairement comment modifier ce paramètre.

    Solution : avant de terminer la procédure d'installation, le programme d'installation de VMware Integrated OpenStack vous permet de revoir et de modifier la configuration. Vous pouvez en profiter pour modifier la configuration de la banque de données des trois machines virtuelles de base de données.

  • Le service image Glance ne prend pas en charge les caractères spéciaux dans les noms de banques de données.
    Si le nom d'une banque de données contient des caractères non alphanumériques comme les deux points, l'esperluette ou la virgule, la banque de données ne peut pas être ajoutée au service Glance. Les caractères suivants en particulier ne sont pas autorisés dans les noms de banques de données Glance du fait qu'ils sont réservés à d'autres usages et peuvent donc interférer avec la configuration : : , / $ (deux points, virgule, barre oblique, symbole de dollar). Ce problème a fait l'objet d'une procédure de résolution rapide.

  • Le démarrage de Nova en créant un nouveau volume sur OVF échoue.
    Le format OVF n'est pas pris en charge.

    Solution : convertissez le format OVF en OVA en utilisant l'outil VMware approprié ou utilisez un autre format pris en charge.

  • Le tableau de bord VMware Integrated OpenStack (Horizon) génère l'erreur 504 d'expiration de délai de la passerelle.
    Après avoir configuré environ 1 500 réseaux, cliquer sur Réseaux dans le panneau de navigation du tableau de bord peut générer l'erreur 504.

  • Si une machine virtuelle de contrôleur redémarre, la haute disponibilité peut être compromise.
    Lorsqu'un contrôleur échoue, l'autre contrôleur continue de fournir des services. Cependant, lorsque le contrôleur initial redémarre, il peut ne plus fournir de services et donc être indisponible si l'autre contrôleur échoue également. Ce problème a fait l'objet d'une procédure de résolution rapide.

    Solution : si un contrôleur échoue et que HA est appelé, examinez votre déploiement pour vous assurer que les deux contrôleurs fournissent des services après le redémarrage du contrôleur ayant échoué.

  • Les noms de centres de données vSphere contenant des virgules empêchent le déploiement.
    Si le nom du centre de données VMware vSphere contient une virgule (par exemple : « Palo Alto, CA »), vous ne pourrez pas déployer VMware Integrated OpenStack. L'assistant de déploiement affiche une erreur de paramètre non valide.

    Solution : si possible, modifiez les noms des centres de données à utiliser pour les déploiements de VMware Integrated OpenStack afin d'omettre le caractère « , ».

  • La commande de démarrage vioconfig doit être exécutée si le nœud OpenStack est redémarré
    Si certains nœuds de machines virtuelles d'un cluster sont redémarrés, vous devrez peut-être redémarrer les autres nœuds également. Vous pouvez redémarrer chaque nœud individuellement dans vSphere Web Client ou en exécutant la commande sudo vioconfig start. Si vous ne pouvez redémarrer aucun nœud, assurez-vous que le gestionnaire VMware Integrated OpenStack fonctionne. Redémarrez le gestionnaire en premier, puis exécutez la commande sudo vioconfig start pour vérifier que tous les nœuds OpenStack démarrent également.

  • L'« image de démarrage Nova » échoue de manière intermittente.
    Si l'adresse IP du gestionnaire OpenStack est modifiée (par exemple, en modifiant le paramètre du nom de domaine complet), les machines virtuelles OpenStack ne sont plus synchronisées sur le service de gestion OpenStack. Ce bogue fait l'objet d'une procédure de résolution rapide.

    Solution : modifiez manuellement l'adresse IP du gestionnaire OpenStack.

    1. À partir de l'interface vSphere Web, sélectionnez Prise en main de VMware Integrated OpenStack vApp->Modifier les paramètres...->Propriétés gestion réseau.

    2. Remplacez l'adresse IP du réseau de serveur de gestion par la nouvelle adresse.

    3. Mettez hors tension, puis redémarrez VMware Integrated OpenStack vApp.

    4. À l'aide de SSH, connectez-vous à la console du serveur de gestion.

    5. Accédez au fichier /etc/network/interfaces et remplacez le paramètre d'adresse IP par le nouveau.

    6. Redémarrez les machines virtuelles OpenStack.

  • Impossible d'atteindre le nœud à l'aide de SSH.
    Un nœud peut être inaccessible de l'extérieur via SSH, même s'il est accessible via SSH depuis le serveur de gestion VIO. Ce problème a été identifié en raison de fluctuations du réseau en dehors de la portée de vSphere et de VMware Integrated OpenStack.

    Solution : vous pouvez découvrir la cause spécifique de ce problème en activant le débogage pour le service jarvis.

    1. Connectez-vous au serveur de gestion et modifiez le fichier /etc/jarvis/jarvis.conf en remplaçant la ligne « verbose=False » par « verbose=True ».

    2. Modifiez le fichier /etc/jarvis/jarvis.conf en remplaçant la ligne « verbose=False » par « verbose=True ».

    3. Enregistrez et fermez le fichier.

    4. Redémarrez jarvis : sudo service jarvis restart.

    5. Exécutez de nouveau le déploiement.

      REMARQUE : la sortie de la journalisation détaillée sera rapidement affichée dans le journal ansible. Réinitialisez sur False après avoir débogué ce problème.

  • Le service de métadonnées n'est pas accessible sur les sous-réseaux créés avec l'option no-gateway.
    Dans la version 2.0, la configuration automatique est désactivée pour les machines virtuelles Edge. Le cas échéant, DHCP définit la passerelle et les métadonnées sont traitées via cette passerelle Edge. Par conséquent, lorsqu'un sous-réseau est créé avec l'option no-gateway, aucun routeur Edge ne capture le trafic de métadonnées.

    Solution : pour les réseaux avec l'option no-gateway, configurez un itinéraire sur 169.254.169.254/32 pour acheminer le trafic vers l'adresse IP de DHCP Edge.

  • Échec de récupération de plusieurs machines virtuelles OpenStack.
    Après avoir récupéré plusieurs machines virtuelles, un nœud rabbitMQ ne récupère pas et entraîne l'échec de config-mq.

    Solution : récupérez l'intégralité du niveau des machines virtuelles.

    viocli recover -v -r RabbitMQ -n VIO-Controller-0 VIO-ComputeDriver-0 VIO-Memcache-1 VIO-LoadBalancer-1 VIO-DB-0

  • Post-mise à niveau : dupliquer des caches d'images
    Lorsque vous mettez à niveau VMware Integrated OpenStack 1.0 vers la version 2.0, les caches d'images existants sont dupliqués. Les caches d'images 1.0 sont requis pour prendre en charge l'ensemble des instances créées dans la version 1.0 ; les instances créées dans la version 2.0 utilisent le nouveau cache d'image.

    Solution : ne supprimez pas les caches d'images 1.0 si vous avez encore des instances créées dans la version 1.0, sinon les instances échoueront. Lorsque vous n'avez plus d'instance 1.0, vous pouvez supprimer les caches d'images 1.0.

  • Le tableau de bord Horizon affiche une erreur après avoir changé de projet en tant qu'utilisateur admin.
    Si vous êtes connecté à Horizon en tant qu'utilisateur administratif et que vous tentez de basculer d'un projet à un autre à l'aide du menu déroulant dans Horizon, le tableau de bord peut renvoyer des erreurs. Ceci provient d'un problème dans OpenStack.

    Solution : déconnectez-vous du tableau de bord Horizon, puis reconnectez-vous pour restaurer le tableau de bord.

  • Problèmes avec le modèle heat lors de la création de ScalingPolicy.
    Les modèles Ceilometer Heat ne peuvent pas créer ScalingPolicy en tant que membre locataire, uniquement en tant qu'administrateur de locataire. Il s'agit d'un problème d'autorisation. Ce problème fait l'objet d'une procédure de résolution rapide.

    Solution : si vous n'utilisez pas LDAP dans votre déploiement, vous pouvez corriger ce problème en modifiant manuellement la configuration de Keystone pour donner à l'utilisateur et au locataire des privilèges de propriétaire.

    keystone user-role-add --user USER_NAME --tenant TENANT_NAME --role heat_stack_owner

    Remarque : vous devez redémarrer le modèle VMware Integrated OpenStack pour appliquer les nouveaux paramètres.

  • WaitConditionHandle ne fonctionne pas avec la configuration heat.conf actuelle.
    L'utilisation de OS::Heat::WaitConditionHandle dans un modèle Heat Orchestration Template (HOT) peut générer l'erreur suivante :

    Échec de création de ressource : Erreur : Resources.Mysql.Resources.Wait Handle: Impossible d'obtenir le jeton utilisateur du domaine de pile, aucun ID de domaine de pile configuré, veuillez corriger votre Heat.Conf

    Ce problème a fait l'objet d'une procédure de résolution rapide.

  • La mise à niveau vers la version 2.0 échoue avec l'erreur « Aucun hôte ESXi qualifié pour le contrôleur 1 ».
    Les procédures d'installation du correctif et de mise à niveau remplacent les personnalisations apportées au fichier omjs.properties, ce qui entraîne cette erreur.

    Solution : appliquez de nouveau vos paramètres personnalisés au fichier omjs.properties de la version 2.0, puis redémarrez le gestionnaire VMware Integrated OpenStack.

  • Le passage de la version 2.0 à la version 1.0.x génère une alerte d'erreur.
    Si vous rétablissez une version 1.0.x, VMware Integrated OpenStack peut afficher une alerte d'erreur d'authentification.

    Solution : fermez l'alerte et le gestionnaire VMware Integrated OpenStack, puis redémarrez le service vSphere Web Client. Lorsque vous redémarrez le gestionnaire VMware Integrated OpenStack, le service VMware Integrated OpenStack redémarrera sans l'erreur.

  • Le téléchargement de snapshots échoue en raison d'une erreur d'expiration de délai.
    Le téléchargement de snapshots échoue en raison de l'expiration du délai de lecture HTTP dans vCenter.

    Solution : vous pouvez éviter cette erreur en modifiant le paramètre readTimeoutMs du fichier vpxd.cfg.

    1. Par mesure de sécurité, faites une copie de sauvegarde du fichier vpxd.cfg.

    2. Réglez le paramètre readTimeoutMs sur 600000.

      <config>
        <vmacore>
          <http>
            <readTimeoutMs>600000</readTimeoutMs>
          </http>
        </vmacore>
      ..
      </config>
      
    3. Arrêtez et redémarrez vCenter.

  • Problème lors du téléchargement du fichier de correctif dans le navigateur Firefox.
    Si vous utilisez Firefox pour mettre à jour le correctif pour VMware Integrated OpenStack, un échec du téléchargement se produit si Firefox utilise la version 19 du plug-in Adobe Flash. Selon la base de bogues d'Adobe, (https://bugbase.adobe.com/index.cfm?event=bug&id=4037494), ce problème affecte uniquement le navigateur Firefox et certaines versions ultérieures de Chrome.

    Solution : vous pouvez contourner ce problème en utilisant un autre navigateur ou en restaurant le plug-in Flash du navigateur à une version antérieure (15, 16, 17 ou 18).

  • Après l'enregistrement du vApp, l'icône VMware Integrated OpenStack ne s'affiche toujours pas.
    Seul un utilisateur disposant des droits d'administration peut enregistrer le vApp VMware Integrated OpenStack. Toutefois, si un utilisateur ne disposant pas des droits d'administration tente d'enregistrer le vApp, aucune alerte n'est envoyée lorsque l'enregistrement échoue et VMware Integrated OpenStack ne s'affiche pas dans le panneau d'inventaire.

    Solution : réenregistrez le vApp à l'aide d'informations d'identification d'administrateur.

  • La commande sudo viocli deployment getlogs renvoie uniquement les journaux OMS et ignore les journaux de nœud OpenStack.
    Lorsque vous exécutez cette commande, aucun journal des nœuds OpenStack n'est renvoyé. Ce problème a été observé dans les déploiements dont le nom par défaut a été modifié au cours de l'installation. Toute autre valeur que VIO aboutit à cette erreur.

    Solution :

    1. Effectuez l'installation avec le nom de déploiement personnalisé.

    2. Connectez-vous au gestionnaire VMware Integrated OpenStack.

    3. Modifiez le fichier /opt/vmware/vio/etc/viocli.conf en définissant le paramètre

      deployment=VIO
      
      sur la même valeur que celle que vous avez affectée lors de l'installation. Par exemple :
      deployment=valeur_affectée_lors_de_l'installation
      

Problèmes résolus

  • Échec du déploiement avec l'erreur Impossible d'interroger l'adresse IP.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.1.

  • Statut de membre non mis à jour régulièrement, uniquement lors de la lecture des statistiques de pools.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.1.

  • La récupération de plusieurs machines virtuelles échoue et renvoie l'erreur WSREP.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.1.

  • L'API Glance ne fonctionne pas après une récupération de plusieurs machines virtuelles.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.1.

  • La mise à niveau de VMware Integrated OpenStack 1.0.3 vers la version 2.0 échoue.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.1.

  • Aucune interface n'est disponible pour définir la gestion du stockage Nova basée sur la stratégie.
    La gestion basée sur des stratégies pour le stockage Nova est maintenant configurée dans le fichier custom.conf. Reportez-vous à la rubrique Nouvelles fonctionnalités de cette version.