Notes de mise à jour de VMware Integrated OpenStack 2.0

VMware Integrated OpenStack 2.0 | 10 septembre 2015 | BUILD 3037963

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.

L'ensemble des informations concernant cette version sont hautement confidentielles et sont soumises à l'obligation de non-divulgation telle que spécifiée dans le contrat d'essai principal du logiciel bêta que votre société a déjà conclu.

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.

  • Mise à niveau transparente vers la version Kilo d'OpenStack. VMware Integrated OpenStack 1.0.x était basé sur la version Icehouse. En procédant à la mise à niveau vers la version 2.0, vous ignorez la version Juno. Une fois la mise à niveau terminée, vous pouvez revenir à la version 1.0.x.

  • Prise en charge de langues supplémentaires. VMware Integrated OpenStack 2.0 est disponible dans six langues supplémentaires : français, allemand, japonais, coréen, chinois simplifié et chinois traditionnel.

  • Enregistrement vApp amélioré et fiable. Le processus d'enregistrement du plug-in VMware Integrated OpenStack a été rationalisé.

  • Intégration LBaaS. VMware Integrated OpenStack 2.0 prend en charge LBaaS 1.0 (Load-Balancing-as-a-Service), qui est un service Neutron avancé d'OpenStack. LBaaS a été introduit en premier dans la version Juno d'OpenStack.

  • Intégration du Ceilometer. Il s'agit d'un service OpenStack qui collecte des mesures d'utilisation des ressources qui comprennent votre déploiement VMware Integrated OpenStack. Le Ceilometer demeure après la collecte des données pour la récupération suivante et l'analyse d'un serveur principal MongoDB. Remarque : En tant que composant OpenStack, le Ceilometer est pour le moment dans sa version préliminaire.

  • Extensibilité automatique Heat. Il s'agit d'un service Heat avancé qui permet aux utilisateurs de déterminer des mesures pour augmenter ou réduire les composants d'application. Cette fonction permet aux équipes de développement de faire face aux changements imprévisibles de la demande de services d'application. Le Ceilometer fournit les alarmes et les déclencheurs, Heat orchestre la création (ou la suppression) de composants évolutifs et LBaaS fournit l'équilibrage de la charge pour les composants évolutifs.

  • Intégration vSphere avancée. VMware Integrated OpenStack 2.0 présente la personnalisation invité Windows de VMware vSphere©. Les administrateurs de VMware peuvent définir divers attributs comme la capacité à générer de nouveaux SID, à attribuer des mots de passe administrateur pour la machine virtuelle, à gérer le traitement des noms, etc. Le placement des machines virtuelles à un niveau plus granulaire est également pris en charge en exploitant certaines fonctions de vSphere comme les paramètres d'affinité et d'anti-affinité.

  • L'introspection des métadonnées des images et les métadonnées des images spécifiques à VMware (vmware_adaptertype, vmware_disktype, etc.) peuvent être examinées et enregistrées avec l'image. L'introspection est prise en charge sur les images clairsemées et les images VMDK streamOptimized, ainsi que sur les OVA.

  • Conversion automatique d'images. VMware Integrated OpenStack 2.0 vous permet d'importer et de convertir les types d'images de disque suivants : QCOW2, RAW, VHD et VDI. Les images sont automatiquement converties dans un format VMDK approprié.

  • Sauvegarde et restauration. VMware Integrated OpenStack 2.0 vous permet de sauvegarder et de restaurer vos services et données de configuration OpenStack via le gestionnaire VMware Integrated OpenStack.

  • Récupération améliorée VMware Integrated OpenStack 2.0 inclut de nouvelles fonctionnalités pour vous permettre de récupérer votre plan de contrôle après un échec.

Mise à jour de la 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.0

La procédure de mise à niveau s'exécute 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.

Conditions requises

  • Doublez les ressources de la banque de données dédiées à votre déploiement VMware Integrated OpenStack actuel.
  • Par mesure de sécurité, sauvegardez votre déploiement actuel. Pour plus de détails, reportez-vous au Guide d'administration de VMware Integrated OpenStack.
  • Conservez la configuration de votre déploiement actuel VMware Integrated OpenStack en l'exportant comme modèle.

Pour mettre à niveau vers VMware Integrated OpenStack 2.0 :

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

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

  3. Cliquez sur l'onglet Opération de mise à niveau.

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

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

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

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

  7. Cliquez sur Suivant.

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

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 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.0. 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 connaissance VMware ou contactez l'assistance technique de VMware.

  • Impossible de modifier les paramètres syslog à la suite du déploiement dans l'interface de gestion de VIO.

    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 gestion de VIO (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 Faux 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

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

    Solution : vous corrigez ce problème en modifiant le paramètre rootdelay=180 du fichier /boot/grub/menu.lst.

    1. Supprimez le snapshot de la machine virtuelle de modèle de VMware Integrated OpenStack.
    2. Démarrez la machine virtuelle de modèle de VMware Integrated OpenStack.
    3. À l'aide de SSH, connectez-vous à l'interface de ligne de commande de la machine virtuelle de modèle.
    4. Ouvrez le fichier /boot/grub/menu.lst dans un éditeur de texte.
    5. Ajoutez le paramètre rootdelay=180 à la ligne 135.
    6. Enregistrez le fichier /boot/grub/menu.lst.
    7. Supprimez l'intégralité du contenu du fichier /etc/network/interfaces.
    8. Arrêtez la machine virtuelle de modèle de VMware Integrated OpenStack.
    9. Dans vCenter, supprimez le déploiement ayant échoué.
    10. Redéployez VMware Integrated OpenStack.

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

  • Statut de membre non mis à jour régulièrement, uniquement lors de la lecture des statistiques de pools.
    Ce problème a été constaté dans les déploiements avec NSX 6.2 et VMware Integrated OpenStack 2.0 avec LBaaS activé. Le statut du nœud des membres de l'équilibrage de charge sont mis à jour uniquement lorsque le statut des pools est extrait. Il devrait être mis à jour régulièrement et indépendamment du statut des pools.

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

    Solution : utilisez les procédures de récupération après échec afin de récupérer les nœuds de base de données, puis redémarrez le déploiement VMware Integrated OpenStack. Pour plus de détails, reportez-vous au Guide d'administration de VMware Integrated OpenStack.

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

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

    Solution : vous pouvez corriger ce problème en arrêtant, puis en démarrant votre déploiement.

    viocli deployment stop
    viocli deployment start

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

  • 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èmes résolus

  • Actions CLI d'arrêt/de démarrage non reflétées dans vSphere Web Client.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.

  • Les machines virtuelles Edge requièrent des banques de données partagées.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.

  • Sans NAT, les règles de pare-feu empêchent la communication externe vers interne.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.

  • L'ajout d'un nouveau routeur logique locataire à une instance Edge partagée brise l'itinéraire statique.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.

  • Erreur de type de système d'exploitation d'images.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.

  • Échec du déploiement du cluster avec NSX-V en raison d'un caractère « $ » dans le mot de passe.
    Ce problème a été résolu dans VMware Integrated OpenStack 2.0.