Il y a un problème relatif à la console OpenStack, non spécifique au pilote novad'OpenStack Oracle VM Server for SPARC.
Pour résoudre ce problème, cliquez sur la barre bleue en haut de la fenêtre de la console.
Certains anciens serveurs (comme les serveurs UltraSPARC T2) ne prennent pas en charge les étiquettes EFI. Dans ce cas, vous devez créer une VTOC basée sur des images VM pour prendre en charge le matériel ancien et nouveau. Ce problème impose également des limitations de taille de disque.
Si la propriété cpu-arch est définie sur une machine virtuelle, le pilote nova ne peut pas modifier la valeur de propriété cpu-arch plus tard. Ce problème se produit parce que la migration de la variante n'est pas encore prise en charge par le pilote Nova d'OpenStack Oracle VM Server for SPARC.
Vous devez utiliser un root ZFS pour disposer de la fonction d'extension de disque automatisée. Le système de fichiers et le gestionnaire de volume tels que UFS, SVM et VxFS ne sont pas pris en charge par cette fonctionnalité.
Les fonctionnalités d'Oracle VM Server for SPARC suivantes ne fonctionnent pas avec un domaine invité qui exécute Linux pour SPARC 1.0 :
Connexion et déconnexion dynamiques de volume
Connexion et déconnexion dynamiques de réseau
Migration en direct
Le journal de console vntsd ne migre pas avec le domaine invité. En conséquence, ces journaux de console ne sont plus disponibles et seules les entrées de journal récentes apparaissent.
Vous pourriez rencontrer des problèmes avec la file d'attente des messages ou d'autres services OpenStack si vos contrôleurs et vos nœuds de calcul possèdent des MTU non-concordantes dans leurs interfaces de gestion. Ces interfaces de gestion sont utilisées pour les communications de gestion OpenStack. Une configuration MTU non-concordante pourrait avoir un réseau de gestion de nœud de calcul de 9000 octets et un nœud de contrôleur de 1500 octets. Assurez-vous que tous les hôtes sont alignés sur leur réseau de gestion en termes de MTU.
Vous pouvez rencontrer des problèmes si vous ajoutez un commentaire (# à la fin d'une ligne de configuration dans un fichier de configuration OpenStack. OpenStack interprète les commentaires en ligne comme un élément de la valeur.
Assurez-vous que vous placez des commentaires sur les lignes de manière séparée et que la ligne de commentaire commence par un symbole de commentaire (#).
Par exemple, dans la ligne de configuration admin_password=welcome1 #my password, le mot de passe sera considéré être welcome1 #my password.
Utilisez la ligne suivante pour rechercher les commentaires en ligne d'un fichier de configuration :
# cat /etc/service/service.conf |egrep -v '^#' | grep '#'
Assurez-vous que les paramètres du serveur NFS sont corrects. Si vous choisissez un serveur inadéquat, le service nova-compute semble se bloquer au démarrage tout en essayant de monter le partage NFS.
Pour contourner ce problème, désactivez le service nova-compute et exécutez la commande kill pour arrêter le montage en cours sur le mauvais partage. Le pilote pouvant éventuellement faire une tentative supplémentaire pour monter le partage, il faut donc s'assurer que toutes les tentatives du pilote pour monter le mauvais partage sont arrêtées après la désactivation du service nova-compute. Corrigez ensuite le fichier nova.conf et activez le service nova-compute.
L'opération de reconstruction n'est pas encore prise en charge par le pilote Nova d'OpenStack Oracle VM Server for SPARC. Seule l'opération d'évacuation Nova est prise en charge. Si un utilisateur tente d'effectuer une opération de reconstruction, le disque existant de la machine virtuelle peut être recyclé et non reconfiguré.
Si un volume Cinder est créé avec une image SE, la copie de l'image SE peut être assez longue. Nova peut interrompre le délai d'attente avant la fin de la tâche de Cinder. Le service nova-compute (en dehors du pilote Nova d'Oracle VM Server for SPARC) interroge pendant un certain temps et attend pour voir si Cinder a créé le volume.
Vous pouvez envisager d'augmenter la valeur suivante si vous rencontrez ces "blocages" dans votre environnement :
block_device_allocate_retries=360
Redémarrez ensuite le service nova-compute.
Si vous rencontrez des problèmes pour accéder au partage NFSv4, un nœud de calcul peut être en panne. Si le partage NFSv4 devient indisponible, a des décalages ou rencontre d'autres problèmes de connexion pendant 10 minutes au moins, les noeuds de calcul deviennent inaccessibles en émettant une panne dans le domaine de contrôle. Si vous rencontrez ce problème fréquemment, désactivez la gestion de verrouillage distribué en commentant l'entrée dlm_nfs_server le temps de trouver la cause de ce problème.
Assurez-vous que votre stockage NFSv4 est hautement disponible et résilient. Assurez-vous que la délégation est désactivée.
Ce problème se pose si le service neutron-server est configuré pour EVS plutôt qu'à partir de ML2 et si le profil tente de mettre le service neutron-server en ligne avant qu'il ne soit correctement configuré.
Pour corriger ce problème, redémarrez le service manifest-import et désactivez le service neutron-server en exécutant ces commandes :
cctrl# svcadm restart manifest-import cctrl# svcadm disable neutron-server
Si vous configurez vos services de contrôleur de Cloud manuellement, vous devez terminer la configuration de vos fichiers de contrôleur de Cloud /etc/neutron/neutron.conf et /etc/neutron/api-paste.ini avant de réactiver le service neutron-server.