Notes de mise à jour du correctif VMware Integrated OpenStack 2.0.3

VMware Integrated OpenStack 2.0.3 | 4 avril 2016 | Build 3717954

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

Nouvelles fonctionnalités de cette version

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

  • Prise en charge de la virtualisation des E/S à racine unique (SR-IOV). SR-IOV est l'une des technologies clés permettant d'obtenir de bonnes performances pour les charges de travail NFV (Network Function Virtualization). Sur VMware Integrated OpenStack, les instances peuvent désormais être déployées avec des fonctions virtuelles pour la mise en réseau. Pour plus d'informations sur la configuration matérielle requise et l'interopérabilité de vSphere, consultez la documentation de vSphere.

  • Allocation de capacité pour plusieurs locataires. VMware Integrated OpenStack étend la fonctionnalité de pool de ressources à OpenStack, ce qui permet aux administrateurs de compartimenter les ressources de cluster par locataire. Il est alors possible de regrouper les instances d'OpenStack dans des pools de ressources spécifiques dès le début. Pour plus d'informations sur les pool de ressources dans vCenter, consultez la documentation de vSphere.

    REMARQUE : cette fonctionnalité peut être appliquée uniquement aux nouvelles instances.

    Pour configurer et appliquer des pools de ressources pour VMware Integrated OpenStack.

    1. Dans vSphere Web Client, créez et définissez le pool de ressources dans le cluster exposé pour le nœud de calcul OpenStack.

    2. Dans le tableau de bord VMware Integrated OpenStack, créez un projet portant le même nom que le pool de ressources.

      REMARQUE : les noms du pool de ressources dans vCenter et du projet dans le tableau de bord VMware Integrated OpenStack doivent être identiques.

      Vous pouvez également définir les propriétés de métadonnées de type et d'image (vmware:resource_pool ou property vmware_resource_pool) via le tableau de bord VMware Integrated OpenStack pour vous assurer que des instances spécifiques utilisent un pool de ressources donné.

      REMARQUE : les propriétés des métadonnées d'image prévalent sur la propriété des métadonnées de type.

  • Paramètres supplémentaires avancés de machine virtuelle exposés dans OpenStack. Vous pouvez désormais optimiser les charges de travail sensibles à la latence, telles que les fonctions de réseau virtuel (VNF), en configurant les paramètres de sensibilité de latence, en activant le multi-threading et en réservant la totalité du CPU et de la mémoire. Ces paramètres sont exposés en tant que propriétés de métadonnées pour les images et les types OpenStack. Toutes les machines virtuelles créées ultérieurement à partir de l'image ou du type modifié héritent de ces propriétés.

    Propriétés des métadonnées de type :

    • quota:cpu_reservation_percent. Vous permet de configurer les réservations vCPU en valeur de pourcentage.

    • quota:memory_reservation_percent. Vous permet de configurer les réservations vRAM en valeur de pourcentage.

    • vmware:latency_sensitivity_level. Vous permet de configurer la sensibilité de latence. Pour plus d'informations sur la sensibilité de latence dans vSphere, consultez la documentation de vSphere.

    • hw:vifs_multi_thread. Active plusieurs threads de transmission.

    Propriétés des métadonnées d'image :

    • quota_cpu_reservation_percent. Vous permet de configurer les réservations vCPU en valeur de pourcentage.

    • quota_memory_reservation_percent. Vous permet de configurer les réservations vRAM en valeur de pourcentage.

    • vmware_latency_sensitivity_level. Vous permet de configurer la sensibilité de latence. Pour plus d'informations sur la sensibilité de latence dans vSphere, consultez la documentation de vSphere.

    • hw_vifs_multi_thread. Active plusieurs threads de transmission.

  • Conversion d'images étendue. Les images non-VMDK sont désormais converties automatiquement en images streamOptimized et avec le contrôleur lsiLogic. Cela aide les clients qui utilisent VMware Virtual SAN.

  • Migration de volumes. Vous pouvez désormais migrer des volumes non attachés d'une banque de données vers une autre. Consultez la commande viocli volume-migrate dans le Guide de l'administrateur de VMware Integrated OpenStack.

  • Documentation de la commande de l'interface de ligne de commande étendue. Toutes les commandes personnalisées de l'interface de ligne de commande de VMware Integrated OpenStack sont documentées dans la section Référence des commandes de l'interface de commande VMware Integrated OpenStack du Guide de l'administrateur 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.

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.3 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.1 ou 2.0.2 vers la version 2.0.3

Pour effectuer la mise à niveau de la version 2.0.1 ou 2.0.2 vers la version 2.0.3, vous installez et appliquez le correctif 2.0.3 (2.0.3 Build 3720171) sur votre déploiement existant.

Pour effectuer les procédures suivantes, vous devez avoir installé la version 2.0.1 ou 2.0.2. 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.

REMARQUE : vous ne pouvez pas effectuer la mise à niveau de la version 2.0 vers la version 2.0.3. Si la version de votre déploiement actuel est 2.0, vous devez d'abord effectuer la mise à niveau vers la version 2.0.1. Consultez les Notes de mise à jour du correctif VMware Integrated OpenStack 2.0.1.

  1. Récupérez le correctif (Build 2.0.3.3720171).

    • 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-203 --version 2.0.3.3720171

      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-203 -v 2.0.3.3720171

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

Pour procéder à la mise à niveau de la version 1.0.x vers la version 2.0.3, 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.3 :

  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 (2.0.3 Build 3717928). Pour plus de détails, consultez le Guide de l'administrateur de VMware Integrated OpenStack.

  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]

    Si la commande viocli dbverify ne retourne aucun enregistrement, vous pouvez continuer sans inquiétude. Si la commande indique la présence de groupes de sécurité « par défaut » dupliqués, consultez la section Les groupes de sécurité par défaut dupliqués peuvent provoquer l'échec de la mise à niveau dans ces notes de mise à jour pour savoir comment procéder.

  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 1.0.x et sélectionnez Migrer les données.

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

  13. 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.3 dans l'onglet Mises à niveau passe à En cours d'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.

  15. 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.3.

    vioconfig configure

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

Problèmes connus

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

  • La fonction Restaurer échoue après un échec de la mise à niveau.
    Ce problème a été constaté lors de la mise à niveau de la version 1.0.3 vers la version 2.0.3. 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 vSphere Web Client.

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

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

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

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

  • 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 -r RabbitMQ -n VIO-Controller-0 VIO-ComputeDriver-0 VIO-Memcache-1 VIO-LoadBalancer-1 VIO-DB-0

  • 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.x é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.x, puis redémarrez le gestionnaire VMware Integrated OpenStack.

  • Le passage de la version 2.0.x à 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 : consultez la Base de connaissances VMware pour trouver une solution à ce problème.

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

  • Les nouvelles définitions de métadonnées Glance ne sont pas chargées dans la mise à jour du correctif.
    Lorsque VMware Integrated OpenStack et mis à jour vers la version 2.0.3 à l'aide du correctif, les définitions de métadonnées Glance ne sont pas incluses.

    REMARQUE Ce problème n'affecte pas les nouveaux déploiements de la version 2.0.3.

    Solution : rechargez les définitions de métadonnées après la mise à jour.

    1. Terminez la mise à jour du correctif comme indiqué.

    2. À l'aide de SSH, connectez-vous au nœud controller01.

    3. Déchargez, puis rechargez les définitions de métadonnées.

      sudo -u glance glance-manage db_unload_metadefs
      sudo -u glance glance-manage db_load_metadefs

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

    Solution : actualisez la vue vSphere Web Client.

  • Les groupes de sécurité par défaut dupliqués peuvent provoquer l'échec de la mise à niveau.
    La présence de groupes de sécurité « par défaut » dupliqués peut provoquer l'échec de la mise à niveau. Comme documenté dans le Guide de l'administrateur de VMware Integrated OpenStack, pendant le processus de mise à niveau, vous exécutez la commande viocli dbverify pour détecter des problèmes potentiels. Si la commande viocli dbverify ne retourne aucun enregistrement, vous pouvez continuer sans inquiétude. Si les enregistrements de la commande montrent la présence de groupes de sécurité « par défaut » dupliqués, utilisez la solution suivante avant de poursuivre.

    Solution : supprimez manuellement le groupe de sécurité qui pose problème.

    1. Connectez-vous au tableau de bord VMware Integrated OpenStack.

      1. Sélectionnez le projet contenant les groupes de sécurités dupliqués.

      2. Dans les groupes dupliqués, sélectionnez celui dont les règles n'ont pas été modifiées par un utilisateur.

      3. Prenez connaissance de la valeur de l'UUID en cliquant sur Gérer les règles et en l'extrayant de l'URL.

        L'UUID est la dernière chaîne de l'URL. Par exemple : fbecbb6d-e75a-400e-bc3f-e1af2f93186d.

    2. Supprimez le groupe à l'aide de l'interface de ligne de commande.

      1. À l'aide de SSH, connectez-vous au nœud controller01 de VMware Integrated OpenStack et passez à l'utilisateur racine.

      2. Exécutez source /root/cloudadmin.rc.

      3. Exécutez nova secgroup-delete [UUID], où UUID est la valeur de l'UUID du groupe de sécurité obtenue dans l'étape précédente.

    Le groupe de sécurité « par défaut » est maintenant supprimé et vous pouvez reprendre les procédures de mise à niveau.

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.

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

  • Le client python-keystone essaye de manière incorrecte d'utiliser l'adresse IP virtuelle interne.
    Le client python-keystone essaye d'utiliser l'adresse IP virtuelle interne au lieu de l'adresse IP virtuelle externe, ce qui provoque un délai d'expiration avec un message d'erreur Impossible d'établir la connexion.

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

  • 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 problème a été résolu dans VMware Integrated OpenStack 2.0.3.

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

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

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

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

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

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

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

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