Problèmes connus
Cette section recense les problèmes d'ordre général et les bogues liés au logiciel Oracle VM Server for SPARC 3.5.
Bogues liés au logiciel Oracle VM Server for SPARC
Cette section récapitule les bogues que vous risquez de rencontrer lors de l'utilisation de cette version du logiciel. Les bogues les plus récents sont décrits en premier. Des solutions de contournement et des procédures de récupération sont spécifiées, le cas échéant.
Bogues liés au logiciel Oracle VM Server for SPARC 3.5
Arrêt brutal de ldmd après l'échec de la suppression de coeurs d'un domaine
ID de bogue 26435797 : Le démon ldmd peut vider un coeur en cas d'échec d'une opération de suppression de CPU virtuelle ou de coeur de CPU. Cette erreur peut se produire lorsque toutes les CPU du domaine cible sont associées ou fortement chargées.
Lorsque cette erreur survient, la commande ldm remove-core peut émettre l'un des messages d'erreur suivants :
Invalid response Failed to receive version negotiation response from logical domain manager: Connection reset by peer
Pour procéder au retrait de CPU virtuelles, vous devez dissocier certaines CPU du domaine cible ou réduire la charge globale. Notez que ce problème n'affecte pas les opérations de retrait de CPU virtuelles sur les domaines associés ou non associés.
Le comportement vsw-relay-mode repasse de remote à local lorsque le domaine de service associé redémarre
ID de bogue 26184111 : La propriété vsw-relay-mode est définie sur un commutateur virtuel pour activer le mode de relais réfléchissant. Ce mode n'étant pas conservé après un redémarrage du domaine de service, l'état reprend la valeur par défaut local.
Solution de contournement : Exécutez la commande suivante sur le commutateur virtuel après le redémarrage qui active la propriété vsw-relay-mode :
primary# ldm set-vsw vsw-relay-mode=remote primary-vsw0
La migration entre CPU peut échouer si les compteurs de performance globaux sont activés
ID de bogue 26047815 : Dans certains scénarios de migration entre CPU, une migration peut échouer avec les erreurs suivantes :
API group 0x20b v1.0 is not supported in the version of the firmware running on the target machine. API group 0x214 v1.0 is not supported in the version of the firmware running on the target machine.
La propriété cpu-arch du domaine est définie sur generic ou migration-class1
Le domaine comporte un paramètre de propriété perf-counter qui inclut la valeur global
Le domaine a été initialisé sur, au minimum, un serveur de série SPARC M7 ou T7
La machine cible est une plate-forme publiée avant le serveur de série SPARC M7 ou T7
Toutes les conditions suivantes doivent être réunies pour que ce problème se produise :
Ce problème se produit parce qu'un domaine initialisé sur, au minimum, un serveur de série SPARC M7 ou T7 avec un paramètre de propriété perf-counter incluant la valeur global enregistre des interfaces d'hyperviseur du compteur de performances spécifiques qui n'existent pas sur les plates-formes plus anciennes. Dans le cadre de la migration, une vérification est effectuée pour s'assurer que toutes les interfaces utilisées par le domaine sont présentes sur la machine cible. Lorsque ces interfaces propres au serveur de série SPARC M7 ou T7 sont détectées, la migration est abandonnée.
Solution de contournement : Ne définissez pas perf-counter=global si cpu-arch n'a pas la valeur native et si des serveurs de série SPARC M7 et T7, au minimum, font partie du pool de migration.
Le sous-système HBA SCSI virtuel ne prend pas en charge tous les périphériques SES (SCSI Enclosure Services)
ID de bogue 25865708 : Un périphérique SES considéré par le système d'exploitation Oracle Solaris comme fonction secondaire ne peut pas être pris en charge par vhba. vhba peut prendre en charge un périphérique SES dont le type a la valeur 0xd, comme indiqué dans le champ inq_dtype de la charge utile INQUIRY.
Lorsque le fichier binaire vhba du domaine invité tente d'initialiser certains périphériques SES (SCSI Enclosure Services), il provoque l'émission du message d'avertissement suivant par la commande scsi :
... scsi: WARNING: scsi_enumeration_failed: vhba2 probe@w50080e51bfd32004,0,d enumeration failed during tran_tgt_init
La sous-chaîne ,d représente le chiffre hexadécimal 0xd, qui est le code standard SCSI pour un périphérique SES. La chaîne ,d indique que ce message d'avertissement résulte d'un type non pris en charge de périphérique SES.
vhba peut prendre en charge un périphérique SES dont le type possède la valeur 0xd indiquée dans le champ inq_dtype de la charge utile INQUIRY :
# mdb -k
> ::vsan
vsan_t( 6400126e08c0 ) cfg-hdl(0) iport-path(/pci@300/pci@1/pci@0/pci@4/SUNW,emlxs@0,11/fp@0,0)
vsan_iport_t( 6400125b8710 )
vsan_tport_t( 64001bf89718 ) tport_phys(w216000c0ff8089d5)
vsan_lun_t( 640011aa65d0 ) lun(0) vlun-id(1127b) []
> 640011aa65d0::print vsan_lun_t vl_sd |::print struct scsi_device sd_inq |::print struct scsi_inquiry inq_dtype
inq_dtype = d
ldomHbaTable est vide
ID de bogue 24393532 : Le correction du bogue 23591953 a désactivé à la fois la surveillance de la Oracle VM Server for SPARC MIB, notamment la liste des objets de la Oracle VM Server for SPARC MIB obtenue avec la commande snmpwalk et la génération d'interruptions pour la table ldomHbaTable. En conséquence, la table ldomHbaTable de la Oracle VM Server for SPARC MIB n'affiche aucun contenu.
primary# snmpwalk -v1 -c public localhost SUN-LDOM-MIB::ldomHbaTable primary#
Solution de contournement : Utilisez la commande ldm list-hba pour afficher les informations sur les HBA.
Erreur Unable to Send Suspend Request signalée à tort lors d'une migration de domaine réussie
ID de bogue 23206413 : Dans quelques cas rares, une migration de domaine réussie renvoie l'erreur suivante :
Unable to send suspend request to domain domain-name
Ce problème se produit lorsque Logical Domains Manager détecte une erreur pendant la mise en suspens du domaine mais qu'il arrive à la réparer et à terminer la migration. L'état de sortie de la commande est 0, ce qui confirme le succès de la migration.
Solution de contournement : Comme la migration réussit, ce message d'erreur peut être ignoré.
La migration à froid d'un domaine lié comprenant un grand nombre de périphériques virtuels peut échouer et laisser deux copies liées du domaine
ID de bogue 23180427 : La migration à froid d'un domaine lié comprenant un grand nombre de périphériques virtuels peut échouer et générer le message d'erreur suivant dans le journal SMF :
warning: Timer expired: Failed to read feasibility response type (9) from target LDoms Manager
Cette panne indique que l'exécution de Logical Domains Manager sur la machine source a rencontré un dépassement de délai en attendant que le domaine soit lié sur la machine cible. Le risque que ce problème se produise augmente avec le nombre de périphériques virtuels dans le domaine à migrer.
Cette panne aboutit à la création d'une copie liée du domaine sur les machines source et cible. Ne démarrez pas les deux copies de ce domaine. Cela peut entraîner une corruption de données car les deux domaines font référence aux mêmes backends de disque virtuel.
Récupération : Après avoir vérifié que la copie du domaine migré est correcte sur la machine cible, dissociez manuellement la copie située sur la machine source et détruisez-la.
Echec de la migration lorsque la machine cible manque de canaux LDC libres
ID de bogue 23031413 : Lorsque le domaine de contrôle de la machine cible se trouve à court de canaux LDC pendant une migration de domaine, la migration échoue sans aucune explication et le message suivant est consigné dans le journal SMF :
warning: Failed to read feasibility response type (5) from target LDoms Manager
Cette erreur est générée lorsque le domaine en cours de migration n'arrive pas à se lier sur la machine cible. Notez que l'échec de l'opération de liaison sur la machine cible peut aussi être dû à d'autres raisons.
Solution de contournement : Pour que la migration réussisse, il faut réduire le nombre de canaux LDC dans le domaine à migrer ou dans le domaine de contrôle de la machine cible. Vous pouvez réduire le nombre de canaux LDC en réduisant le nombre de périphériques virtuels qui sont utilisés ou desservis par un domaine. Pour plus d'informations sur la gestion des canaux LDC, reportez-vous à la section Using Logical Domain Channels du manuel Guide d’administration d’Oracle VM Server for SPARC 3.5.
ovmtlibrary limite le nom de fichier d'image disque à 50 caractères
ID de bogue 23024583 : La commande ovmtlibrary limite le nom de fichier d'image disque à 50 caractères. ovmtlibrary vérifie le fichier .ovf et compare les informations de la section <ovf:References> aux noms de fichier réels des disques décompressés.
Une erreur est générée si les fichiers sont différents ou si le nom de fichier d'image disque comprend plus de 50 caractères. Par exemple :
# ovmtlibrary -c store -d "example" -q -o file:/template.ova -l /export/user1/ovmtlibrary_example event id is 3 ERROR: The actual disk image file name(s) or the actual number of disk image(s) is different from OVF file: template.ovf exit code: 1
L'exemple XML suivant illustre un nom de fichier d'image disque qui dépasse la limite des 50 caractères :
<ovf:References> <ovf:File ovf:compression="gzip" ovf:href="disk_image.ldoms3.5_build_s11_u3_sru15_01_kz_42G.img.gz" ovf:id="ldoms3" ovf:size="6687633773"/> </ovf:References>
Solution de contournement : Limitez la longueur des noms de fichier d'image disque à moins de 50 caractères.
Les périphériques réseau virtuels ajoutés à un domaine invité inactif n'obtiennent jamais la valeur par défaut de linkprop
ID de bogue 22842188 : Pour que linkprop=phys-state soit pris en charge sur un périphérique réseau virtuel, il faut que Logical Domains Manager soit capable de confirmer que le commutateur virtuel auquel ce périphérique est rattaché comprend une carte réseau (NIC) physique qui soutient le commutateur virtuel.
L'agent netsvc d'Oracle VM Server for SPARC doit être en cours d'exécution sur le domaine invité pour qu'il soit possible d'interroger le commutateur virtuel.
Si le domaine invité n'est pas actif et ne peut pas communiquer avec l'agent situé dans le domaine contenant le commutateur virtuel du périphérique réseau virtuel, la propriété linkprop=phys-state n'est pas définie pour ce périphérique réseau virtuel.
Solution de contournement : Ne définissez linkprop=phys-state que lorsque le domaine est actif.
Echec de ldm set-vsw net-dev= lorsque linkprop=phys-state
ID de bogue 22828100 : Si un commutateur virtuel est rattaché à des périphériques réseau configurés avec linkprop=phys-state, il doit avoir un périphérique NIC de sauvegarde valide, indiqué par la propriété net-dev. La valeur de la propriété net-dev doit être le nom d'un périphérique réseau valide.
Si cette action est effectuée à l'aide de net-dev=, le commutateur virtuel continue d'indiquer linkprop=phys-state même si la valeur de la propriété net-dev n'est pas un périphérique NIC valide.
Solution de contournement : Commencez par supprimer tous les périphériques réseau virtuels rattachés au commutateur virtuel, puis supprimez le commutateur virtuel. Ensuite, créez à nouveau le commutateur virtuel, avec un périphérique de sauvegarde net-dev valide, puis créez tous les périphériques réseau virtuels.
Impossible de recréer un domaine qui présente des contraintes de socket à partir d'un fichier XML
ID de bogue 21616429 : Le logiciel Oracle VM Server for SPARC 3.3 inclut la prise en charge des sockets pour les serveurs Fujitsu M12 et serveurs Fujitsu M10 uniquement.
Le logiciel exécuté sur les serveurs SPARC d'Oracle et les versions d'Oracle VM Server for SPARC antérieures à 3.3 ne peuvent pas recréer un domaine avec des contraintes de socket à partir d'un fichier XML.
Toute tentative de recréation d'un domaine avec des contraintes de socket à partir d'un fichier XML à l'aide d'une ancienne version du Oracle VM Server for SPARC ou sur un serveur SPARC d'Oracle échoue avec le message suivant :
primary# ldm add-domain -i ovm3.3_socket_ovm11.xml socket not a known resource
Si Oracle VM Server for SPARC 3.2 s'exécute sur un serveur Fujitsu M12 ou Serveur Fujitsu M10 et que vous tentez de recréer un domaine avec des contraintes de socket à partir d'un fichier XML, la commande échoue avec les différents types de messages d'erreur suivants :
primary# ldm add-domain -i ovm3.3_socket_ovm11.xml Unknown property: vcpus primary# ldm add-domain -i ovm3.3_socket_ovm11.xml perf-counters property not supported, platform does not have performance register access capability, ignoring constraint setting.
Solution de contournement : Modifiez le fichier XML pour supprimer les sections qui font référence au type de ressource socket.
Les zones de noyau bloquent la migration en direct des domaines invités
ID de bogue 21289174 : Sur un serveur SPARC, une zone de noyau en cours d'exécution au sein d'un domaine Oracle VM Server for SPARC bloque la migration en direct du domaine invité. Le message d'erreur suivant s'affiche :
Guest suspension failed because Kernel Zones are active. Stop Kernel Zones and retry.
Solution de contournement : Choisissez l'une des solutions suivantes :
Arrêtez l'exécution de la zone de noyau.
# zoneadm -z zonename shutdown
Suspendez la zone de noyau.
# zoneadm -z zonename suspend
Effectuez une migration en direct vers un autre système avant de migrer le domaine invité.
Reportez-vous au Chapitre 3, Migrating an Oracle Solaris Kernel Zone du manuel Creating and Using Oracle Solaris Kernel Zones.
Après dépose dans factory-default, le mode de récupération échoue si le système s'initialise à partir d'un périphérique différent de celui utilisé dans la configuration précédemment active
ID de bogue 20425271 : Lors du déclenchement d'une récupération après la dépose dans factory-default, le mode de récupération échoue si le système s'initialise depuis un autre périphérique que celui qui a été initialisé dans la configuration précédemment active. La panne peut se produire si la configuration active utilise un périphérique d'initialisation autre que factory-default.
Remarque - Ce problème concerne les serveurs des séries UltraSPARC T2, UltraSPARC T2 Plus, SPARC T3 et SPARC T4. Il peut également survenir sur les serveurs SPARC T5, SPARC M5 et SPARC M6 qui exécutent un microprogramme antérieur à la version 9.5.3.
Solution de contournement : Effectuez les étapes suivantes chaque fois que vous voulez enregistrer une nouvelle configuration vers le SP :
Déterminez le chemin d'accès complet vers le périphérique d'initialisation pour le domaine primary.
Utilisez ce chemin pour la commande ldm set-var exécutée à l'étape 4.
Supprimez toute propriété boot-device définie à partir du domaine primary.
Ces étapes ne sont nécessaires que si la propriété boot-device a une valeur définie. Si la propriété ne possède pas de valeur, toute tentative de suppression de la propriété boot-device renvoie un message boot-device not found.
primary# ldm rm-var boot-device primary
Enregistrez la configuration actuelle sur le SP.
primary# ldm add-spconfig config-name
Définissez explicitement la propriété boot-device du domaine primary.
primary# ldm set-var boot-device=value primary
Si vous définissez la propriété boot-device après l'enregistrement de la configuration sur le SP selon les instructions, le périphérique d'initialisation indiqué est initié lorsque le mode de récupération est déclenché.
Reprise : Si le mode de récupération a déjà échoué comme décrit, suivez les étapes ci-après :
Définissez explicitement le périphérique d'initialisation sur celui utilisé dans la dernière configuration en cours d'exécution.
primary# ldm set-var boot-device=value primary
Réinitialisez le domaine primary.
primary# reboot
La réinitialisation permet à la récupération de se poursuivre.
Les mises à jour du domaine invité eeprom sont perdues si l'opération ldm add-spconfig n'est pas terminée
ID de bogue 19932842 : Une tentative de configuration d'une variable OBP à partir d'un domaine invité risque d'échouer si vous utilisez la commande eeprom ou la commande OBP avant que l'une des commandes suivantes soit terminée :
ldm add-spconfig
ldm remove-spconfig
ldm set-spconfig
ldm bind
Ce problème peut se produire si ces commandes prennent plus de 15 secondes.
# /usr/sbin/eeprom boot-file\=-k promif_ldom_setprop: promif_ldom_setprop: ds response timeout eeprom: OPROMSETOPT: Invalid argument boot-file: invalid property
Reprise : Relancez la commande eeprom ou OBP une fois l'opération ldm terminée.
Solution de contournement : Relancez la commande eeprom ou OBP sur le domaine invité affecté. Vous pourriez éviter ce problème en utilisant la commande ldm set-var sur le domaine primary.
La réinitialisation d'un domaine invité comportant plus de 1 000 résultats de périphériques réseau virtuels provoque une panique
ID de bogue 19449221 : Un domaine ne peut pas avoir plus de 999 périphériques réseau virtuels (vnets).
Solution de contournement : Limitez le nombre de vnet d'un domaine à 999.
Chemin de périphérique incorrect pour les fonctions virtuelles Fibre Channel dans un domaine root
ID de bogue 18001028 : Dans le domaine root, le chemin de périphérique Oracle Solaris d'une fonction virtuelle Fibre Channel est incorrect.
Par exemple, le nom de chemin incorrect est pci@380/pci@1/pci@0/pci@6/fibre-channel@0,2, alors qu'il devrait être pci@380/pci@1/pci@0/pci@6/SUNW,emlxs@0,2.
La sortie ldm list-io -l présente le chemin de périphérique correct pour les fonctions virtuelles Fibre Channel.
Solution de contournement : Aucune.
Oracle Solaris 11.3 SRU 12 : les fonctions de pilote ssd et sd sont fusionnées pour les périphériques Fibre Channel sur les plates-formes SPARC
ID de bogue 17036795 : Le système d'exploitation Oracle Solaris 11.3 SRU 12 a fusionné les fonctions de pilote ssd et sd pour les périphériques Fibre Channel sur les plates-formes SPARC.
Cette modification affecte les noms de noeud de périphérique sur le chemin d'accès aux périphériques physiques. Les noms des noeuds de périphérique passent de ssd@ à disk@. Elle se répercute également sur les liaisons des pilotes de périphériques, qui passent de ssd à sd.
Remarque - Veillez à adapter les applications ou clients du système d'exploitation Oracle Solaris qui utilisent ces noms de noeud ou liaisons de pilote.
Cette modification n'est pas activée par défaut pour les systèmes Oracle Solaris 11.3.
Vous devez l'activer pour effectuer des migrations en direct de domaines utilisant des périphériques HBA et Fibre Channel virtuels.
Avant d'activer cette modification, assurez-vous que MPxIO est déjà activé en exécutant la commande stmsboot -D fp -e.
Exécutez la commande format pour déterminer si MPxIO est activé. Si c'est le cas, vhci doit apparaître dans les noms des périphériques. Sinon, si la sortie de la commande mpathadm -list lu est vide, aucun périphérique MPxIO n'est énuméré.
Exécutez la commande beadm pour créer un environnement d'initialisation. Les environnements d'initialisation vous permettent de rétablir facilement un environnement précédent en cas de problème inattendu.
Montez l'environnement d'initialisation et remplacez le fichier /etc/devices/inception_points par le fichier /etc/devices/inception_points.vhba. Le fichier .vhba contient des indicateurs de fonction qui permettent cette modification.
Enfin, redémarrez le système après avoir activé le nouvel environnement d'initialisation.
# beadm create BE-name # beadm mount BE-name /mnt # cp /mnt/etc/devices/inception_points.vhba /mnt/etc/devices/inception_points # beadm umount BE-name # beadm activate BE-name # reboot
Après le redémarrage, utilisez la commande prtconf -D | grep driver | grep sd pour vérifier le changement.
Si des disques utilisent le pilote ssd, c'est que la configuration présente un problème.
Vous pouvez aussi utiliser la commande mpathadm list lu pour afficher plusieurs chemins d'accès aux mêmes disques si le HBA virtuel et la fonction virtuelle FibreChannel sont tous deux configurés pour détecter les mêmes LUN.
Affichage de messages induisant en erreur pour les opérations de suppression SR-IOV InfiniBand
ID de bogue 16979993 : La tentative d'utiliser une opération de suppression SR-IOV dynamique sur un périphérique InfiniBand entraîne l'apparition de messages d'erreur peu clairs et inappropriés.
Les opérations de suppression SR-IOV dynamiques ne sont pas prises en charge pour les périphériques InfiniBand.
Solution de contournement : Supprimez les fonctions virtuelles InfiniBand en effectuant l'une des procédures suivantes :
La commande ldm migrate -n devrait échouer lors d'une migration entre CPU à partir d'un serveur SPARC T5, SPARC M5 ou SPARC M6 vers un serveur UltraSPARC T2 ou SPARC T3
ID de bogue 16864417 : La commande ldm migrate -n ne signale pas de défaillance lors d'une tentative de migration entre un serveur SPARC T5, SPARC M5 ou SPARC M6 et un serveur UltraSPARC T2 ou SPARC T3.
Solution de contournement : Aucune.
Un domaine d'E/S résilient doit prendre en charge les modifications apportées à la configuration des périphériques PCI après la réinitialisation du domaine root
ID de bogue 16691046 : Si des fonctions virtuelles sont affectées au domaine root, un domaine d'E/S risque de ne pas pouvoir fournir la résilience nécessaire aux situations d'enfichage à chaud suivantes :
Vous ajoutez un complexe root (bus PCIe) de manière dynamique au domaine root, puis vous créez les fonctions virtuelles et les affectez au domaine d'E/S.
Vous ajoutez à chaud une carte SR-IOV au domaine root propriétaire du complexe root, puis vous créez les fonctions virtuelles et les affectez au domaine d'E/S.
Vous remplacez ou ajoutez une carte PCIe (par enfichage à chaud ou lors de l'arrêt du domaine root) dans un emplacement vide du complexe root qui appartient au domaine root. Ce domaine root fournit des fonctions virtuelles au domaine d'E/S à partir du complexe root.
Solution de contournement : Effectuez l'une des étapes suivantes :
Si le complexe root fournit déjà des fonctions virtuelles au domaine d'E/S et que vous ajoutez, supprimez ou remplacez une carte PCIe sur ce complexe root (par enfichage à chaud ou lors de l'arrêt du domaine root), vous devez réinitialiser le domaine root et le domaine d'E/S.
Si le complexe root ne disposent pas de fonctions virtuelles actuellement affectées au domaine d'E/S et que vous ajoutez au complexe root une carte SR-IOV ou tout autre type de carte PCIe, vous devez arrêter le domaine root pour procéder à l'ajout. Une fois le domaine root réinitialisé, vous pouvez affecter des fonctions virtuelles au domaine d'E/S à partir de ce complexe root.
Si vous voulez ajouter un nouveau bus PCIe au domaine root, puis créer et affecter au domaine d'E/S des fonctions virtuelles à partir de ce bus, effectuez l'une des étapes suivantes, puis réinitialisez le domaine root :
Ajouter le bus au cours d'une reconfiguration retardée
Ajouter le bus de façon dynamique
Domaines invités en état de transition après la réinitialisation du domaine primary
ID de bogue 16659506 : Un domaine invité est en état de transition (t) après la réinitialisation du domaine primary. Ce problème se produit lorsqu'un grand nombre de fonctions virtuelles sont configurées sur le système.
Solution de contournement : Pour éviter ce problème, tentez à nouveau d'exécuter la commande d'initialisation des disques OBP plusieurs fois, ce qui permet d'éviter une initialisation à partir du réseau.
Accédez à la console du domaine.
primary# telnet localhost 5000
Définissez la propriété boot-device.
ok> setenv boot-device disk disk disk disk disk disk disk disk disk disk net
Le nombre d'entrées disk que vous indiquez en tant que valeur de la propriété boot-device dépend du nombre de fonctions virtuelles configurées sur le système. Sur les systèmes de moindre envergure, il se peut que vous puissiez inclure moins d'instances de disk dans la valeur de propriété.
Vérifiez à l'aide de la commande printenv que la propriété boot-device est correctement définie.
ok> printenv
Revenez à la console de domaine primary.
Répétez les étapes 1 à 4 pour chaque domaine sur le système.
Réinitialisez le domaine primary.
primary# shutdown -i6 -g0 -y
Procédez comme suit sur chaque domaine :
Le message WARNING: ddi_intr_alloc: cannot fit into interrupt pool signifie que l'approvisionnement d'interruptions est épuisé lorsque les pilotes de périphériques d'E/S ont été joints
ID de bogue 16284767 : Cet avertissement sur la console Oracle Solaris signifie que l'approvisionnement d'interruptions a été épuisé lorsque les pilotes de périphériques d'E/S ont été joints :
WARNING: ddi_intr_alloc: cannot fit into interrupt pool
Cette limitation concerne uniquement les systèmes SPARC pris en charge avant les serveurs SPARC M7 et les serveurs de la série SPARC T7.
Le matériel fournit un nombre défini d'interruptions, Oracle Solaris limite donc le nombre d'interruptions que chaque périphérique peut utiliser. Une limite par défaut est conçue pour répondre aux besoins des configurations système classiques. Cependant, cette limite peut nécessiter des ajustements pour certaines configurations système.
Plus précisément, la limite peut nécessiter des ajustements si le système est divisé en plusieurs domaines logiques et si un nombre trop important de périphériques d'E/S est assigné à un domaine invité. Oracle VM Server for SPARC divise le total des interruptions en ensembles plus petits assignés à des domaines invités. Si un nombre trop important de périphériques d'E/S est assigné à un domaine invité, ses approvisionnements risquent d'être trop faibles pour assigner à chaque périphérique la limite par défauts d'interruptions. Son approvisionnement s'épuise donc avant d'être entièrement associé à tous les pilotes.
Certains pilotes fournissent une routine de rappels facultatifs qui permet à Oracle Solaris d'ajuster automatiquement leurs interruptions. La limite par défaut ne s'applique pas à ces pilotes.
Solution de contournement : Utilisez les macros MDB ::irmpools and ::irmreqs pour déterminer l'utilisation des interruptions. La macro ::irmpools affiche l'approvisionnement global des interruptions divisées en pools. La macro ::irmreqs affiche les périphériques qui sont mappés vers chaque pool. Pour chaque périphérique, ::irmreqs affiche si la limite par défaut est appliquée par une routine de rappels facultatifs, le nombre d'interruptions demandées par chaque pilote et le nombre d'interruptions accordées au pilote.
Les macros n'affichent pas d'informations sur les pilotes qui n'ont pas pu être joints. Toutefois, les informations affichées permettent de calculer dans quelle mesure vous pouvez ajuster la limite par défaut. Un périphérique qui utilise plus d'une interruption sans fournir de routine de rappels peut être forcé d'utiliser moins d'interruptions en ajustant la limite par défaut. La réduction de la limite par défaut à un niveau inférieur à celui est utilisé par un tel périphérique peut se traduire par la libération d'interruptions en vue d'une utilisation par d'autres périphériques.
Pour ajuster la limite par défaut, définissez la propriété ddi_msix_alloc_limit sur une valeur comprise entre 1 to 8 dans le fichier /etc/system. Réinitialisez ensuite le système pour que la modification prenne effet.
Pour optimiser les performances, commencez par affecter de grandes valeurs et réduisez les valeurs par petits incréments jusqu'à la réussite de l'initialisation du système, sans avertissements. Utilisez les macros ::irmpools et ::irmreqs pour mesurer l'impact de l'ajustement sur tous les pilotes joints.
Par exemple, supposez que les avertissements suivants sont émis lors de l'initialisation du système d'exploitation Oracle Solaris dans un domaine invité :
WARNING: emlxs3: interrupt pool too full. WARNING: ddi_intr_alloc: cannot fit into interrupt pool
Les macros ::irmpools et ::irmreqs affichent les informations suivantes :
# echo "::irmpools" | mdb -k ADDR OWNER TYPE SIZE REQUESTED RESERVED 00000400016be970 px#0 MSI/X 36 36 36 # echo "00000400016be970::irmreqs" | mdb -k ADDR OWNER TYPE CALLBACK NINTRS NREQ NAVAIL 00001000143acaa8 emlxs#0 MSI-X No 32 8 8 00001000170199f8 emlxs#1 MSI-X No 32 8 8 000010001400ca28 emlxs#2 MSI-X No 32 8 8 0000100016151328 igb#3 MSI-X No 10 3 3 0000100019549d30 igb#2 MSI-X No 10 3 3 0000040000e0f878 igb#1 MSI-X No 10 3 3 000010001955a5c8 igb#0 MSI-X No 10 3 3
La limite par défaut dans cet exemple comporte huit interruptions par périphérique, ce qui n'est pas suffisant pour stocker la pièce jointe du périphérique emlxs3 sur le système. En supposant que toutes les instances emlxs se comportent de la même manière, emlxs3 a probablement demandé 8 interruptions.
En soustrayant les 12 interruptions utilisées par tous les périphériques igb de la taille totale du pool des 36 interruptions, 24 interruptions sont disponibles pour les périphériques emlxs. La division des 24 interruptions par 4 suggère que 6 interruptions par périphérique permettent à tous les périphériques emlxs de se joindre avec des performances égales. L'ajustement suivant est ainsi ajouté au fichier /etc/system :
set ddi_msix_alloc_limit = 6
Lorsque le système réussit à s'initialiser sans avertissement, les macros ::irmpools et ::irmreqs affichent les informations mises à jour suivantes :
# echo "::irmpools" | mdb -k ADDR OWNER TYPE SIZE REQUESTED RESERVED 00000400018ca868 px#0 MSI/X 36 36 36 # echo "00000400018ca868::irmreqs" | mdb -k ADDR OWNER TYPE CALLBACK NINTRS NREQ NAVAIL 0000100016143218 emlxs#0 MSI-X No 32 8 6 0000100014269920 emlxs#1 MSI-X No 32 8 6 000010001540be30 emlxs#2 MSI-X No 32 8 6 00001000140cbe10 emlxs#3 MSI-X No 32 8 6 00001000141210c0 igb#3 MSI-X No 10 3 3 0000100017549d38 igb#2 MSI-X No 10 3 3 0000040001ceac40 igb#1 MSI-X No 10 3 3 000010001acc3480 igb#0 MSI-X No 10 3 3
Serveur SPARC T5-8 : les données de temps de disponibilité affichent une valeur nulle pour certaines commandes de liste ldm
ID de bogue 16068376 : Sur un serveur SPARC T5-8 comprenant approximativement 128 domaines, certaines commandes ldm telles que ldm list peuvent afficher pour tous les domaines un temps de disponibilité de 0 seconde.
Solution de contournement : Connectez-vous au domaine et utilisez la commande uptime pour déterminer le temps de disponibilité du domaine.
ldm list -o status sur le domaine de contrôle indique une progression de migration incorrecte
ID de bogue 15819714 : Dans quelques rares circonstances, la commande ldm list -o status indique un pourcentage d'avancement incorrect lorsqu'elle est utilisée pour observer l'état d'une migration sur un domaine de contrôle.
Ce problème n'a aucune incidence sur le domaine en cours de migration ou sur les démons ldmd des domaines de contrôle source ou cible.
Solution de contournement : Exécutez la commande ldm list -o status de l'autre domaine de contrôle qui est impliqué dans la migration afin d'observer la progression.
La commande ldm init-system peut ne pas correctement restaurer une configuration de domaine sur lesquels des modifications d'E/S physiques ont été apportées
ID de bogue 15783031 : Vous risquez de rencontrer des problèmes lorsque vous utilisez la commande ldm init-system pour restaurer une configuration de domaine qui a utilisé des opérations d'E/S directes ou SR-IOV.
Un emplacement a été supprimé d'un bus qui est toujours la propriété du domaine primary.
Une fonction virtuelle a été créée à partir d'une fonction physique qui est la propriété du domaine primary.
Une fonction virtuelle a été assignée au domaine primary, à d'autres domaines invités, ou aux deux à la fois.
Un complexe root a été supprimé du domaine primary et a été assigné à un domaine invité, et ce complexe est utilisé en tant que base pour les opérations de virtualisation d'E/S supplémentaires.
En d'autres termes, vous avez créé le domaine root non primary et effectué l'une des opérations précédentes.
Un problème survient si une ou plusieurs des opérations suivantes ont été exécutées dans la configuration à restaurer :
Si vous avez effectué l'une des opérations précédentes, appliquez la solution de contournement indiquée dans Oracle VM Server for SPARC PCIe Direct I/O and SR-IOV Features (Doc ID 1325454.1) (https://support.oracle.com/epmos/faces/SearchDocDisplay?amp;_adf.ctrl-state=10c69raljg_77&_afrLoop=506200315473090).
Panique du domaine invité lors de l'exécution de la commande cputrack lors de l'une migration vers un serveur SPARC T4
ID de bogue 15776123 : Si la commande cputrack est exécutée sur un domaine invité pendant la migration vers un serveur SPARC T4, le domaine invité peut paniquer sur la machine cible après avoir été migré.
Solution de contournement : N'exécutez pas la commande cputrack durant la migration d'un domaine invité vers un serveur SPARC T4.
Limitation du nombre maximum de fonctions virtuelles qu'il est possible d'affecter à un domaine
ID de bogue 15775637 : un domaine d'E/S possède un nombre limité de ressources d'interruptions disponibles par complexe root.
Sur les serveurs SPARC T3 et SPARC T4, la limite est d'environ 63 vecteurs MSI/X. Chaque fonction virtuelle igb utilise trois interruptions. La fonction virtuelle ixgbe utilise deux interruptions.
Si vous affectez un grand nombre de fonctions virtuelles à un domaine, le domaine manque de ressources système pour prendre en charge ces périphériques. Des messages similaires au message suivant peuvent s'afficher :
WARNING: ixgbevf32: interrupt pool too full. WARNING: ddi_intr_alloc: cannot fit into interrupt pool
Une tentative de connexion à la console d'un domaine invité lié peut provoquer le blocage de la sortie
ID de bogue 15771384 : La console invitée d'un domaine est susceptible de se figer en cas de tentatives répétées pour vous connecter à la console avant et pendant l'opération de liaison de la console. Par exemple, ce problème peut se produire si vous utilisez un script automatisé pour saisir la console lorsqu'un domaine est en cours de migration sur la machine.
Solution de contournement : Pour débloquer la console, exécutez les commandes suivantes sur le domaine qui héberge le concentrateur de consoles du domaine (domaine de contrôle en règle générale) :
primary# svcadm disable vntsd primary# svcadm enable vntsd
Désactivation conseillée de l'option ldm remove-io des cartes PCIe possédant des ponts PCIe vers PCI
ID de bogue 15761509 : Utilisez uniquement les cartes PCIe prenant en charge la fonction d'E/S directes (DIO) qui sont répertoriées dans ce support document (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=REFERENCE&id=1325454.1).
Remarque - La fonctionnalité d'E/S directes est en phase d'abandon à partir des serveurs de série SPARC T7 et M7.
Solution de contournement : Utilisez la commande ldm add-io pour rajouter la carte au domaine primary.
Migration en direct d'un domaine dépendant d'un domaine maître inactif sur la machine cible entraînant l'erreur de la commande ldmd avec une erreur de segmentation
ID de bogue 15701865 : Si vous tentez une migration en direct d'un domaine dépendant d'un domaine inactif sur la machine cible, le démon ldmd échoue avec une erreur de segmentation et s'arrête brutalement. Le démon ldmd redémarre automatiquement, mais la migration est abandonnée.
Supprimez la dépendance invitée du domaine à migrer.
Démarrez le domaine maître sur la machine cible.
Solution de contournement : Effectuez l'une des actions suivantes avant de tenter la migration en direct :
La stratégie DRM et la sortie ldm list présentent un nombre de CPU virtuelles différent du nombre de CPU virtuelles réellement contenues dans le domaine invité
ID de bogue 15701853 : Le message No response peut s'afficher dans le journal de Oracle VM Server for SPARC lorsque la stratégie DRM d'un domaine chargé expire après une réduction significative du nombre de CPU. La sortie ldm list montre qu'il y a plus de ressources CPU affectées au domaine que celles affichées dans la sortie psrinfo.
Solution de contournement : Utilisez la commande ldm set-vcpu pour redéfinir le nombre de CPU du domaine sur la valeur présentée dans la sortie psrinfo.
Des opérations de migration simultanées dans des "directions opposées" risquent d'entraîner le blocage de ldm
ID de bogue 15696986 : Si deux commandes ldm migrate sont émises simultanément entre deux systèmes identiques dans des "directions opposées," elles risquent de se bloquer et de ne jamais aboutir. Une situation avec des directions opposées se présente lorsque vous démarrez simultanément une migration de la machine A vers la machine B ou une migration de la machine B vers la machine A.
Le blocage se produit même si les processus de migration sont initialisés en tant que simulations à l'aide de l'option –n. Lorsque ce problème se produit, toutes les autres commandes ldm risquent de se bloquer.
Reprise : Redémarrez Logical Domains Manager sur les machines source et cible :
primary# svcadm restart ldmd
Solution de contournement : Aucune.
Serveur SPARC T3-1 : problème lié aux disques accessibles via plusieurs chemins d'E/S directes
ID de bogue 15668368 : Un serveur SPARC T3-1 peut être installé avec des disques double port, lesquels peuvent être accessibles via deux périphériques d'E/S directes différents. Dans ce cas, l'assignation de ces périphériques d'E/S directes à des domaines différents entraîne parfois l'utilisation des disques par les deux domaines et une incidence mutuelle sur l'utilisation réelle de ces disques.
Solution de contournement : N'assignez pas des périphériques d'E/S directes ayant accès au même ensemble de disques sur différents domaines d'E/S. Pour déterminer si votre serveur SPARC T3-1 contient des disques à deux ports, exécutez la commande suivante sur le SP :
-> show /SYS/SASBP
Si la sortie contient la valeur fru_description, le système correspondant contient des disques double port :
fru_description = BD,SAS2,16DSK,LOUISE
Lorsque des disques double port sont présents dans le système, assurez-vous que les deux périphériques d'E/S directes suivants sont toujours assignés au même domaine :
pci@400/pci@1/pci@0/pci@4 /SYS/MB/SASHBA0 pci@400/pci@2/pci@0/pci@4 /SYS/MB/SASHBA1
L'exécution de la commande ldm stop -a sur des domaines participant à une relation maître-esclave laisse l'esclave avec l'indicateur défini sur stopping
ID de bogue 15664666 : Lorsqu'une relation de dépendance de réinitialisation est créée, la commande ldm stop -a peut entraîner le redémarrage au lieu de l'arrêt seul d'un domaine participant à une relation de dépendance de réinitialisation.
Solution de contournement : Exécutez d'abord la commande ldm stop pour le domaine maître. Exécutez ensuite la commande ldm stop pour le domaine esclave. Si l'arrêt initial du domaine esclave échoue, exécutez la commande ldm stop -f pour le domaine esclave.
La suppression dynamique de toutes les unités cryptographiques d'un domaine entraîne l'arrêt de SSH
ID de bogue 15600969 : Si toutes les unités cryptographiques matérielles sont supprimées de manière dynamique dans un domaine actif, la structure cryptographique ne peut pas recourir aux fournisseurs cryptographiques de logiciels sans erreur, et arrête l'ensemble des connexions ssh.
Ce problème ne concerne que les serveurs UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3.
Reprise : Rétablissez les connexions ssh après avoir supprimé les unités cryptographiques du domaine.
Solution de contournement : Définissez la propriété UseOpenSSLEngine=no du fichier /etc/ssh/sshd_config sur le côté serveur et exécutez la commande svcadm restart ssh.
Aucune des connexions ssh ne recourt plus aux unités cryptographiques matérielles (et ne tire donc plus parti des améliorations des performances qui y sont associées) et les connexions ssh ne sont plus arrêtées lorsque des unités cryptographiques sont supprimées.
Logical Domains Manager ne démarre pas si la machine n'est pas mise en réseau et qu'un client NIS est exécuté
ID de bogue 15518409 : Si vous ne disposez pas d'un réseau configuré sur votre machine et qu'un client NIS (Network Information Services, services d'information réseau) est actif, Logical Domains Manager ne démarre pas sur votre système.
Solution de contournement : Désactivez le client NIS sur la machine non mise en réseau :
# svcadm disable nis/client
Impossible de se connecter à la console d'un domaine migré sauf si le service vntsd est redémarré
ID de bogue 15513998 : Il arrive qu'il soit impossible de se connecter à la console d'un domaine qui vient d'être migré.
Ce problème se produit lorsque le domaine migré exécute une version du système d'exploitation antérieure à Oracle Solaris 11.3.
Solution de contournement : Redémarrez le service SMF vntsd pour activer les connexions à la console :
# svcadm restart vntsd
Remarque - Cette commande déconnecte toutes les connexions de console actives.
Une installation réseau simultanée de plusieurs domaines échoue lorsqu'il s'agit d'un groupe de consoles commun
ID de bogue 15453968 : Une installation réseau simultanée de plusieurs domaines invités échoue sur les systèmes ayant un groupe de consoles commun.
Solution de contournement : Procédez à une installation réseau uniquement sur des domaines invités ayant chacun leur propre groupe de consoles. Cette panne se rencontre uniquement sur les domaines ayant un groupe de consoles commun partagé entre plusieurs domaines à installation réseau.
Le comportement de la commande ldm stop-domain n'est pas toujours très clair
ID de bogue 15368170 : Dans certains cas, le comportement de la commande ldm stop-domain est déroutant.
# ldm stop-domain -f domain-name
Si le domaine est dans le débogueur du module noyau, avec l'invite kmdb(1), la commande ldm stop-domain échoue avec le message d'erreur suivant :
LDom <domain-name> stop notification failed
Problèmes identifiés dans la documentation
Cette section contient les problèmes et erreurs de documentation qui n'ont pas été identifiées à temps pour être modifiées dans cette version d'Oracle VM Server for SPARC 3.5.
Remarque - Les modifications décrites dans les errata suivants ont été apportées à la version anglaise du Oracle VM Server for SPARC 3.5 Reference Manual sur OTN.
Elles ne sont pas mentionnées dans les pages de manuel fournies avec le logiciel Oracle VM Server for SPARC 3.5 ni dans la version japonaise du Oracle VM Server for SPARC 3.5 Reference Manual on OTN.
ldmd(1M) : Description manquante de la propriété SMF ldmd/migration_adi_legacy_compat
La page de manuel ldmd(1M) ne contient pas la description suivante de la propriété SMF ldmd/migration_adi_legacy_compat :
- ldmd/migration_adi_legacy_compat
Specifies whether to permit a domain migration between servers that support Silicon Secured Memory (SSM) even if one of the machines does not have support for the migration of Application Data Integrity (ADI) version information that is introduced in Oracle VM Server for SPARC 3.5.
If both the source machine and the target machine are running the latest versions of the Oracle VM Server for SPARC software, you do not need to use this SMF property.
Mise en garde - If you intend to perform a domain migration on your servers that support SSM, it is best that they run at least the Oracle VM Server for SPARC 3.5 software. If this is not possible, take extreme caution when using the ldmd/migration_adi_legacy_compat SMF property. Improper use of this property can result in undefined application behavior if ADI is in use in the domain being migrated.
By default, the property value is false, which prevents a domain migration unless both the source machine and the target machine support SSM and run the required version of the Oracle VM Server for SPARC software. This property has no effect on servers that do not support SSM.
When the value is true, the domain migration proceeds without support for the migration of ADI version information.
So, if either the source machine or target machine runs a version of the Oracle VM Server for SPARC software that is older than 3.5, which does not support the migration of ADI version information, the migration is permitted.
You cannot upgrade both the source machine and target machine to a version of the Oracle VM Server for SPARC software that supports the migration of ADI version information
You know for certain that ADI versioning is not in use within the domain to be migrated
Only set the ldmd/migration_adi_legacy_compat SMF property value to true if both the following circumstances are true:
Setting this property to true permits migrations where ADI version information is not transferred to the target machine. This situation can result in undefined application behavior if ADI is in use in the domain being migrated.
The ldmd/migration_adi_legacy_compat SMF property is not recognized by Oracle VM Server for SPARC versions older than 3.5. Use of this property is applicable only on a source machine or a target machine is running at least Oracle VM Server for SPARC 3.5.
ldm(1M) : Description mise à jour de la sous-commande set-domain et de l'option –i
La page de manuel ldm(1M) contient les mises à jour suivantes :
Le premier paragraphe est désormais libellé comme suit :
The set-domain subcommand enables you to modify properties such as boot-policy, mac-addr, hostid, failure-policy, extended-mapin-space, master, and max-cores for a domain. You cannot use this command to update resources.
La description de l'option –i est désormais libellée comme suit :
–i file specifies the XML configuration file to use in setting the properties of the logical domain.
Only the ldom_info nodes specified in the XML file are parsed. Resource nodes, such as vcpu, mau, and memory, are ignored.
If the hostid property in the XML file is already in use, the ldm set-domain -i command fails with the following error:
Hostid host-ID is already in use
Before you re-run the ldm set-domain -i command, remove the hostid entry from the XML file.
ldm(1M) fait référence de façon incorrecte à la mémoire tampon de l'historique des commandes
La page de manuel ldm(1M) renvoie de façon incorrecte à une mémoire tampon d'historique des commandes que vous pouvez consulter avec la commande ldm list-history.
Les premier et deuxième paragraphes de la section Command History ont été mis à jour comme suit :
Use the ldm list-history command to view the Oracle VM Server for SPARC command history log. This log captures ldm commands and commands that are issued through the XMPP interface. By default, the number of commands shown by the ldm list-history command is ten.
To change the number of commands output by the ldm list-history command, use the ldm set-logctl command to set the history property value. If you set history=0, the saving of command history is disabled. You can re-enable this feature by setting the history property to a non-zero value.
La description de la propriété history dans la section Control Logging Operations a été mise à jour comme suit :
history=num specifies the number of commands output by the ldm list-history command. Setting the value to 0 disables the saving of command history.
La description de l'option –a dans la section View Logging Capabilities a été mise à jour comme suit :
–a shows the logging capability values for all logging types and the number of commands output by the ldm list-history command.