VMware Integrated OpenStack 7.1 | 13 mai 2021 | Build OVA 17987092, correctif 17987093 Vérifiez les compléments et les mises à jour de ces notes de mise à jour.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

• À propos de VMware Integrated OpenStack
• Nouveautés
• Mettre à niveau vers la version 7.1
• Compatibilité
• Remarques concernant l'obsolescence
• Problèmes résolus
• Problèmes connus

À 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 gestionnaire de déploiement qui s'exécute en tant que dispositif virtuel dans l'instance de vCenter Server.

Nouveautés

• Prise en charge des dernières versions des produits VMware : 
  • VMware Integrated OpenStack 7.1 est entièrement compatible avec VMware vSphere 7.0 U2, NSX-T 3.1.1 et NSX-V 6.4.10
• Nouvelles fonctionnalités et amélioration :
  • Plan de gestion :
    • Prise en charge de la récupération d'urgence pour le plan de gestion VIO. Fournit une nouvelle commande viocli pour prendre en charge la récupération du plan de gestion après un sinistre. La procédure de récupération d'urgence complète est validée avec la fonctionnalité multisite SRM, vSphere Replication et NSX-T, qui couvre les instances Nova, les volumes Cinder et les réseaux Neutron. Une fois le déploiement récupéré sur le site de récupération d'urgence cible, les utilisateurs peuvent utiliser VIO pour gérer les objets Nova/Cinder/Neutron récupérés.
    • Prise en charge de la migration du plug-in de gestion NSX-T Neutron vers le plug-in de stratégie. 
    • Prise en charge de plusieurs clés de licence : Autorisez l'administrateur à entrer plusieurs clés de licence VIO et à les attribuer pour utilisation.
  • Pilote OpenStack :
    • Prise en charge du type Octavia. La fonctionnalité permet aux utilisateurs d'utiliser la capacité des types Octavia d'OpenStack sur les équilibrages de charge créés par VIO sur NSX-T. Cette fonctionnalité est prise en charge par le plug-in NSX-P Neutron et avec NSX-T 3.1 ou version ultérieure.
  • Évolutivité :
    • Prise en charge d'une plus grande évolutivité. Un déploiement VIO peut désormais prendre en charge jusqu'à 128 nœuds de calcul Nova, jusqu'à 10 000 réseaux de locataires avec le plug-in de stratégie NSX-T Neutron et jusqu'à 8 fédérations de déploiements VIO avec vIDM comme fournisseur d'identité.

Mettre à niveau vers la version 7.1

• Pour mettre à niveau depuis la version 7.0/7.0.1, utilisez la commande viocli patch. Veuillez trouver les instructions détaillées dans le guide d'installation du produit.
• Pour mettre à niveau depuis la version 6.0, utilisez la procédure de mise à niveau bleue/verte décrite dans le guide d'installation du produit.
• VIO 7.1 ne prend pas en charge la mise à niveau directe depuis la version 5.x. Veuillez d'abord mettre à niveau vers la version 7.0.1.

Compatibilité

• Consultez Matrices d'interopérabilité des produits VMware pour plus d'informations sur la compatibilité de VMware Integrated OpenStack avec les autres produits VMware.

Remarques concernant l'obsolescence 

• Les fonctionnalités de mise en réseau suivantes ont été obsolètes et seront supprimées dans la prochaine version de VIO :
  • Pilote NSX Data Center for vSphere pour Neutron.
  • Le plug-in de gestion NSX-T pour Neutron sera remplacé par le plug-in de stratégie de NSX-T.
  • Le plug-in TVD, qui permet à un déploiement unique de VMware Integrated OpenStack d'utiliser un serveur principal NSX Data Center for vSphere et un serveur principal NSX-T Data Center.
• Neutron FWaaSv2 sera obsolète dans une version ultérieure.

Problèmes résolus

Les problèmes résolus sont regroupés comme suit.

• Problèmes de gestion VIO résolus
• Problèmes OpenStack résolus

Problèmes de gestion VIO résolus

• 2750794 résolu : les données de sauvegarde étaient supprimées lorsque l'administrateur VIO supprime la tâche de planification de sauvegarde VIO.

  Dans VIO 7.0, lorsque l'administrateur supprime la tâche de planification de sauvegarde VIO, les données de sauvegarde stockées dans la bibliothèque de contenu vCenter étaient également supprimées.
  Dans VIO 7.1, les données de sauvegarde ne sont pas supprimées lorsque la tâche de planification de sauvegarde est supprimée.

• 2738659 résolu : la procédure de restauration de sauvegarde VIO ne fonctionnait pas correctement lorsque vCenter SSL est activé.

  la procédure de restauration de sauvegarde VIO ne fonctionnait pas correctement lorsque vCenter SSL est activé. Les données de sauvegarde ne peuvent pas être téléchargées dans la bibliothèque de contenu de vCenter et l'erreur « x509 : autorité inconnue pour le certificat » est signalée.

• 2680755 résolu : l'assistant de déploiement VIO ne progresse pas et signale une erreur « Le chargement des ressources vCenter a expiré ».

  VIO 7 utilise govmomi pour récupérer les informations d'inventaire de vCenter. Govmomi passe en état de panique si DistributedVirtualPortgroup dispose d'un qualificateur de trafic « MAC » ou « Trafic système » pour le filtrage et le balisage du trafic dans l'environnement vSphere cible.

• 2677748 résolu : l'interface utilisateur Web de VIO Manager ne parvient pas à répertorier l'état des services OpenStack

  L'interface utilisateur Web de VIO Manager ne parvient pas à répertorier les services qui tournent en rond et affiche uniquement le message « aucune ressource trouvée ».

• 2591794 résolu : le service de métadonnées est inaccessible dans l'environnement NSX-V

  Le service de métadonnées n'est pas accessible si le serveur Edge du proxy de métadonnées n'est pas routable à partir de l'API VMware Integrated OpenStack. Dans ce cas, VIO 7.1 atteint automatiquement le proxy de métadonnées via l'API de gestion.

• 2688209 résolu : le bundle de support VIO contient des informations de journal pendant seulement deux jours environ.

  Dans VIO 6.0 et 7.0, le bundle de support peut contenir les informations de journal pendant seulement deux jours environ. Ces informations de journal ne sont pas suffisantes à des fins de dépannage. Pour résoudre ce problème, VIO 7.1 active les sauvegardes de journaux générées automatiquement pour augmenter la conservation des journaux jusqu'à 7 jours.

• 2707205 résolu : VIO 6/7 n'a pas défini rp_filter en mode libre sur les nœuds de contrôleur

  VIO 6/7 bascule vers PhotonOS et n'a pas explicitement défini rp_filter sur les nœuds de contrôleur, ce qui signifie qu'ils sont définis sur « 1 » (mode RFC3704 strict) par défaut. Il se peut que les applications sur le réseau de gestion ne parviennent pas à se connecter aux points de terminaison publics, car le paramètre de mode strict entraîne l'abandon des paquets.

• 2631412 résolu : l'interface utilisateur graphique de VIO utilise un certificat nommé « Certificat de faux contrôleur d'entrée Kubernetes »

  Le nom du certificat est celui par défaut créé par le contrôleur d'entrée Nginx. Lorsque vous faites une mise à niveau vers VIO 7.1, il est remplacé par le nom approprié. 

Problèmes OpenStack résolus

• 2594923 résolu : la propriété vmware_cpu_affinity de l'image Glance ne fonctionne pas.

  la propriété vmware_cpu_affinity de l'image Glance ne fonctionne pas. Une erreur se produit lors de l'utilisation d'une telle image Glance pour créer des instances Nova « Erreur : une liste est requise dans le champ vmware_cpu_affinity et non une chaîne (HTTP 400) »

  Dans VIO 7.1, la propriété peut être définie comme dans l'exemple ci-dessous :

  openstack image set --property vmware_cpu_affinity="[0,1]" image_name

• 2753879 résolu : la pile Heat n'a pas pu être mise à jour en raison de l'extension fwaas v1.

  La pile Heat en amont utilise toujours fwaas v1 et ne prend pas en charge fwaas v2. Toutefois, VIO 7 prend uniquement en charge fwaas v2.

• 2713308 résolu : les images Glance de base inutilisées s'accumulent dans le dossier de cache Nova.

  les images Glance de base inutilisées s'accumulent dans le dossier de cache Nova. Le processus de nettoyage de l'image inutilisée ne fonctionne pas correctement.

• 2710808 résolu : VIO 7 ne prend en charge qu'un seul ns_record dans le pool Designate

  VIO 7 ne prend en charge qu'un seul ns_record dans le pool Designate, ce qui est amélioré dans VIO 7.1 afin de prendre en charge plusieurs ns_records dans Designate.

• 2707581 résolu : si une stratégie QoS est configurée comme stratégie par défaut, le réseau externe utilise également cette stratégie QoS.

  Si une stratégie QoS est configurée par défaut, le réseau externe utilise également cette stratégie QoS. Cela n'est pas correct pour le réseau externe.

• 2705010 résolu : la taille de l'équilibrage de charge avec Octavia n'a pas pu être modifiée dans VIO 7.

  Le LBaaS Octavia ne permet pas à l'utilisateur de modifier la taille de l'équilibrage de charge.
  VIO 7.1 fournit des options pour la configuration de la taille.

  default_edge_size = <purpose>:<edge size>[,...]
  

  Les buts pris en charge sont router, dhcp, lb.
  Les tailles prises en charge sont compact, large, xlarge, quadlarge.
  Par exemple : default_edge_size = lb:xlarge

  Utilisez « viocli update neutron » pour ajouter les paramètres ci-dessous sous la section [nsxv] afin de configurer :

  conf:
    neutron:
    plugins:
      nsx:
        nsxv:
          default_edge_size: lb:xlarge

• 2701437 résolu : l'option d'image Glance « vmware_create_template=false » ne fonctionnait pas correctement.

  L'image Glance ne créait et ne démarrait pas les instances Nova dans les configurations suivantes :

  • Lorsque l'option vmware_create_template est false dans la configuration Glance
  • Lorsque l'utilisateur crée l'image Glance à l'aide de l'interface de ligne de commande OpenStack avec la propriété « vmware_create_template=false »
    Par exemple :

  openstack image create --disk-format vmdk --file vmdk --property vmware_create_template=false imageName

• 2699470 résolu : vous ne pouvez pas exécuter la commande nova-manage dans l'espace de calcul Nova.

  Lorsque vous exécutez la commande nova-manage à partir de l'espace de calcul Nova, il existe une exception DBNonExistentTable, car aucune section [database] n'est présente dans nova-compute.conf.

• 2688655 résolu : l'authentification de l'interface de ligne de commande OpenStack via openid ne fonctionne pas sur VIO 7.0.1

  L'authentification de l'interface de ligne de commande OpenStack via openid ne fonctionne pas sur VIO 7.0.1 avec l'erreur Non autorisé (HTTP 401).

• 2674517 résolu : le disque d'échange défini dans le type n'est pas correctement monté dans l'instance Nova.

  le disque d'échange défini dans le type n'est pas correctement monté dans l'instance Nova. Ce problème est résolu dans VIO 7.1 avec une limitation de la non-prise en charge du redimensionnement de VM avec disque d'échange.

• 2672946 résolu : l'espace de configuration AZ du traitement Nova passe à l'état CrashLoopBackOff lorsque les noms d'agrégation d'hôtes ont des conditions spécifiques.

  S'il existe une agrégation d'hôtes nommée « nova » dans la zone AZ Nova et une autre agrégation d'hôtes nommée « xxxxx-nova » qui correspond à « ^.*nova$ » dans la même zone (par exemple, 5-nova), l'espace de calcul Nova az-setup passe à l'état CrashLoopBackOff.

• 2656225 résolu : l'utilisateur ne peut pas ouvrir la console de VM avec l'erreur « Erreur : la console est actuellement indisponible » via l'interface utilisateur d'Horizon

  Horizon ne peut pas afficher les consoles de VM avec l'erreur « Erreur : la console est actuellement indisponible » dans certaines situations. Cela se produit lorsque le chemin de configuration vmx devient plus long, nova-compute ne peut pas insérer une ligne contenant les informations d'un ticket MKS et le chemin de configuration vmx vers la base de données. Par exemple, SvMotion pour une instance de VIO entraîne la modification du chemin de configuration vmx en une chaîne plus longue.

• 2652286 résolu : la suppression du moniteur de santé LB échoue avec l'erreur « Erreur côté serveur : l'objet « NoneType » n'a pas d'attribut « load_balancer_id ». »

  Il s'agit d'un bogue dans le service Octavia qui affecte le plug-in VMware NSX. Dans certains cas, le service Octavia ne parvient pas à récupérer le pool correspondant à un moniteur de santé, ce qui déclenche cette erreur. Le bogue est actuellement ouvert et suivi à l'adresse https://storyboard.openstack.org/#!/story/2008231

• 2678067 résolu : le curseur de la souris ne fonctionne pas systématiquement pour les VM Nova Windows via Horizon Console

  Lorsque vous accédez à Horizon Console sur un navigateur, le curseur de la VM Windows ne répond pas, sauf si Tab ou Ctrl+clic est utilisé. Il cessera finalement de répondre à nouveau au clic gauche.

• 2755304 résolu : la transaction de modification d'état LB Octavia échoue et reste bloquée à l'état PENDING_DELETE.

  Octavia utilise un socket UNIX pour communiquer en interne dans l'agent du pilote. Il peut arriver qu'il y ait un délai d'expiration lors de l'écriture dans ce socket, ce qui fait échouer la transaction de modification d'état. Un mécanisme de nouvelle tentative est ajouté pour la transaction de modification d'état.

• 2643797 résolu : lorsque vous configurez trusted_dashboard, le nom de domaine complet Horizon est enregistré en tant qu'adresse IP dans kystone.conf et non sous forme de nom de domaine complet.

  Lorsque vous configurez des paramètres de fédération pour Keystone, le nom de domaine complet Horizon fourni est enregistré en tant qu'adresse IP dans le fichier de configuration Keystone et non sous la forme du nom de domaine complet fourni.

  viocli update keystone
  conf:
    keystone:
      federation:
        trusted_dashboard: https://HorizonFQDN/auth/websso/

Problèmes connus

• La limite de taux d'API publique n'est pas disponible.

  Dans VMware Integrated OpenStack 7.1, il n'est pas possible d'appliquer la limite de taux aux API publiques.

  Solution : aucune. Cette fonctionnalité sera fournie dans une version ultérieure.

• La création d'un équilibrage de charge avec un sous-réseau privé qui n'est pas attaché à un routeur génère un état d'erreur

  Avec les plug-ins Neutron NSX-T tels que les plug-ins MP et NSX-T Policy, la création d'un équilibrage de charge avec un sous-réseau privé qui n'est pas attaché à un routeur entraîne un équilibrage de charge qui est dans un état d'erreur et l'erreur ne sera pas signalée à l'utilisateur.

  Solution : créez l'équilibrage de charge avec un sous-réseau qui est attaché à un routeur.

• Si des informations d'identification incorrectes sont saisies lors du déploiement d'OpenStack, l'assistant peut ne pas reconnaître les informations d'identification correctes.

  Lors du processus de déploiement d'OpenStack, si les informations d'identification de vCenter Server ou NSX Manager sont entrées de manière incorrecte, l'assistant peut ne pas reconnaître les informations d'identification correctes. Même si vous supprimez les informations incorrectes et que vous entrez les informations d'identification correctes, l'assistant peut ne pas parvenir à les valider.

  Solution : fermez l'assistant de déploiement et ouvrez-le à nouveau.

• La sécurité des ports OpenStack ne peut pas être appliquée sur les ports directs dans le plug-in NSX-V Neutron

  L'activation de port-security pour les ports avec un vnic-type direct peut être inefficace. Les fonctionnalités de sécurité ne sont pas disponibles pour les ports directs.

  Solution : aucune.

• Impossible de se connecter à VIO si le mot de passe vCenter et NSX contient $$

  Si le compte VIO configuré pour le système vCenter et NSX sous-jacent utilise un mot de passe qui contient « $$ », VIO ne peut pas terminer l'authentification pour vCenter et NSX en raison de l'utilisation de « $$ » dans le mot de passe. Les espaces OpenStack peuvent passer à l'état CrashLoopBackOff.

  Solution : utilisez d'autres mots de passe qui ne contiennent pas « $$ ».

• Les équilibrages de charge sont bloqués à l'état PENDING_XXX et ne peuvent pas être utilisés.

  Ce problème de blocage se produit pour chaque équilibrage de charge qui est créé, modifié ou supprimé lorsque octavia-da dans l'espace octavia-api a planté.

  Solution : ces équilibrages de charge ne peuvent plus être utilisés dans Octavia. Ils doivent être supprimés manuellement de la base de données Octavia.

• L'utilisateur n'a pas pu télécharger l'image Glance à partir du client d'interface de ligne de commande OpenStack

  Lors du téléchargement de l'image à partir de l'interface de ligne de commande OpenStack, l'erreur suivante s'affiche : « [Errno 32] Téléchargement d'image corrompue. » Cela est dû au fait que VIO stocke l'image en tant que modèle de VM dans la banque de données vSphere par défaut. La valeur md5sum n'est pas enregistrée entre VMDK et le modèle de VM.

  Solution : l'image Glance peut être téléchargée avec les configurations suivantes :

  • l'option vmware_create_template est false dans la configuration Glance
  • l'utilisateur crée l'image Glance à l'aide de l'interface de ligne de commande OpenStack avec la propriété « vmware_create_template=false »
• Après la définition administrative d'un groupe de pare-feu DOWN (state=DOWN), l'état opérationnel du groupe de pare-feu est toujours DOWN, même après que l'état d'administration du groupe de pare-feu soit UP à nouveau

  Le service neutron-fwaas ignore la modification de l'état opérationnel lors des transitions qui n'impliquent pas l'ajout d'un port ou la suppression d'un port du groupe de pare-feu.

  Solution : ajoutez ou supprimez un port. Vous pouvez aussi ajouter et supprimer un port déjà lié au groupe de pare-feu.

• Impossible d'ignorer la validation du certificat si le certificat vCenter et NSX est signé par une autorité de certification intermédiaire

  Lorsque le certificat vCenter et NSX est signé par une autorité de certification intermédiaire, certains services VIO ne peuvent pas être configurés correctement pour valider le certificat. L'échec peut être observé dans différents formats. Par exemple, vous ne pouvez pas désélectionner « Ignorer la validation du certificat » lors de l'ajout ou de la modification de vCenter ou NSX.

  Solution : choisissez « Ignorer la validation du certificat » dans l'interface utilisateur, modifiez la CR vCenter et NSX et définissez spec.insecure sur true.

• Le fait de cliquer sur Modifier et Enregistrer sur un segment Neutron active accidentellement la multidiffusion

  Dans l'interface utilisateur de stratégie NSX-T, si des modifications sans lien sont apportées au routage de multidiffusion, ce dernier sera activé sur le segment.

  Solution : désactivez explicitement la multidiffusion dans l'interface utilisateur lors de la modification du segment.

• Les opérations d'ajout de membres échouent avec l'erreur « Le fournisseur « vmwareedge » signale une erreur : le certificat n'a pas pu être récupéré:: » (État HTTP 500)

  Impossible d'ajouter ou de supprimer des membres des équilibrages de charge Octavia HTTPS_TERMINATED.

  Solution : utilisez l'interface de ligne de commande OpenStack pour ajouter ou supprimer des membres.

  1. Effectuez l'extraction de tls_container_ref pour tous les utilisateurs impactés

  2. Recherchez des URI de conteneur, de secret et de certificat

  3. Récupérez l'ID d'utilisateur du service Octavia

  4. Ajoutez les URI récupérés à l'étape 2 aux ACL pour l'ID d'utilisateur récupéré à l'étape 3

• Les passerelles de niveau 1 ne pouvaient pas être entièrement restaurées lors d'une migration MP2P à grande échelle

  Certaines passerelles de niveau 1 ne pouvaient pas être entièrement restaurées et l'état de suppression restait en cours lors d'une migration MP2P à grande échelle. L'échec de la restauration peut être dû à une erreur lors de la migration.

  Solution : restaurez UA et effectuez à nouveau la migration.

• Erreur d'entrée en double dans la fédération Keystone

  Après la suppression de l'OIDC dans la fédération Keystone, si le même utilisateur tente de se connecter avec OIDC, l'authentification échoue avec un message 409.

  Solution : supprimez l'utilisateur via Horizon ou l'interface de ligne de commande OpenStack.

  Par exemple :

  1. Dans Horizon, connectez-vous avec un compte d'administrateur.

  2. Définissez le contexte de domaine avec le domaine fédéré.

  3. Sur la page d'utilisateur, supprimer l'utilisateur dont la colonne Nom d'utilisateur est Aucun.

  Dans l'interface de ligne de commande OpenStack

  openstack user list --domain <federated domain name>

  openstack user delete <user id> --domain <federated domain name>

• Une fois la migration réussie, les journaux d'un espace de migration ne sont pas disponibles dans le bundle de support VIO
   

  Une fois la migration réussie, le plan de contrôle VIO est reconfiguré et l'espace de migration est supprimé. Par conséquent, son journal n'est pas capturé sur le bundle de support.

  Solution : les journaux de l'espace de migration sont disponibles sur le nœud de contrôleur et ils sont exécutés et stockés dans /var/log/vmware/mp2p_migration.log. Vous pouvez récupérer les fichiers journaux en accédant aux nœuds de contrôleur via viossh. Les fichiers journaux sont disponibles uniquement sur le contrôleur sur lequel l'exécution de la tâche a lieu. Par conséquent, il peut être nécessaire de les parcourir sur plusieurs contrôleurs jusqu'à ce que vous les trouviez.

• Échec de l'activation de Ceilometer lorsqu'il existe 10 000 réseaux de locataires Neutron.

  Lorsqu'il existe une grande quantité de ressources, telles que des réseaux créés dans vSphere, VIO génère de nombreuses ressources client pour ces objets. Si le nombre de CR est trop grand, l'interface utilisateur Web de VIO Manager échouera sur l'API du serveur principal, car les données de réponse sont trop volumineuses pour la demande HTTP.

  Solution : dans VIO Manager, supprimez manuellement les ressources client découvertes.

  Les CR peuvent être répertoriées à l'aide de la commande ci-dessous :

  kubectl -n openstack get discoveries.vio.vmware.com

  Les CR peuvent être supprimées avec la commande ci-dessous. Par exemple :

  kubectl -n openstack delete discoveries.vio.vmware.com vcenter-vcenter2-networks-2

• Le certificat doit être signé par une autorité de certification et réappliqué après la restauration

  Le secret des certificats qui contient la clé privée et le certificat VIO n'est pas dans l'étendue de sauvegarde actuellement. Après une restauration qui n'est pas sur place, le certificat importé précédemment n'existera pas dans un nouveau déploiement.

  Solution :

  1. Enregistrez le secret des certificats à partir du déploiement d'origine
  osctl get secret certs -oyaml > certs.yaml
  2. Après la restauration, remplacez les valeurs « private_key » et « vio_certificate » dans le secret des certificats par les données de l'étape 1.
  3. Arrêtez/démarrez les services.

• Impossible de créer des instances sur un nœud de calcul Nova spécifique et le journal de calcul Nova se bloque.

  Lors de la création d'une instance, celle-ci est dans l'état BUILD et n'aboutira jamais. Consultez le journal nova-compute, peu de journaux sont disponibles et sans plus d'informations.

  Solution : redémarrez manuellement l'espace novacompute.

• Il n'y a aucune réponse lors de l'enregistrement des modifications des règles de pare-feu à partir de l'interface utilisateur d'Horizon.

  Si l'une des options requises marquées par « * » n'est pas mise à jour lors de la modification des règles de pare-feu, il n'y a aucune réponse de l'interface utilisateur lors de l'enregistrement des modifications.

  Solution : mettez à jour toutes les options requises lors de la modification des règles de pare-feu.

• Certaines opérations du jour 2 ne fonctionnent pas après la modification du nom d'utilisateur et du mot de passe de vCenter à partir de l'interface utilisateur Web de VIO Manager.

  Lorsque l'utilisateur met à jour les informations d'identification de vCenter dans l'interface utilisateur Web de VIO Manager, les services OpenStack peuvent fonctionner, mais le plan de contrôle de VIO ne peut pas communiquer avec vCenter, car le secret de vCenter dans le fournisseur de cloud k8s et cluster-api n'est pas mis à jour.

  Solution : utilisez la commande « kubectl patch secret » pour mettre à jour les informations d'identification de vCenter dans VIO Manager.

  Vérifiez les informations du secret vc-credential actuelles :

  kubectl -n kube-system get secret viocluster1-vc-credentials -o yaml 
  kubectl -n openstack get secret viocluster1-vc-credentials -o yaml
  

  Mettez à jour le secret vc-credentials avec le nouveau nom d'utilisateur/mot de passe (au format base64) :

  kubectl -n kube-system patch secret viocluster1-vc-credentials --patch \
  '{"data": {"your_vcenter.password": "password_in_base64", "your_vcenter.username": "username_in_base64"}}'
  kubectl -n openstack patch secret viocluster1-vc-credentials --patch \
  '{"data": {"password": "password_in_base64", "username": "username_in_base64"}}'
  

• L'interface utilisateur d'Horizon affiche « xmltooling::IOException » lors de la connexion avec le fournisseur d'identité de la fédération SAML.

  Lorsque VIO est configuré avec un fournisseur d'identité SAML externe, une erreur « xmltooling::IOException » est signalée lorsque l'utilisateur tente de se connecter à la fédération SAML.

  Solution : cliquez sur le bouton Actualiser dans le navigateur. L'utilisateur accède à la page de connexion du fournisseur d'identité.

• Lors de l'utilisation de la commande « viocli update » pour mettre à jour la CR, une erreur peut se produire si vous entrez un entier long comme valeur. Par exemple, profile_fb_size_kb : 2097152.

  Dans certains cas, les entiers longs sont convertis en notation scientifique par les diagrammes Helm VIO.

  Solution : ajoutez des guillemets droits avant et après l'entier long. Par exemple, profile_fb_size_kb : "2097152".

• Les snapshots sur un nœud de contrôleur empêchent certaines opérations VIO.

  Le volume persistant sur un nœud de contrôleur ne peut pas être déplacé si un snapshot du nœud de contrôleur existe. Par conséquent, la prise d'un snapshot d'un contrôleur n'est pas prise en charge par VIO.

  Solution : supprimez tous les snapshots sur les nœuds de contrôleur.

• Les volumes créés à partir d'images sont toujours démarrables par défaut.

  Si vous incluez le paramètre --non-bootable lors de la création d'un volume à partir d'une image, celui-ci n'est pas appliqué.

  Solution : une fois le volume créé, mettez-le à jour pour qu'il ne soit pas démarrable.