Cette section recense les problèmes d'ordre général et les bogues liés au logiciel Oracle VM Server for SPARC 3.4.
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é.
ID de bogue 23180427 : La migration 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.
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 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 Utilisation des canaux de domaines logiques du manuel Guide d’administration d’Oracle VM Server for SPARC 3.4.
ID de bogue 23026264 : A partir d'Oracle VM Server for SPARC 3.4, Logical Domains Manager prend en charge uniquement TLS v1.2 (ou version supérieure) pour les migrations de domaine sécurisées. Si le poste pair de la migration n'est pas capable d'utiliser TLS v1.2, la migration échoue en générant le message d'erreur suivant :
Failed to establish connection with ldmd(1m) on target: target Check that the 'ldmd' service is enabled on the target machine and that the version supports Domain Migration. Check that the 'xmpp_enabled' and 'incoming_migration_enabled' properties of the 'ldmd' service on the target machine are set to 'true' using svccfg(1M).
La migration de domaine n'est prise en charge qu'entre deux versions mineures consécutives du logiciel Oracle VM Server for SPARC. Ce problème n'affecte aucune des combinaisons prises en charge. Toutefois, le logiciel Oracle VM Server for SPARC exécuté sur le système d'exploitation Oracle Solaris 10 ne peut pas utiliser TLS v1.2 par défaut et il est incompatible pour la migration de domaine avec Oracle VM Server for SPARC 3.4.
ID de bogue 23025921 : La propriété boot-policy d'un domaine invité n'est pas conservée lorsque ce domaine est migré vers un système exécutant une version plus ancienne de Logical Domains Manager et ensuite migré vers un système exécutant Oracle VM Server for SPARC 3.4.
Le logiciel Oracle VM Server for SPARC 3.4 a introduit la propriété boot-policy pour prendre en charge la fonctionnalité Verified Boot. Les versions antérieures du logiciel Oracle VM Server for SPARC ne prennent pas en charge la propriété boot-policy, de sorte qu'elle est supprimée quand un domaine invité est migré depuis un système exécutant Oracle VM Server for SPARC 3.4 vers un système exécutant une version d'Oracle VM Server for SPARC inférieure à 3.4.
Lorsque le domaine invité est ultérieurement migré vers un système exécutant Oracle VM Server for SPARC 3.4, la valeur boot-policy par défaut warning est appliquée au domaine invité migré.
Récupération : Après avoir migré le domaine invité vers un système cible exécutant Oracle VM Server for SPARC 3.4, affectez manuellement à la propriété boot-policy la valeur désirée. Effectuez cette étape si la valeur par défaut warning ne convient pas.
Définissez boot-policy=none.
primary# ldm set-domain boot-policy=none ldg1
Réinitialisez l'invité pour que la nouvelle stratégie d'initialisation prenne effet.
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.
ID de bogue 20453206 : La migration peut échouer même en cas de mémoire suffisante dans une configuration valide du système cible. Les opérations de reconfiguration dynamique de la mémoire peuvent rendre plus compliquée la migration d'un domaine invité.
Solution de contournement : Aucune.
ID de bogue 17285751 : La migration d'un domaine invité Oracle Solaris 10 auquel une seule CPU virtuelle a été assignée peut provoquer une erreur grave sur le domaine invité dans la fonction pg_cmt_cpu_fini().
Ce problème a été corrigé dans le système d'exploitation Oracle Solaris 11.1.
Solution de contournement : Assignez au moins deux CPU virtuelles au domaine invité avant de procéder à la migration en direct. Par exemple, utilisez la commandeldm add-vcpu number-of-virtual-CPUs domain-name pour augmenter le nombre de CPU virtuelles assignées au domaine invité.
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.
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.
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.
ID de bogue 15775055 : Après la migration d'un domaine entre deux machines possédant des fréquences de CPU différentes; le temps de disponibilité signalé par la commande ldm list peut être incorrect. Ces résultats incorrects surviennent car le temps de disponibilité est calculé par rapport à la fréquence STICK de la machine sur laquelle le domaine est exécuté. Si la fréquence STICK diffère entre les machines source et cible, le temps de disponibilité apparaît incorrect à l'échelle.
Ce problème ne concerne que les serveurs UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3.
Le temps de disponibilité signalé et affiché par le domaine invité lui-même est correct. En outre, toute la comptabilisation effectuée par le SE Oracle Solaris dans le domaine invité est correcte.
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 le domaine de la machine cible est redémarré. Bien que la migration réussisse, le redémarrage inopiné du domaine migré sur la machine cible signifie qu'il ne s'agit pas d'une migration en direct.
Solution de contournement : Effectuez l'une des actions suivantes avant de tenter la migration en direct :
Supprimez la dépendance invitée du domaine à migrer.
Démarrez le domaine maître sur la machine cible.
ID de bogue 15701853 : Si vous effectuez une migration de domaine alors qu'une stratégie DRM est en vigueur et que, par la suite, la stratégie DRM expire ou est supprimée du domaine migré, DRM ne parvient pas à restaurer le nombre d'origine de CPU virtuelles sur le domaine.
Solution de contournement : Si un domaine est migré alors qu'une stratégie DRM est active, puis que cette dernière expire ou est supprimée, redéfinissez le nombre de CPU virtuelles. Utilisez la commande ldm set-vcpu pour définir le nombre de CPU virtuelles sur la valeur d'origine sur le domaine.
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.
Solution de contournement : Aucune.
ID de bogue 15527921 : Au cours d'une migration, le groupe de consoles et le port explicitement assignés sont ignorés, et une console avec les propriétés par défaut est créée pour le domaine cible. Cette console est créée en utilisant le nom du domaine cible comme groupe de consoles et un port disponible sur le premier concentrateur de console virtuelle (vcc) du domaine de contrôle. S'il y a un conflit avec le nom de groupe par défaut, la migration échoue.
Reprise : Pour restaurer les propriétés de la console explicite à la suite d'une migration, dissociez le domaine cible et définissez manuellement les propriétés souhaitées à l'aide de la commande ldm set-vcons.
ID de bogue 15523120 : Dans certaines situations, la migration échoue et la commande ldmd signale que la liaison de la mémoire nécessaire pour le domaine source est impossible. Cela peut se produire même si la quantité totale de mémoire disponible sur la machine cible est supérieure à celle utilisée par le domaine source.
Cet échec se produit car la migration de plages de mémoire spécifiques utilisées par le domaine source nécessite que des plages de mémoire compatibles soient également disponibles sur la cible. Si aucune plage de mémoire compatible n'est trouvée pour une plage de mémoire donnée dans la source, la migration échoue. Voir la section Configuration requise pour la mémoire du manuel Guide d’administration d’Oracle VM Server for SPARC 3.4.
Reprise : Si vous rencontrez ce problème, essayez de migrer le domaine en modifiant l'utilisation de la mémoire sur la machine cible. Pour ce faire, dissociez n'importe quel domaine logique actif sur la cible.
Exécutez la commande ldm list-devices -a mem pour déterminer la quantité de mémoire disponible et son utilisation. Envisagez également de réduire la quantité de mémoire assignée à un autre domaine.
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
Ce problème ne concerne que les serveurs UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3.
Les versions 8.4, 9.1 et XCP2230 du microprogramme système ont inclus pour la première fois la prise en charge des étiquettes de disque GPT EFI. Par défaut, les disques virtuels qui sont installés sur des systèmes exécutant le SE Oracle Solaris 11.1 ou une version ultérieure possèdent une étiquette de disque GPT EFI. Cette étiquette de disque n'est pas lisible sur les versions plus anciennes du microprogramme (telles que 9.0.x, 8.3, 7.x ou XCP2221). Cette situation vous empêche d'effectuer une migration en direct ou une migration à froid vers un système exécutant une version du microprogramme système ne prenant pas en charge GPT EFI. Notez que la migration à froid échoue également dans cette situation, qui est différente des restrictions précédentes.
Pour déterminer si votre disque virtuel dispose d'une étiquette de disque GPT EFI, exécutez la commande devinfo -i sur le périphérique brut. Les exemples suivants indiquent si le disque virtuel possède une étiquette de disque VTOC SMI ou GPT EFI .
Etiquette de disque VTOC SMI. Si votre disque virtuel possède une étiquette VTOC SMI, vous pouvez effectuer une migration vers le microprogramme, que celui-ci prenne en charge EFI ou non.
Cet exemple indique que le périphérique a une étiquette VTOC car la commande devinfo -i affiche des informations propres au périphérique .
# devinfo -i /dev/rdsk/c2d0s2 /dev/rdsk/c2d0s2 0 0 73728 512 2
Etiquette de disque GPT EFI. Si votre disque virtuel possède une étiquette de disque GTP EFI, vous pouvez uniquement effectuer une migration vers un microprogramme prenant en charge EFI.
Cet exemple indique que le périphérique a une étiquette GPT EFI car la commande devinfo -i signale une erreur .
# devinfo -i /dev/rdsk/c1d0s0 devinfo: /dev/rdsk/c1d0s0: This operation is not supported on EFI labeled devices
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.
ID de bogue 23205662 : En raison d'une limitation du pilote PSIF utilisé par certaines cartes InfiniBand, le pilote ne prend pas en charge les opérations IOV dynamiques telles que la création de fonction virtuelle. Cette limitation fait que le mode de récupération ne récupère pas les domaines root non primary qui comprennent des fonctions physiques utilisant le pilote PSIF. Les fonctions physiques ne deviennent jamais prêtes pour la création de fonctions virtuelles en raison de l'absence de prise en charge des opérations IOV dynamiques.
Solution de contournement : Ne créez pas de fonctions virtuelles sur des fonctions physiques InfiniBand qui utilisent le pilote PSIF dans les domaines root non primary.
ID de bogue 23170671 : Il arrive que les fonctions virtuelles et les fonctions physiques restent dans un état non valide après la création de fonctions virtuelles. Un domaine auquel une telle fonction virtuelle est assignée ne peut pas être lié. Si ce problème se produit pendant le mode de récupération, tout domaine d'E/S présentant des fonctions virtuelles en état INV échappe à la récupération.
Le journal ldmd contient des messages similaires à celui-ci pour la fonction IOVFC.PF1 :
Recreating VFs for PF /SYS/MB/PCIE2/IOVFC.PF0 in domain root_2 Recreating VFs for PF /SYS/MB/PCIE2/IOVFC.PF1 in domain root_2 Recreating VFs for PF /SYS/MB/NET2/IOVNET.PF0 in domain root_3 PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3) PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3) PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3) PF /SYS/MB/PCIE2/IOVFC.PF1 not ready (3)
Reprise : Si vous remarquez ce problème à temps, vous pouvez redémarrer l'agent ldmd dans le domaine root_2 pour le résoudre tant que le mode de récupération continue de réexécuter la fonction physique en cause. Le redémarrage de l'agent permet la récupération des domaines d'E/S qui utilisent des fonctions virtuelles de la fonction physique. Si vous ne remarquez pas le problème à temps, l'opération de récupération va se poursuivre, mais elle ne sera pas en mesure de récupérer les domaines d'E/S qui utilisent ces fonctions virtuelles.
ID de bogue 23144895 : Oracle VM Server for SPARC MIB indique uniquement la configuration par défaut d'usine pour la table des configurations de processeur de service (SP) (ldomSPConfigTable).
Solution de contournement : Pour afficher la liste complète des configurations de SP dans le système, utilisez la commande ldm list-spconfig ou l'interface XML list-spconfig.
Par exemple :
primary# ldm list-spconfig factory-default [next poweron] test_config
La commande XML list-spconfig renvoie le résultat suivant :
<cmd>
<action>list-spconfig</action>
<data version="3.0">
<Envelope>
<References/>
<Section>
<Item>
<rasd:OtherResourceType>spconfig</rasd:OtherResourceType>
<gprop:GenericProperty key="spconfig_name">factory-default</gprop:GenericProperty>
<gprop:GenericProperty key="spconfig_status">next</gprop:GenericProperty>
</Item>
</Section>
<References/>
<Section>
<Item>
<rasd:OtherResourceType>spconfig</rasd:OtherResourceType>
<gprop:GenericProperty key="spconfig_name">test_config</gprop:GenericProperty>
</Item>
</Section>
...
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.4_build_s11_u3_sru06_rti_02_kz_40G.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.
ID de bogue 22919488 : La commande ovmtcreate ne prend pas en charge la création de modèles à partir de domaines source où le vdsdev a le même nom pour plus d'un disque virtuel au sein du même domaine.
Ce problème a peu de chances de se produire parce que les domaines source comprenant plusieurs disques virtuels ont généralement des périphériques backend différents, avec par conséquent des noms de fichier différents. Toutefois, si la commande ovmtdeploy est utilisée avec un modèle qui a été créé à partir d'un domaine source où le vdsdev a le même nom pour plus d'un disque virtuel, elle échoue en générant un message d'erreur. Par exemple :
# ovmtdeploy -d ldg1 template.ova ERROR: pigz: //ldg1/resources/disk_image.ldoms3.4_build_s11_u3_sru05_rti_01_kz_36G.img.gz does not exist -- skipping FATAL: Failed to decompress disk image
Solution de contournement : Spécifiez des noms de fichier backend vdsdev différents pour les disques virtuels inclus dans le même domaine.
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.
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.
ID de bogue 21616429 : Le logiciel Oracle VM Server for SPARC 3.3 inclut la prise en charge des sockets pour les 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 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.
ID de bogue 21321166 : La capacité de traitement d'E/S est parfois ralentie lors de l'utilisation d'un chemin MPxIO vers un domaine de service hors ligne pour un HBA SCSI virtuel.
Solution de contournement : Désactivez le chemin vers le domaine de service hors ligne à l'aide de la commande mpathadm disable path jusqu'à la remise en service du domaine de service.
ID de bogue 21188211 : Si des numéros d'unité logique (LUN) sont ajoutés ou supprimés dans un réseau de stockage (SAN) virtuel après la reconfiguration d'un HBA SCSI virtuel, la commande ldm rescan-vhba n'affiche pas la nouvelle vue des LUN.
Solution de contournement : Supprimez puis rajoutez le HBA SCSI virtuel. Assurez-vous que les LUN sont visibles. Si les opérations de suppression et de rajout ne fonctionnent pas, vous devez réinitialiser le domaine invité.
ID de bogue 20876502 : Le retrait du câble SAN d'un domaine de service appartenant à une configuration de domaine invité MPxIO avec des HBA SCSI virtuels entraîne l'affichage de valeurs incorrectes dans la colonne d'état du chemin de la sortie de la commande mpathadm.
Solution de contournement : Branchez le câble SAN et exécutez la commande ldm rescan-vhba pour tous les HBA SCSI virtuels sur le domaine de service auquel le câble est rattaché. Après l'application de cette solution, le domaine invité doit reprendre l'exécution des opérations d'E/S.
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.
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.
ID de bogue 20046234 : Lorsqu'un HBA SCSI virtuel et un périphérique SR-IOV Fibre Channel peuvent afficher les mêmes LUN dans un domaine invité quand MPxIO est activé, une erreur grave risque de survenir. L'erreur grave survient si la carte SR-IOV Fibre Channel est supprimée du domaine invité, puis rajoutée.
Solution de contournement : Ne configurez pas de domaine invité à l'aide de SR-IOV Fibre Channel et d'un HBA SCSI virtuel lorsque MPxIO est activé.
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.
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.
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.
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 :
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
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.
Procédez comme suit sur chaque domaine :
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
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 SE 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
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.
ID de bogue 15812823 : Dans les cas où la mémoire restante est faible, les blocs de mémoire ne peuvent pas tous être utilisés pour l'opération de DR de la mémoire en raison d'espace mémoire insuffisant. Cependant, ces blocs de mémoire sont inclus dans l'espace de mémoire libre. La situation peut conduire à ce qu'une quantité moins importante que prévu soit ajoutée au domaine. Aucun message d'erreur n'apparaît lorsque cette situation se produit.
Solution de contournement : aucune.
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 problème survient si une ou plusieurs des opérations suivantes ont été exécutées dans la configuration à restaurer :
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.
Pour garantir que le système demeure dans un état dans lequel aucune des actions précédentes n'a eu lieu, consultez Using the ldm init-system Command to Restore Domains on Which Physical I/O Changes Have Been Made (https://support.oracle.com/epmos/faces/DocumentDisplay?id=1575852.1).
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
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
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.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1325454.1).
Solution de contournement : Utilisez la commande ldm add-io pour rajouter la carte au domaine primary.
ID de bogue 15759601 : Si vous émettez une commande ldm stop immédiatement après une commande ldm start, la commande ldm stop risque d'échouer avec l'erreur suivante :
LDom domain-name stop notification failed
Solution de contournement : Relancez la commande ldm stop.
ID de bogue 15748348 : Lorsque le domaine primary partage le coeur physique le plus bas (généralement 0) avec un autre domaine, toute tentative de définir la contrainte de coeur complet (whole-core) pour le domaine primary échoue.
Solution de contournement : Effectuez les opérations suivantes :
Déterminez le coeur lié le plus bas partagé par les domaines.
# ldm list -o cpu
Dissociez tous les threads de CPU du coeur le plus bas de tous les domaines autres que le domaine primary.
Par conséquent, les threads de CPU du coeur le plus bas ne sont pas partagés et sont disponibles pour être liés au domaine primary.
Définissez la contrainte whole-core en effectuant l'une des opérations suivantes :
Liez les threads de CPU au domaine primary et définissez la contrainte whole-core à l'aide de la commande ldm set-vcpu -c.
Utilisez la commande ldm set-core pour lier les threads de CPU et définissez la contrainte whole-core en une seule étape.
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.
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
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.
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.
ID de bogue 15572184 : Une commande ldm risque de mettre beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés. Si vous exécutez une commande ldm à ce stade, elle peut sembler se bloquer. Sachez que la commande ldm revient normalement, une fois que la tâche attendue est effectuée. Lorsque la commande revient, le système doit répondre normalement aux commandes ldm.
Solution de contournement : Evitez d'initialiser plusieurs domaines à la fois. Toutefois, si vous y êtes contraint, évitez d'exécuter d'autres commandes ldm tant que le système ne retourne pas à son état de fonctionnement normal. Par exemple, patientez environ deux minutes sur des serveurs Sun SPARC Enterprise T5140 et T5240 et environ quatre minutes sur le serveur Sun SPARC Enterprise T5440 Server ou Sun Netra T5440.
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
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.
ID de bogue 15370442 : L'environnement Logical Domains ne prend pas en charge la définition ou la suppression de clés d'initialisation de connexion WAN à partir du SE Oracle Solaris à l'aide de la commande ickey(1M). Toutes les opérations ickey échouent avec le message d'erreur suivant :
ickey: setkey: ioctl: I/O error
De plus, les clés d'initialisation via connexion WAN qui sont définies en utilisant le microprogramme OpenBoot sur des domaines logiques autres que le domaine de contrôle ne sont pas mémorisées après la réinitialisation du domaine. Sur ces domaines, les clés définies à partir du microprogramme OpenBoot sont valides uniquement pour un seul usage.
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
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.4.
La page de manuel ldm(1M) n'indique pas qu'il faut réinitialiser un domaine actif après avoir utilisé la commande ldm set-domain pour modifier la valeur de la propriété boot-policy.
La description de la propriété boot-policy a été mise à jour dans le paragraphe suivant :
Si le domaine est actif lorsque vous modifiez la valeur de boot-policy, vous devez le réinitialiser pour que la modification prenne effet.
En outre, le premier paragraphe de la section traitant de la définition des options de domaine mentionne désormais le nom de propriété boot-policy :
La sous-commande set-domain permet de modifier uniquement les propriétés boot-policy, mac-addr, hostid, failure-policy, extended-mapin-space, master et max-cores de chaque domaine. Vous ne pouvez pas utiliser cette commande pour mettre à jour les propriétés de ressources.
La page de manuel ldmd(1M) indique un nom de propriété SMF incorrect, à savoir ldmd/fj-ppar-dr-policy. Le nom correct est ldmd/fj_ppar_dr_policy.