Notes de mise à jour de VMware Integrated OpenStack 2.5

VMware Integrated OpenStack 2.5 | 3 juin 2016 | Build 3955000

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.

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.

  • Possibilité de déployer les clusters de gestion et de calcul sur différents serveurs vCenter. VMware Integrated OpenStack 2.5 permet aux utilisateurs de déployer les clusters de gestion et de calcul sur différents serveurs vCenter. Cela permet d'optimiser les performances, l'évolutivité et la disponibilité, mais aussi d'effectuer un déploiement plus solide et fiable du produit. Consultez le document Guide d'installation et de configuration de VMware Integrated OpenStack.

  • Nouvelles conditions d'attribution de licences NSX. Dans VMware Integrated OpenStack 2.5, les déploiements basés sur NSX exigent la licence NSX Advanced ou Enterprise.

  • Architecture simplifiée. VMware Integrated OpenStack 2.5 dispose d'une architecture simplifiée qui réduit la quantité de ressources nécessaires et améliore les performances. Par exemple, des nœuds tels que memcache et RabbitMQ ont été incorporés aux nœuds de base de données et aux nœuds de contrôleur, respectivement. Consultez les diagrammes de systèmes du document Guide d'installation et de configuration de VMware Integrated OpenStack.

  • Prise en charge des modèles vSphere existants. VMware Integrated OpenStack 2.5 permet aux utilisateurs d'exploiter leurs modèles de vSphere existants en les ajoutant à leur déploiement d'OpenStack sous forme d'images Glance. Ces modèles peuvent ensuite être démarrés comme instances d'OpenStack ou utilisés pour créer des volumes Cinder démarrables. En outre, le snapshot Nova et les opérations cinder upload-to-image créeront des images Glance stockées sous forme de modèles vSphere. Consultez le document Guide d'administration de VMware Integrated OpenStack.

  • Prise en charge de LBaaS v2.0. VMware Integrated OpenStack 2.5 prend en charge OpenStack LBaaS v2.0. Après l'installation de VMware Integrated OpenStack 2.5 ou la mise à niveau du logiciel vers cette version, vous pouvez continuer avec LBaaS v1.0 ou migrer vers la version 2.0 à l'aide d'une procédure simple qui consiste à migrer également les entrées de base de données de votre équilibrage de charge de la version 1.0 à la version 2.0.

    REMARQUE : après la migration vers LBaaS v2.0, vous ne pouvez pas rétablir la version v1.0. Consultez le document Guide d'installation et de configuration de VMware Integrated OpenStack pour les nouvelles installations ou le document Guide d'administration de VMware Integrated OpenStack pour les déploiements mis à niveau.

  • Améliorations du service image. VMware Integrated OpenStack 2.5 inclut de nouvelles fonctionnalités qui améliorent les performances du service image d'OpenStack : temps de démarrage plus rapide pour la création de l'instance initiale, démarrage de l'instance plus fiable et amélioration de la fonctionnalité de snapshot, entre autres.

  • Amélioration de la fonctionnalité de dépannage. Les améliorations apportées aux commandes de l'interface de ligne de commande de VMware Integrated OpenStack permettent aux utilisateurs de localiser et de supprimer les machines virtuelles inactives, les fonctionnalités de journalisation améliorées avec sortie de débogage et rotation des journaux de fichiers ainsi que les rapports sur l'état du déploiement développés pour inclure des informations telles que les problèmes de synchronisation, les connexions rompues, les tailles et le nombre de connexions des clusters de bases de données, les processus manquants, etc. Consultez la section sur la référence des commandes de l'interface de ligne de commande dans le document Guide d'administration de VMware Integrated OpenStack.

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.

Mise à niveau vers VMware Integrated OpenStack 2.5

La procédure de mise à niveau s'exécute directement dans le gestionnaire VMware Integrated OpenStack. Pour en savoir plus sur les différentes étapes de la procédure complète, reportez-vous au document Guide de l'administrateur de VMware Integrated OpenStack.

Conditions requises

  • Vérifiez que vous disposez actuellement de la version 2.0 ou d'une version supérieure.

    REMARQUE : Vous ne pouvez pas effectuer la mise à niveau de la version 1.0.x vers la version 2.5 directement. Si vous disposez actuellement de la version 1.0.x, vous devez d'abord effectuer la mise à niveau vers la version 2.0 ou 2.0.x. Consultez le Centre de documentation de VMware Integrated OpenStack 2.0 pour accéder à l'ensemble des notes de mise à jour de la version 2.0.

  • Vérifiez que vous disposez de suffisamment d'espace disque disponible sur le serveur de gestion VMware Integrated OpenStack pour installer le module de mise à niveau.

    Vous avez besoin d'environ 2,75 Go d'espace disque disponible.

  • Augmentez le nombre des ressources de banques de données dédiées aux machines virtuelles sur le cluster de gestion dans votre déploiement actuel de VMware Integrated OpenStack.

    À chaque nœud doivent correspondre des ressources, à l'exception des nœuds memcache et RabbitMQ. Consultez les sections Configuration matérielle requise pour les déploiements de VDS ou Configuration matérielle requise pour les déploiements de NSX, en fonction de votre déploiement.

  • Vérifiez que le cluster de gestion comprend suffisamment d'adresses IP à la fois pour le déploiement existant et le nouveau déploiement.
  • Par mesure de sécurité, sauvegardez votre déploiement actuel.
  • Pour conserver la configuration actuelle de votre déploiement VMware Integrated OpenStack, exportez-le sous forme de fichier de configuration à partir du gestionnaire VMware Integrated OpenStack.

Pour mettre à niveau vers VMware Integrated OpenStack 2.5 :

  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.

  2. Obtenez et installez le correctif Debian de la mise à niveau (2.5 Build 3955000).

  3. Exécutez la commande viocli dbverify pour détecter dans la base de données VMware Integrated OpenStack des problèmes connus, tels que des clefs dupliquées ou manquantes, pouvant provoquer des problèmes pendant la procédure de mise à niveau.

    viocli dbverify [-d NAME]

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

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

  6. Cliquez sur l’onglet Mises à niveau.

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

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

  8. 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.

  9. 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.

  10. Cliquez sur Suivant.

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

  12. Dans l'onglet Mises à niveau, cliquez avec le bouton droit sur le nom du déploiement 2.0.x et choisissez Migrer les données.

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

  13. Dans l'onglet Mises à niveau, cliquez avec le bouton droit sur le nom du déploiement 2.0.x et choisissez Basculer vers le nouveau déploiement.

    Une fois le basculement vers le déploiement terminé, l'état du déploiement 2.5 dans l'onglet Mises à niveau passe à Exécution. Le déploiement 1.0.x affiche un statut Arrêté.

  14. Dans vSphere Web Client, mettez à niveau le point de terminaison OpenStack Keystone vers la nouvelle adresse IP virtuelle interne.

    Le paramètre du point de terminaison Keystone est situé dans Administration > OpenStack.

Composants open source de VMware Integrated OpenStack 2.5

Les déclarations de copyright et les licences applicables aux composants logiciels en libre accès distribués dans VMware Integrated OpenStack 2.5 sont accessibles dans 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.

Problèmes connus

Les problèmes suivants ont été identifiés dans VMware Integrated OpenStack 2.5. 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.

  • 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.

  • L'injection de l'itinéraire de l'hôte ne fonctionne pas dans VMware Integrated OpenStack 1.0.1
    Ce problème a fait l'objet d'une procédure de résolution rapide.

  • 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.

  • 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 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é.

  • 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.x, la configuration automatique des machines virtuelles Edge est désactivée. 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.

  • Impossible de créer des instances sur une banque de données Virtual SAN
    Les utilisateurs déclarent être incapables de lancer des instances sur leur banque de données Virtual SAN. Le tableau de bord OpenStack indique « Aucun hôte disponible trouvé ».

    Cause : dans les cas rapportés, ce problème survient, car les utilisateurs ont changé le nom du centre de données. Ce nom fait partie du localisateur utilisé lorsque des images sont ajoutées à une banque de données. Les images créées avant le changement de nom ne peuvent donc pas être localisées.

    Solution : rétablissez le nom du centre de données ou réimportez les images de sorte que leurs localisateurs soient précis.

  • Le tableau de bord Horizon affiche une erreur après le changement 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.

  • 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 ».
    Cette erreur survient car les paramètres personnalisés de l'utilisateur dans le fichier omjs.properties ne sont pas appliqués à la version 2.0 lors du processus de mise à niveau.

    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.

  • La mise à niveau de VMware Integrated OpenStack 1.0.2 vers la version 2.0 échoue.
    Il existe un cas rare pour lequel le processus de mise à niveau échoue avec une erreur de service. Cela est probablement dû à un problème de chargement de classe Tomcat ou Java.

    Solution : redémarrez le gestionnaire VMware Integrated OpenStack et réessayez. La procédure doit réussir.

  • 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 : récupérez le correctif à l'aide de l'interface de ligne de commande. Vous pouvez également contourner ce problème en utilisant un autre navigateur ou en restaurant le plug-in Flash du navigateur Firefox à une version antérieure (15, 16, 17 ou 18).

  • Le service de gestion OpenStack ne redémarre pas automatiquement
    Dans certains cas, le service de gestion OpenStack ne redémarre pas automatiquement. Par exemple, après un événement de basculement, tous les services OpenStack redémarrent correctement, mais le service de gestion reste inaccessible.

    Solution : redémarrez manuellement le vApp de VMware Integrated OpenStack dans vSphere Web Client. Cliquez avec le bouton droit sur l'icône de la page d'inventaire et choisissez Arrêter. Une fois tous les services arrêtés, mettez le vApp sous tension. Vérifiez les journaux du gestionnaire OpenStack pour confirmer que le redémarrage s'est déroulé correctement.

    Remarque : Le redémarrage interrompt les services. Ce problème fait l'objet d'une procédure de résolution rapide dans une version ultérieure de VMware Integrated OpenStack.

  • La valeur tenant_id vide utilisée lors de la création de la ressource LBaaS v2.0 n'est pas rejetée
    Lors de la création d'une nouvelle ressource LBaaS tel que le moniteur de santé, NSX LBaaS v2.0 accepte les valeurs tenant_id vides, mais OpenStack Neutron LBaaS les rejette. Il s'agit d'un conflit entre les versions Kilo et Mitaka d'OpenStack qui devrait être résolu lors de la migration de VMware Integrated OpenStack vers Mitaka dans une version ultérieure.

    Solution : aucune action de l'utilisateur n'est requise. Comme solution temporaire, VMware Integrated OpenStack accepte la nouvelle ressource LBaaS et applique la valeur de tenant_id du locataire qui crée la ressource.

    Remarque : NSX ne prend pas en charge plusieurs locataires attachés au même sous-réseau. Consultez la documentation du produit NSX.

  • L'opération de récupération renvoie l'erreur « Les nœuds existent déjà. »
    Dans certains cas, l'exécution de la commande viocli recovery - <DB name> échoue si l'opération Ansible est interrompue. Les nœuds de base de données sont alors conservés, ce qui provoque l'erreur.

    Solution : supprimez manuellement les nœuds et réexécutez la commande viocli recovery.

  • Migration vers LBaaS v2 : les moniteurs de santé non associés à un pool ne migrent pas
    Dans LBaaS v2, les moniteurs de santé doivent être spécifiés et attachés à un pool. Dans LBaaS v1, les moniteurs de santé peuvent être créés sans association de pools et associés à un pool dans une procédure distincte.

    Lors de la migration vers LBaaS v2, les moniteurs de santé non liés sont donc exclus.

    Solution : avant de migrer vers LBaaS v1, associez tous les moniteurs de santé à un pool pour assurer la réussite de la migration. Après l'installation de VMware Integrated OpenStack 2.5 ou la mise à niveau du logiciel vers cette version, le processus de migration est facultatif. Consultez le document Guide d'administration de VMware Integrated OpenStack.

  • La récupération du nœud de base de données échoue.
    Lors de la première tentative, il se produit parfois un échec du processus de récupération des nœuds de base de données ayant échoué.

    Solution : recommencez le processus de récupération.

  • Limitation du locataire NSX LBaaS v2.0
    Les équilibrages de charge NSX prennent en charge un seul locataire par sous-réseau. En temps normal, ce n'est pas un problème, car les locataires créent leurs propres équilibrages de charge. Si un utilisateur tente de créer un équilibrage de charge et de l'attacher à un sous-réseau, cet équilibrage, une fois créé, indiquera un état d'erreur.

    Solution : autorisez les locataires à créer leurs propres équilibrages de charge. Ne créez pas d'équilibrage de charge ou ne l'attachez pas à un sous-réseau existant.

  • VMware Integrated OpenStack 2.5 nécessite la version Kilo du client Python Heat
    Comme VMware Integrated OpenStack 2.5 est basé sur la version Kilo d'OpenStack, le composant Orchestration nécessite la version Kilo de python-heatclient. Consultez https://launchpad.net/python-heatclient/kilo pour accéder à la version requise.

  • Message d'erreur du tableau de bord : « Un réseau peut être attaché à un seul routeur distribué. »
    Observé dans les déploiements à l'aide de NSX v6.2.2. Cela est dû à l'envoi de demandes router-interface-add en double de la part d'Horizon.

    Solution : aucune action de l'utilisateur n'est requise. Dans tous les cas, l'interface est créée. Vous pouvez ignorer le message d'erreur.

  • Le changement de nom du routeur peut entraîner l'abandon des paquets
    Observé dans les déploiements à l'aide de NSX v6.2.2. Si vous changez le nom d'un routeur partagé lors de l'envoi d'une requête Ping à la machine virtuelle à partir d'une source externe, certains paquets de trafic entrant peuvent être perdus en raison d'une demande de mise à jour du serveur principal.

    REMARQUE : ce problème est résolu dans la version 3.0 de VMware Integrated OpenStack.

  • L'importation d'image entraîne une erreur « qemu-img convert ».
    Lors de l'importation d'une image Ubuntu ou d'une autre source dans Glance, vous devez spécifier le format de disque correspondant aux attributs de l'image source.

    Solution : recommencez la procédure d'importation d'image, en spécifiant le format de disque correct. Consultez la documentation du produit pour vous guider.

    REMARQUE : dans une version ultérieure de VMware Integrated OpenStack, l'interface sera modifiée afin de mieux guider l'utilisateur et éviter cette erreur lors du processus d'importation d'image.

  • La suppression de la pile Heat échoue avec l'erreur « Impossible de publier la configuration sur NSX Edge ».
    Observé dans les déploiements à l'aide de NSX v6.2.2. En cas de conditions de stress, la pile Heat ou l'API OpenStack peuvent échouer sur l'ordinateur principal.

    Solution : retentez l'opération qui a échoué.

    REMARQUE : ce problème fait l'objet d'une procédure de résolution rapide dans une version ultérieure de NSX.

  • L'ajout d'un sous-réseau renvoie un message d'erreur
    Lors de l'ajout d'une interface de sous-réseau à un réseau privé, vous recevez l'erreur suivante : « Échec de la demande : erreur interne du serveur lors du traitement de votre demande ». Cela indique que l'interface de sous-réseau signale un routeur dont le réseau de passerelle est un réseau externe qui ne dispose pas de sous-réseau.

    Solution : vous pouvez résoudre ce problème en ajoutant un sous-réseau à la configuration du réseau externe, puis en créant de nouveau le routeur qui utilise ce réseau comme passerelle. Reconfigurez le réseau privé avec l'interface de sous-réseau du routeur mis à jour.

    REMARQUE : ce problème fait l'objet d'une procédure de résolution rapide dans une version ultérieure de VMware Integrated OpenStack.

  • La commande « nova list » échoue lorsque le mot de passe est entré manuellement.
    Il s'agit d'un bogue OpenStack documenté en détail ici : https://bugs.launchpad.net/python-novaclient/+bug/1525378. Ce problème se produit lorsque la variable d’environnement OS_PASSWORD du client Nova n'est pas spécifiée.

    Solution : définissez la variable d’environnement OS_PASSWORD du client Nova.

  • L'importation du modèle échoue avec le message : « 400 - Demande incorrecte : 10.0.0.1 doit correspondre à vcenter-host.example.com »
    L'ajout d'un modèle de VM en tant qu'image Glance peut échouer si l'URI d'emplacement utilisé pour créer l'image se réfère à l'instance de vCenter Server en utilisant l'adresse IP, car VMware Integrated OpenStack nécessite le nom d'hôte.

    Solution : lors de la création de l'image, utilisez le nom d'hôte comme valeur d'URI d'emplacement.

  • Impossible de sélectionner la version avec une taille de disque racine de 0.

    Si vous créez une version en spécifiant root_disk=0, celle-ci peut apparaître comme étant désactivée lorsqu'un utilisateur essaye de la sélectionner lors de la création d'une instance dans le tableau de bord de VMware Integrated OpenStack (Horizon).

    Solution : créez l'instance à l'aide de l'interface de ligne de commande, ce qui vous permet de spécifier la version.

    REMARQUE : ce problème fait l'objet d'une procédure de résolution rapide dans une version ultérieure de VMware Integrated OpenStack.

  • La configuration AD/LDAP est valide, mais Keystone ne démarre pas
    Lors du processus d'installation, la configuration Active Directory/LDAP est valide, mais le service Keystone ne démarre pas lors du processus de déploiement. Ce problème se produit, car le nom commun du certificat ne correspond pas au nom d'hôte du serveur LDAP.

    Solution : avant d'installer et de déployer VMware Integrated OpenStack, vérifiez que le nom du certificat correspond au nom d'hôte du serveur LDAP.

    REMARQUE : Ce problème fait l'objet d'une procédure de résolution rapide dans une version ultérieure de VMware Integrated OpenStack.

  • L'ajout d'une interface de routeur échoue avec une erreur de vidage.

    L'ajout d'une opération d'interface de routeur sur un routeur distribué peut échouer en raison d'une condition de concurrence, avec le message d'erreur « Erreur de vidage : La nouvelle instance <xx>, avec la clé d'identité <yy>, entre en conflit avec l'instance persistante <zz> ».

    Solution : retentez l'opération qui a échoué.

    REMARQUE : ce problème fait l'objet d'une procédure de résolution rapide dans la prochaine version de VMware Integrated OpenStack.

  • Modèles Heat Kilo incompatibles avec LBaaS v2.0.

    VMware Integrated OpenStack est basé sur la version Kilo d'OpenStack et prend en charge éventuellement LBaaS v2.0. Toutefois, les modèles Heat ne sont pas compatibles avec LBaaS v2.0 pour les versions antérieures à la version Mitaka d'OpenStack.

    Solution : si vous utilisez un modèle Heat avec VMware Integrated OpenStack 2.5 qui nécessite des ressources LBaaS, n'effectuez pas la migration vers LBaaS v2.0. Consultez le document Guide d'administration de VMware Integrated OpenStack.

Problèmes résolus

  • 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.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • 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.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5. Nécessite NSX 6.2.3.

  • 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 ».

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

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

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • 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.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • 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 peut être 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.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • Échec du déploiement avec l'erreur Impossible d'interroger l'adresse IP.
    Cet échec se produit principalement dans les environnements lents et peut dans certains cas être associé au bogue Ubuntu 1326199. Ce problème fait l'objet d'une procédure de résolution rapide.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • É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.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • La récupération de plusieurs machines virtuelles échoue et renvoie l'erreur WSREP.
    La commande viocli recover -v -r RabbitMQ -n VIO-Controller-0 VIO-Memcache-0 VIO-LoadBalancer-0 VIO-DB-1 VIO-DB-2 échoue avec une erreur sur les nœuds de base de données. Ce problème a fait l'objet d'une procédure de résolution rapide.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • L'API Glance ne fonctionne pas après une récupération de plusieurs machines virtuelles.
    L'API Glance ne fonctionne pas après une récupération de plusieurs machines virtuelles et renvoie une erreur d'informations d'identification « Identité OpenStack non valide ».

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • La page Résumé affiche un numéro de version incorrect après la mise à niveau.
    Après la mise à niveau d'un correctif, la page Résumé du gestionnaire VMware Integrated OpenStack peut afficher l'ancien numéro de version.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.

  • Valeurs par défaut de la commande cinder backup-create dans NFS 4.1.
    Lors de la sauvegarde d'un stockage de bloc, par défaut, OpenStack prend en charge NFS 4.1. Par conséquent, l'exécution de la commande cinder backup-create échoue pour les clients qui utilisent NFS 3.x.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5. Les procédures de création de sauvegardes cinder ont été modifiées pour être compatibles avec les différentes versions de NFS. Consultez la section « Configurer le service de sauvegarde du stockage de bloc » du document Guide de l'administrateur de VMware Integrated OpenStack.

  • Règles de pare-feu manquantes dans l'inventaire NSX
    Les règles de pare-feu du groupe de sécurité locataire par défaut peuvent être manquantes dans l'inventaire NSX, ce qui provoque une perte de connectivité entre les instances.

    Ce problème a été résolu dans VMware Integrated OpenStack 2.5.