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.
Remarque - Certains bogues décrits dans cette section ont été résolus depuis la version Oracle VM Server for SPARC 3.1. Les notes concernant ces bogues sont toutefois conservées pour les utilisateurs exécutant encore la version 3.1 d'Oracle VM Server for SPARC.
Bogues liés au logiciel Oracle VM Server for SPARC 3.2
rcm_daemon peut émettre un message sur la console durant une opération ldm remove-io
ID de bogue 20619894 : si le package system/management/hwmgmtd n'est pas installé, une opération de suppression de bus dynamique fait en sorte que le rcm_daemon imprime le message suivant sur la console :
rcm_daemon[839]: rcm script ORCL,pcie_rc_rcm.pl: svcs: Pattern 'sp/management' doesn't match any instances
Solution de contournement : vous pouvez ignorer ce message en toute sécurité.
Le mode récupération peut se bloquer si la stratégie de gestion de l'alimentation est définie sur elastic
ID de bogue 20570207 : quand la stratégie de gestion de l'alimentation est définie sur elastic, le domaine primary peut se bloquer alors que Logical Domains Manager récupère des domaines après avoir détecté des ressources manquantes ou défectueuses.
Récupération : modifiez la stratégie sur disabled, puis arrêtez et redémarrez le système pour redémarrer en mode de récupération.
Comportement inattendu lorsque les commandes de socket Serveurs Fujitsu M10 sont utilisées lors de la reconfiguration retardée
ID de bogue 20432421 : si vous utilisez la commande grow-socket ou shrink-socket pour modifier des CPU virtuelles ou des coeurs lors d'une reconfiguration retardée, un comportement inattendu peut s'ensuivre. La mémoire appartenant au domaine primary est réaffectée de sorte que seule la mémoire du socket indiqué est liée au domaine.
Solution de contournement :ne modifiez que les coeurs et CPU virtuels à l'aide des commandes shrink-socket et grow-socket lorsqu'ils ne sont pas en reconfiguration retardée.
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
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 : appliquez les étapes suivantes à chaque fois que vous souhaitez 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é.
Récupération : 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.
ldm list-rsrc-group affiche les informations des bus PCIe dans le mauvais groupe de ressources
ID de bogue 20426593 : La commande ldm list-rsrc-group peut afficher des informations liées aux ressources d'E/S dans le mauvais groupe lorsque le suffixe numérique du nom du groupe de ressources contient plus d'un chiffre.
Dans l'exemple suivant, la commande ldm list-rsrc-group affiche bien les informations correctes relatives aux bus PCIe, pour /SYS/CMIOU10 dans le groupe de ressources /SYS/CMIOU1.
primary# ldm list-io
NAME TYPE BUS DOMAIN STATUS
---- ---- --- ------ ------
..
/SYS/CMIOU10/PCIE2 PCIE pci_50 primary OCC
/SYS/CMIOU10/PCIE3 PCIE pci_51 primary OCC
/SYS/CMIOU10/PCIE1 PCIE pci_53 primary OCC
..
.
primary# ldm list-rsrc-group -l -o io /SYS/CMIOU1
NAME
/SYS/CMIOU1
IO
DEVICE PSEUDONYM BOUND
pci@305 pci_5 alt-root
pci@306 pci_6 primary
pci@308 pci_8 alt-root
pci@309 pci_9 primary
pci@332 pci_50 primary
pci@333 pci_51 primary
pci@335 pci_53 primary
Les bus PCIe pci_50, pci_51 et pci_53 s'affichent à tort dans le groupe de ressources /SYS/CMIOU1 et non /SYS/CMIOU10.
Solution de contournement : exécutez la commande ldm list-io -l pour obtenir le nom de groupe de ressources correspondant bien au bus PCIe à partir du nom d'E/S. Par exemple, le bus PCIe avec le nom d'E/S /SYS/CMIOU10/PCIE2 doit appartenir à /SYS/CMIOU10 et non à /SYS/CMIOU1.
Le mode de récupération ne récupère pas le domaine invité quand le backend du disque virtuel est indisponible dans le domaine de service
ID de bogue 20321459 : si un backend virtuel manquant ne peut pas être validé, Logical Domains Manager ne récupère pas le domaine invité affecté au backend. Ce cas se vérifie, même lorsque la fonctionnalité de chemins d'accès multiples est configurée.
Solution de contournement : effectuez les opérations suivantes :
Désactivez temporairement la validation du périphérique.
primary# svccfg -s ldmd setprop ldmd/device_validation integer: 0 primary# svcadm refresh ldmd primary# svcadm restart ldmd
Récupérez les domaines invités manquants manuellement dans le backend.
Notez que lorsque le périphérique est désactivée, l'Logical Domains Manager ajoute un périphérique virtuel à un domaine invité, même si le backend ou le périphérique réseau physique associé n'existe pas. Ainsi, assurez-vous de réactiver la validation du périphérique une fois que vous avez récupéré la configuration de domaine.
primary# svccfg -s ldmd setprop ldmd/device_validation integer: -1 primary# svcadm refresh ldmd primary# svcadm restart ldmd
La commande ldm bind génère une erreur Invalid response
ID de bogue 20307560 : si vous créez un domaine invité qui utilise un certain nombre de CPU virtuelles et n'importe quelle quantité de mémoire, et que vous exécutiez la commande ldm bind, cette dernière peut générer une erreur Invalid response. Cette erreur peut se produire si le domaine primary a toutes les ressources avant la création du domaine invité et l'exécution de la commande ldm bind.
Solution de contournement : supprimez de la mémoire du domaine primary, puis exécutez la commande ldm bind.
La fonction physique ou virtuelle est bloquée à l'état INV en configuration retardée et lorsque Logical Domains Manager est redémarré
ID de bogue 20257979 : l'une des méthodes de création des fonctions virtuelles à partir d'une fonction physique consiste à placer le domaine root propriétaire de la fonction physique en reconfiguration retardée. En reconfiguration différée, vous pouvez créer une ou plusieurs fonctions virtuelles à l'aide de la commande ldm create-vf.
En général, une commande ldm list-io montre que la fonction physique et ses fonctions virtuelles enfant ont un état correct. Toutefois, si le service ldmd est redémarré avant la réinitialisation du domaine root, ou si la reconfiguration retardée est annulée, la fonction physique et ses fonctions virtuelles sont représentées à l'aide de l'état INV.
Le même problème se produit lorsque des fonctions virtuelles sont supprimées en reconfiguration retardée. Lors de la destruction des fonctions virtuelles, le redémarrage de Logical Domains Manager, puis l'exécution de la sortie ldm list-io n'affichent pas de fonctions physiques pour le domaine root.
Solution de contournement : effectuez l'une des opérations suivantes :
Annulez la reconfiguration retardée.
Lorsque vous exécutez une commande ldm list-io, la fonction physique et ses fonctions virtuelles existantes ont un état valide.
Réinitialisez le domaine root qui était en reconfiguration retardée.
Notez que les modifications que vous avez effectuées pendant que le domaine root était en reconfiguration retardée figurent dans la SE sur le domaine invité.
Les CPU ne sont pas relancées lorsque le plafonnement de la consommation énergétique est inférieur à la limite
ID de bogue 20187197 : si le plafonnement de la consommation énergétique est activé, il est impossible d'atteindre l'état d'alimentation le plus bas. L'état d'alimentation a été abaissé, mais pas au maximum. Lorsque cette situation se produit, l'état d'alimentation le plus élevé peut ne pas être repris après la définition d'une limite énergétique garantissant l'état de l'alimentation le plus élevé.
Cette situation se produit lors de la définition d'un nouveau plafonnement de la consommation énergétique proche de la limite énergétique maximale pour le système, ou encore lors de la définition d'un nouveau plafonnement de la consommation énergétique pour lequel la différence entre l'énergie réelle (sans plafonnement) et la nouvelle limite entraînerait l'utilisation de l'état d'alimentation le plus bas.
Solution de contournement : effectuez l'une des opérations suivantes :
Désactivez le plafonnement de la consommation énergétique
Définissez un nouveau plafonnement de la consommation énergétique de taille réduite, ou qui ne soit pas proche de la limite énergétique minimale du système.
Les noeuds ixgbevf sur un domaine d'E/S sont signalés comme étant désactivés par la commande ipadm et comme non existants par la commande ifconfig
ID de bogue 20004281 :quand un domaine primary est mis sous tension, les noeuds ixgbevf sur un domaine d'E/S peuvent être signalés comme étant désactivés par la commande ipadm et comme non existants par la commande ifconfig.
Solution de contournement : réactivez les interfaces IP :
# svcadm restart network/physical:default
Les interfaces HGXE sont inutilisables si elles sont affectées à l'aide d'une E/S directe vers un domaine d'E/S
ID de bogue 19943809 : le pilote hxge ne peut pas utiliser d'interfaces dans un domaine d'E/S quand la carte est attribuée en utilisant la fonctionnalité d'E/S directe.
L'avertissement suivant s'affiche dans le fichier journal du système :
WARNING: hxge0 : <== hxge_setup_mutexes: failed 0x1
Solution de contournement : ajoutez la ligne suivante à /etc/system, puis réinitialisez :
set px:px_force_intx_support=1
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
Récupération : 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 pourrez éviter le problème en à l'aide de la commande ldm set-var du 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.
Oracle VM Server for SPARC ne garde plus la trace des adresses MAC libérées
ID de bogue 19078763 : Oracle VM Server for SPARC ne garde plus la trace des adresses MAC libérées. Les adresses MAC sont à présent allouées par la sélection au hasard d'une adresse, puis par la confirmation que cette dernière n'est utilisée par aucun domaine logique du réseau local.
Le microprogramme des cartes Sun Storage 16 Gb Fibre Channel Universal HBA ne prend pas en charge les contrôles de la bande passante
ID de bogue 18083904 : le microprogramme des cartes Sun Storage 16 Gb Fibre Channel Universal HBA, Emulex ne prend pas en charge la configuration des contrôles de la bande passante. Le microprogramme du HBA ignore les valeurs que vous indiquez pour la propriété bw-percent.
Solution de contournement : aucune.
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.
Des problèmes peuvent survenir lorsque l'architecture FMA détecte de la mémoire défectueuse
ID de bogue 17576087 : l'arrêt et le redémarrage du système vers une configuration enregistrée risque de ne pas restaurer la mémoire après le remplacement de la mémoire défectueuse.
Solution de contournement : après le remplacement de la mémoire défectueuse, arrêtez et redémarrez le système vers la configuration factory-default. Ensuite, effectuez un cycle d'alimentation du système vers la configuration que vous souhaitez utiliser.
DLMP ne fonctionne pas dans un domaine invité sur un périphérique réseau virtuel ou une fonction virtuelle SR-IOV
Vous ne pouvez pas configurer un groupement DLMP sur une fonction virtuelle SR-IOV NIC ou un périphérique réseau virtuel dans un domaine invité.
Impossible d'installer le SE Oracle Solaris 11.1 à l'aide d'une étiquette de disque GPT EFI sur un disque virtuel à tranche unique.
ID de bogue 17422973 : l'installation du SE Oracle Solaris 11.1 sur un disque à tranche unique risque d'échouer avec l'erreur suivante sur un serveur SPARC T4 exécutant au moins la version 8.4.0 du microprogramme du système ou sur un serveur SPARC T5, SPARC M5 ou SPARC M6 exécutant au moins la version 9.1.0 du microprogramme du système, ou sur un Serveur Fujitsu M10 exécutant au moins la version 2230 de XCP ou une version ultérieure :
cannot label 'c1d0': try using fdisk(1M) and then provide a specific slice Unable to build pool from specified devices: invalid vdev configuration
Solution : renommez le disque avec un étiquette SMI.
La configuration enregistrée automatiquement n'est pas mise à jour après la suppression d'une fonction virtuelle ou d'un périphérique PCIe
ID de bogue 17051532 : lorsqu'un périphérique PCIe ou une fonction virtuelle est supprimé d'un domaine invité, la configuration enregistrée automatiquement n'est pas mise à jour. Ce problème peut entraîner la réapparition du périphérique ou de fonction virtuelle dans le domaine invité une fois l'enregistrement automatique récupéré, à savoir autorecovery_policy=3. Ce problème peut également entraîner l'échec de la commande ldm add-spconfig -r et l'affichage du message Autosave configuration config-name is invalid si vous n'exécutez pas une autre commande ldm déclenchant la mise à jour de l'enregistrement automatique.
Solution de contournement : effectuez l'une des opérations suivantes :
Enregistrez une nouvelle configuration une fois que vous avez supprimé le périphérique PCIe ou la fonction virtuelle.
primary# ldm add-config new-config-name
Actualisez la configuration enregistrée suite à la suppression du périphérique PCIe ou de la fonction virtuelle en supprimant puis en recréant la configuration.
primary# ldm rm-config config-name primary# ldm add-config config-name
Notez que ce bogue empêche le bon fonctionnement de la commande ldm add-config -r config-name.
Exécutez une autre commande ldm qui entraîne une mise à jour de l'enregistrement automatique telle que ldm set-vcpu, ldm bind ou ldm unbind.
Panique de domaine invité à lgrp_lineage_add(mutex_enter: bad mutex, lp=10351178)
ID de bogue 17020950 : après la migration d'un domaine actif à partir d'une plate-forme SPARC T4 vers une plate-forme SPARC T5, SPARC M5 ou SPARC M6 liée à l'aide de la version 8.3 du microprogramme, une opération de reconfiguration dynamique peut entraîner la panique d'un domaine invité.
Solution de contournement : avant d'effectuer la migration, mettez à jour le système SPARC T4 avec la version 8.4 du microprogramme système. Ensuite, associez à nouveau le domaine.
Domaines invités en état de transition après la réinitialisation du domaine primary
ID de bogue 17020481 : 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 mode de récupération devrait prendre en charge la suppression d'emplacements PCIe dans les domaines root non primary
ID de bogue 16713362 : à l'heure actuelle, les emplacements PCIe ne peuvent pas être supprimés des domaines root non primary pendant une opération de récupération. Les emplacements PCIe restent assignés au domaine root non primary.
Solution de contournement : les emplacements PCIe doivent être supprimés manuellement à partir du domaine root non primary et assignés au(x) domaine(s) d'E/S approprié(s) une fois l'opération de récupération terminée.
Pour plus d'informations sur la suppression d'emplacements PCIe à partir d'un domaine root non primary, reportez-vous à la section Présentation des domaines root non primary du manuel Guide d’administration d’Oracle VM Server for SPARC 3.2 .
La récupération de domaines d'E/S qui utilisent des emplacements PCIe détenus par des domaines root non primary dépend de la configuration des domaines d'E/S concernés :
Si le domaine d'E/S n'utilise que des emplacements PCIe et qu'aucun de ses emplacements PCIe n'est disponible, il n'est pas récupéré et est laissé dans l'état dissocié, les emplacements PCIe étant marqués comme évacués.
Si le domaine d'E/S utilise les fonctions virtuelles SR-IOV ainsi que les emplacements PCIe, le domaine est récupéré et les emplacements PCIe indisponibles sont marqués comme évacués.
Utilisez la commande ldm add-io pour ajouter les emplacements PCIe à un domaine d'E/S une fois que vous les avez supprimés manuellement du domaine root non primary.
ldm list n'affiche pas la propriété evacuated pour les périphériques d'E/S physiques
ID de bogue 16617981 : la sortie ldm list n'affiche pas la propriété evacuated pour les périphériques d'E/S physiques.
Solution de contournement : utilisez l'option –p avec n'importe laquelle des commandes ldm list afin d'afficher la propriété evacuated pour les périphériques d'E/S physiques.
La panique send_mondo_set: timeout se produit en cas d'utilisation de la commande ldm stop sur un domaine invité soumis à une charge de travail importante
ID de bogue 16486383 : ce problème peut se produire si vous affectez directement un périphérique ou bus PCI à un domaine invité auquel aucun coeur n'a été attribué à partir du /SYS/DCU où la carte PCI réside physiquement. Etant donné que l'hyperviseur réinitialise les périphériques PCI pour le compte des domaines invités, il est possible qu'au cours de chaque réinitialisation de domaine invité, un domaine comportant des coeurs sur le DCU connecté au périphérique PCI panique. Lorsque plusieurs périphériques PCI sont affectés à des invités non-DCU-local, le risque de panique augmente.
Solution de contournement : effectuez l'une des opérations suivantes :
Assurez-vous que lorsque vous affectez des périphériques PCI à un domaine invité, la carte se trouve physiquement dans le même DCU que les coeurs.
Affectez manuellement les coeurs afin de disposer d'une certaine flexibilité pour le placement de la carte.
Par exemple, pour un périphérique PCI sur IOU0 (pci_0 à pci_15), choisissez un coeur entre 0 et 127 et allouez-le au domaine.
# ldm add-core cid=16 domain-name
Visualisez les coeurs du système à l'aide de la commande suivante :
# ldm ls-devices -a core
Pour un périphérique PCI sur IOU1 (pci_16 à pci_31), choisissez un coeur entre 128 et 255. Pour un périphérique PCI sur IOU2 (pci_32 à pci_47), choisissez un coeur entre 256 et 383. Pour un périphérique PCI sur IOU3 (pci_48 à pci_63), choisissez un coeur entre 384 et 511.
Des sous-périphériques subordonnés à un périphérique PCIe retournent à l'état "sans nom"
ID de bogue 16299053 : lorsque vous désactivez un périphérique PCIe, un comportement inattendu peut s'ensuivre. Les sous-périphériques subordonnés au périphérique PCIe désactivé retournent à l'état "sans nom" tandis que le périphérique PCIe est toujours la propriété du domaine.
Solution de contournement : si vous décidez de désactiver un emplacement PCIe sur ILOM, assurez-vous que l'emplacement PCIe n'est pas affecté à un domaine à l'aide de la fonction d'E/S directes (DIO). En d'autres termes, assurez-vous d'abord que l'emplacement PCIe est affecté au domaine root correspondant avant de désactiver l'emplacement sur ILOM.
Si vous désactivez l'emplacement PCIe sur ILOM alors que l'emplacement PCIe est affecté à un domaine avec DIO, arrêtez le domaine concerné et réaffectez le périphérique au domaine root pour que le comportement soit normal.
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
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
SPARC M5-32 et SPARC M6-32 : problème lié aux disques accessibles via plusieurs chemins d'E/S directs
ID de bogue 16232834 : lorsque vous utilisez la commande ldm add-vcpu pour assigner des CPU à un domaine, le SE Oracle Solaris peut paniquer avec affichage du message suivant :
panic[cpu16]/thread=c4012102c860: mpo_cpu_add: Cannot read MD
Des DCU supplémentaires ont été attribués à un hôte
L'hôte est démarré à l'aide d'une configuration SP précédemment enregistrée qui ne contient pas tout le matériel attribué à l'hôte.
Cette panique se produit dans les cas suivants :
Le domaine cible de l'opération ldm add-vcpu est le domaine qui panique. Le domaine est récupéré avec les CPU supplémentaires lors de la réinitialisation.
Solution de contournement : n'utilisez pas des configurations générées avec un nombre de ressources matérielles moindre que celui affecté à l'hôte.
Afin d'éviter ce problème, n'ajoutez pas de CPU selon la procédure détaillée dans la description du problème. Ou effectuez les opérations suivantes :
Générez une nouvelle configuration de processeur de service après l'ajout des DCU.
Par exemple, la commande suivante crée une configuration nommée new-config-more-dcus :
primary# ldm add-config new-config-more-dcus
Arrêtez le domaine.
Arrêtez l'hôte.
-> stop /HOST
Démarrez l'hôte.
-> start /HOST
Le périphérique ixgbevf des domaines SR-IOV risque d'être désactivé après la réinitialisation du domaine primary
ID de bogue 16224353 : après avoir réinitialisé le domaine primary, les instances ixgbevf du domaine primary risquent de ne pas fonctionner.
Solution de contournement : aucune.
Après la réinitialisation du domaine primary d'Oracle Solaris 10 1/13, une interface de fonction virtuelle risque de ne pas être automatiquement raccordée ou de ne pas se voir attribuer d'adresse IP
ID de bogue 16219069 : sur un domaine primary exécutant le SE Oracle Solaris 10 1/13, les interfaces de fonction virtuelle risquent de ne pas être automatiquement raccordées ou de ne pas se voir attribuer d'adresse IP sur la base du fichier /etc/hostname.vf-interface.
Ce problème se produit lorsque vous initialisez ou réinitialisez un système SPARC T3, SPARC T4 ou SPARC T5 exécutant le SE Oracle Solaris 10 1/13 sur le domaine primary. Ce problème affecte les fonctions virtuelles créées sur les fonctions physiques intégrées et sur les fonctions physiques additionnelles. Ce problème ne se produit pas lorsque vous initialisez une image de domaine invité Logical Domains.
Oracle Solaris 10 uniquement : mutex_enter: bad mutex panique dans le domaine primary lors de la réinitialisation ou de l'arrêt
ID de bogue 16080855 : lors d'une réinitialisation ou d'un arrêt du domaine primary, le domaine primary peut subir une panique du noyau avec un message semblable au suivant :
panic[cpu2]/thread=c40043b818a0: mutex_enter: bad mutex, lp=c4005fa01c88 owner=c4005f70aa80 thread=c40043b818a0 000002a1075c3630 ldc:ldc_mem_rdwr_cookie+20 (c4005fa01c80, c4004e2c2000,2a1075c37c8, 6c80000, 1, 0) %l0-3: 00000000001356a4 0000000000136800 0000000000000380 00000000000002ff %l4-7: 00000000001ad3f8 0000000000000004 00000000ffbffb9c 0000c4005fa01c88 000002a1075c3710 vldc:i_vldc_ioctl_write_cookie+a4 (c4004c400030, 380,ffbff898, 100003, 0, 70233400) %l0-3: 0000000006c80000 0000000000156dc8 0000000000000380 0000000000100003 %l4-7: 00000000702337b0 000002a1075c37c8 0000000000040000 0000000000000000 000002a1075c37f0 vldc:vldc_ioctl+1a4 (3101, c4004c400030, ffbff898,c4004c400000, c4004c438030, 0) %l0-3: 0000000000100003 0000000000000000 000000007b340400 0000c4004c438030 %l4-7: 0000c4004c400030 0000000000000000 0000000000000000 0000000000000000 000002a1075c38a0 genunix:fop_ioctl+d0 (c4004d327800, 0, ffbff898, 100003,c4004384f718, 2a1075c3acc) %l0-3: 0000000000003103 0000000000100003 000000000133ce94 0000c4002352a480 %l4-7: 0000000000000000 0000000000000002 00000000000000c0 0000000000000000 000002a1075c3970 genunix:ioctl+16c (3, 3103, ffbff898, 3, 134d50, 0) %l0-3: 0000c40040e00a50 000000000000c6d3 0000000000000003 0000030000002000 %l4-7: 0000000000000003 0000000000000004 0000000000000000 0000000000000000
Reprise : autorisez le domaine primary à se réinitialiser. Si le domaine primary est configuré pour ne pas se réinitialiser après un arrêt brutal, initialisez-le manuellement.
SPARC M5-32 et SPARC M6-32 : le contrôleur LSI-SAS est exporté de façon incorrecte avec SR-IOV
ID de bogue 16071170 : sur un système SPARC M5-32 ou SPARC M6-32, les contrôleurs SAS internes sont exportés en tant que contrôleurs SR-IOV bien que ces cartes ne prennent pas en charge SR-IOV.
Le journal d'Oracle VM Server for SPARC consigne les messages suivants lors de la tentative de création de la fonction physique sur ces cartes :
Dec 11 04:27:54 warning: Dropping pf pci@d00/pci@1/pci@0/pci@0/pci@0/pci@4/LSI,sas@0: no IOV capable driver Dec 11 04:27:54 warning: Dropping pf pci@d80/pci@1/pci@0/pci@c/pci@0/pci@4/LSI,sas@0: no IOV capable driver Dec 11 04:27:54 warning: Dropping pf pci@c00/pci@1/pci@0/pci@c/pci@0/pci@4/LSI,sas@0: no IOV capable driver Dec 11 04:27:54 warning: Dropping pf pci@e00/pci@1/pci@0/pci@0/pci@0/pci@4/LSI,sas@0: no IOV capable driver
Le système est doté de quatre ports de contrôleur SAS LSI, chacun situé dans un IOU de l'assemblage SPARC M5-32 et SPARC M6-32. Cette erreur est signalée pour chaque port.
Solution de contournement : vous pouvez ignorer ces messages. Ces messages indiquent seulement que les contrôleurs SAS LSI du système sont compatibles avec SR-IOV, mais qu'aucune prise en charge de SR-IOV n'est disponible pour ce matériel.
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 système T5-8 comprenant approximativement 128 domaines, certaines commandes ldm telles que ldm list peuvent afficher 0 seconde comme temps de disponibilité de tous les domaines.
Solution de contournement : connectez-vous au domaine et utilisez la commande uptime pour déterminer le temps de disponibilité du domaine.
ldm ne parvient pas à évacuer un coeur défectueux d'un domaine invité
ID de bogue 15962837 : une évacuation de coeur ne se termine pas lorsqu'une panne se produit au niveau de la puce. Une évacuation qui est suivie d'une panne de coeur fonctionne correctement, mais la panne au niveau de la puce ne prend pas fin lorsque vous essayez de retirer un noeud CMP complet.
Solution de contournement : aucune. Planifiez le remplacement de la puce lorsque vous diagnostiquez une panne au niveau de celle-ci.
Oracle Solaris 10 : les opérations de reconfiguration dynamique de la mémoire se bloquent lorsque la mémoire est réduite à moins de quatre giga-octets
ID de bogue 15942036 : si vous effectuez une opération de DR de la mémoire pour réduire la mémoire à moins de quatre giga-octets, l'opération risque de se bloquer indéfiniment. Si vous exécutez une commande ldm cancel-op memdr sur ce domaine, un message incorrect est émis :
The memory removal operation has completed. You cannot cancel this operation.
Malgré ce message, l'opération de DR de mémoire se bloque et vous risquez de ne pas être en mesure d'effectuer d'autres opérations ldmd sur le domaine invité concerné.
Solution de contournement : ne tentez de réduire la mémoire à moins de quatre giga-octets dans aucun domaine. Si vous êtes déjà dans cet état, exécutez la commande ldm stop -f ou connectez-vous au domaine et réinitialisez-le.
La reconfiguration dynamique de CPU d'un très grand nombre de CPU virtuelles peut échouer
ID de bogue 15826354 : la reconfiguration dynamique (DR) d'un très grand nombre de CPU entraîne le renvoi d'un échec par le démon ldmd. Bien que ldmd arrive à expiration, l'opération de reconfiguration dynamique continue en arrière-plan et finit par aboutir. Néanmoins, ldmd n'est plus aligné avec le domaine résultant et les opérations de reconfiguration dynamique ultérieures risquent de ne pas être autorisées.
Par exemple :
# ldm ls NAME STATE FLAGS CONS VCPU MEMORY UTIL NORM UPTIME primary active -n-cv- UART 7 20G 2.7% 0.4% 1h 41m ldg0 active -n---- 5000 761 16G 75% 51% 6m # ldm rm-vcpu 760 ldg0 Request to remove cpu(s) sent, but no valid response received VCPU(s) will remain allocated to the domain, but might not be available to the guest OS Resource removal failed # ldm set-vcpu 1 ldg0 Busy executing earlier command; please try again later. Unable to remove the requested VCPUs from domain ldg0 Resource modification failed # ldm ls NAME STATE FLAGS CONS VCPU MEMORY UTIL NORM UPTIME primary active -n-cv- UART 7 20G 0.9% 0.1% 1h 45m ldg0 active -n---- 5000 761 16G 100% 0.0% 10m
Solution de contournement : attendez quelques minutes, puis réexécutez la commande ldm set-vcpu :
# ldm set-vcpu 1 ldg0 # ldm ls NAME STATE FLAGS CONS VCPU MEMORY UTIL NORM UPTIME primary active -n-cv- UART 7 20G 0.9% 0.1% 1h 50m ldg0 active -n---- 5000 1 16G 52% 0.0% 15m
Notez que 760 dépasse le maximum recommandé.
SPARCT4-4 : impossible d'associer un domaine invité
ID de bogue 15825330 : Oracle VM Server for SPARC se bloque au démarrage de certaines configurations SPARC T4-4 comportant une seule carte de processeur.
Solution de contournement : assurez-vous qu'il y a toujours une carte processeur dans les emplacements dédiés aux processeurs 0 et 1. Le redémarrage du système dans une configuration de ce type permet au logiciel Oracle VM Server for SPARC de démarrer.
Panique du domaine invité lorsque la propriété threading est modifiée de max-throughput à max-ipc
ID de bogue 15821246 : sur un système qui exécute le SE Oracle Solaris 11.1, la modification de la valeur de la propriété threading sur un domaine migré de max-ipc à max-throughput peut entraîner une panique sur le domaine invité.
Solution de contournement : ne modifiez pas le statut de la propriété threading d'un domaine invité tant qu'il n'a pas été réinitialisé.
Le domaine de contrôle se bloque lors d'une réinitialisation avec deux domaines d'E/S directs actifs
ID de bogue 15820741 : sur un système Oracle Solaris 11.1 comportant deux domaines avec des configurations d'E/S directes, le domaine de contrôle peut se bloquer lors de la réinitialisation.
Reprise : pour effectuer une reprise après un blocage de la réinitialisation, effectuez une remise à zéro du domaine de contrôle en lançant la commande suivante sur le processeur de service :
-> reset -f /HOST/domain/control
Absence d'un message d'erreur lorsqu'un ajout de reconfiguration dynamique de mémoire est en partie réussi
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.
Echec de la recréation d'un domaine avec des fonctions virtuelles PCIe à partir d'un fichier XML
ID de bogue 15783851 : un problème peut survenir lors de la recréation d'une configuration à partir d'un fichier XML représentant de façon incorrecte les contraintes de la fonction virtuelle.
Ce problème survient lorsque vous utilisez la commande ldm list-constraints -x pour enregistrer la configuration d'un domaine possédant des fonctions virtuelles PCIe.
Si vous recréez ultérieurement le domaine à l'aide de la commande ldm add-domain -i, les fonctions virtuelles d'origine n'existent pas, une tentative de liaison de domaine échoue et le message d'erreur suivant s'affiche :
No free matching PCIe device...
Même si vous créez les fonctions virtuelles manquantes, une autre tentative de liaison de domaine échoue et contient les mêmes messages d'erreur car les fonctions virtuelles sont déclassées en tant que périphériques PCIe par la commande ldm add-domain.
Solution de contournement : effectuez les opérations suivantes :
Enregistrez les informations relatives aux fonctions virtuelles à l'aide de la commande ldm list-io.
Détruisez chaque domaine affecté à l'aide de la commande ldm rm-dom.
Créer toutes les fonctions virtuelles requises à l'aide de la commande ldm create-vf.
Regénérez les domaines à l'aide de la commande ldm.
Lorsque vous utilisez la commande ldm add-io pour ajouter chaque fonction virtuelle, cette dernière est correctement classée en tant que périphérique de fonction virtuelle afin de pouvoir détecter le domaine.
Pour plus d'informations sur la regénération d'une configuration de domaine utilisant des fonctions virtuelles, reportez-vous à la section 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.
Emission de messages d'erreur incorrects lorsque le domaine de contrôle utilise des coeurs partiels au lieu de coeurs complets
ID de bogue 15783608 : lorsque vous faites basculer le domaine de contrôle d'une utilisation de coeurs physiquement limités à une utilisation de ressources de CPU non limitées, le message superflu suivant peut s'afficher :
Whole-core partitioning has been removed from domain primary,because dynamic reconfiguration has failed and the domain is now configured with a partial CPU core.
Solution de contournement : vous pouvez ignorer ce message.
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 :
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.
Arrêt brutal et redémarrage possibles de Logical Domains Manager en cas de modification simultanée de nombreux domaines
ID de bogue 15782994: Logical Domains Manager risque de s'arrêter brutalement et de redémarrer si vous tentez une opération concernant de nombreux domaines. Ce problème risque de se produire lorsque vous tentez d'apporter des modifications à la configuration de la mise en réseau virtuelle et qu'un grand nombre de périphériques réseau virtuels est situé sur le même commutateur virtuel dans plusieurs domaines. En règle générale, ce problème survient lorsque environ 90 domaines ou plus possèdent des périphériques réseau virtuels connectés au même commutateur virtuel et que la propriété inter-vnet-link est activée (le comportement par défaut). Confirmez le diagnostic en recherchant le message suivant dans le fichier journal ldmd et un fichier core dans le répertoire /var/opt/SUNWldm
Frag alloc for 'domain-name'/MD memory of size 0x80000 failed
Solution de contournement : évitez de créer un trop grand nombre de périphériques de réseau virtuel connectés au même commutateur virtuel. Le cas échéant, définissez la propriété inter-vnet-link sur off dans le commutateur virtuel. N'oubliez pas que cette option risque d'avoir une incidence négative sur les performances du réseau entre les domaines invités.
Domaine de contrôle nécessitant le coeur le plus bas du système
ID de bogue 15778392 : le domaine de contrôle requiert le coeur le plus bas du système. Par conséquent, si l'ID coeur 0 est le coeur le plus bas, il ne peut pas être partagé avec un autre domaine si vous souhaitez appliquer la contrainte whole-core au domaine de contrôle.
Par exemple, si le coeur le plus bas dans le système est l'ID coeur 0, le domaine de contrôle doit ressembler à la sortie suivante :
# ldm ls -o cpu primary NAME primary VCPU VID PID CID UTIL STRAND 0 0 0 0.4% 100% 1 1 0 0.2% 100% 2 2 0 0.1% 100% 3 3 0 0.2% 100% 4 4 0 0.3% 100% 5 5 0 0.2% 100% 6 6 0 0.1% 100% 7 7 0 0.1% 100%
Oracle Solaris 11 : signalement d'usurpation et d'échec RD Oracle Solaris par les DRM
ID de bogue 15775668 : un domaine doté d'une stratégie de priorité supérieure peut voler des ressources de CPU virtuelles à partir d'une stratégie de priorité inférieure. Pendant que cette action de "vol" est en cours, les messages d'avertissement suivants peuvent s'afficher dans le journal ldmd toutes les 10 secondes :
warning: Unable to unconfigure CPUs out of guest domain-name
Solution de contournement : vous pouvez ignorer ces messages qui vous induisent en erreur.
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 systèmes SPARC T3 et SPARC T4, la limite est fixée à 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 nouvelle tentative de connecter la console du 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 libérer la console, exécutez les commandes suivantes sur le domaine hôte qui héberge le concentrateur de console du domaine (habituellement le domaine de contrôle) :
primary# svcadm disable vntsd primary# svcadm enable vntsd
Destruction de l'ensemble des fonctions virtuelles et renvoi des emplacements vers le domaine root n'entraînant aucune restauration des ressources de complexe root
ID de bogue 15765858 : les ressources situées sur le complexe root ne sont pas restaurées après la destruction de l'ensemble des fonctions virtuelles et le renvoi des emplacements vers le domaine root.
Solution de contournement : définissez l'option iov sur off pour le bus PCIe spécifique.
primary# ldm start-reconf primary primary# ldm set-io iov=off pci_0
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.
Solution de contournement : utilisez la commande ldm add-io pour rajouter la carte au domaine primary.
Echec probable de la commande ldm stop en cas d'émission immédiatement après une commande ldm start
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.
init-system ne restaure pas les contraintes de coeur nommées pour les domaines invités à partir des fichiers XML enregistrés
ID de bogue 15758883 : la commande ldm init-system ne parvient pas à restaurer les contraintes de coeur des CPU nommés pour les domaines invités à partir d'un fichier XML enregistré.
Solution de contournement : effectuez les opérations suivantes :
Créez un fichier XML pour le domaine primary.
# ldm ls-constraints -x primary > primary.xml
Créez un fichier XML pour le ou les domaines invités.
# ldm ls-constraints -x domain-name[,domain-name][,...] > guest.xml
Effectuez un cycle d'alimentation du système et initialisez une configuration usine par défaut.
Appliquez la configuration XML au domaine primary.
# ldm init-system -r -i primary.xml
Appliquez la configuration XML aux domaines invités.
# ldm init-system -f -i guest.xml
Panique du système lors de la réinitialisation d'un domaine primary possédant un très grand nombre de fonctions virtuelles affectées
ID de bogue 15750727 : un système peut paniquer lorsque vous réinitialisez un domaine primary auquel un très grand nombre de fonctions virtuelles est assigné.
Solution de contournement : effectuez l'une des opérations suivantes :
Diminuez le nombre de fonctions virtuelles pour réduire le nombre de fonctions virtuelles ayant échoué. Cette modification peut maintenir la puce active.
Créez plusieurs pools IRM (Interrupt Resource Management) pour la fonction virtuelle ixgbe étant donné qu'un seul pool IRM est créé par défaut pour toutes les fonctions virtuelles ixgbe sur le système.
Echec de l'autorisation des transitions DR whole-core par le coeur partiel primary
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.
Affichage de l'état UNK ou INV par la commande ldm list-io après l'initialisation
ID de bogue 15738561 : la commande ldm list-io peut afficher l'état UNK ou INV pour les emplacements PCIe et les fonctions virtuelles SR-IOV si la commande s'exécute immédiatement après l'initialisation du domaine primary. Ce problème est causé par le délai de la réponse de l'agent Logical Domains à partir du SE Oracle Solaris.
Ce problème a uniquement été signalé sur un nombre limité de systèmes.
Solution de contournement : l'état des emplacements PCIe et les fonctions virtuelles sont automatiquement mis à jour après réception des informations par l'agent Logical Domains.
La suppression d'un grand nombre de CPU d'un domaine invité peut échouer
Domaine de contrôle.
ID de bogue 15677358 : utilisez une reconfiguration retardée plutôt qu'une reconfiguration dynamique pour supprimer plus de 100 CPU du domaine de contrôle (également appelé domaine primary). Utilisez les étapes suivantes :
Utilisez la commande ldm start-reconf primary pour mettre le domaine de contrôle en mode de reconfiguration retardée.
Supprimez le nombre de ressources de CPU de votre choix.
Si vous vous trompez lors de la suppression des ressources de CPU, ne tentez pas d'exécuter une nouvelle demande de suppression de CPU tant que le domaine de contrôle est à l'état de reconfiguration retardée. Le cas échéant, les commandes échoueront (reportez-vous à la section Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée du manuel Guide d’administration d’Oracle VM Server for SPARC 3.2 ). Au lieu de cela, annulez l'opération de reconfiguration retardée à l'aide de la commande ldm cancel-reconf, et recommencez.
Réinitialisez le domaine de contrôle.
Domaine invité.
ID de bogue ID 15726205 : le message d'erreur suivant peut s'afficher lorsque vous tentez de supprimer un grand nombre de CPU d'un domaine invité.
Request to remove cpu(s) sent, but no valid response received VCPU(s) will remain allocated to the domain, but might not be available to the guest OS Resource modification failed
Solution de contournement : arrêtez le domaine invité avant de supprimer plus de 100 CPU.
Les bogues ci-après décrivent des pannes susceptibles de se produire lors de la suppression d'un grand nombre de CPU d'un domaine.
Impossible d'utiliser les opérations d'enfichage à chaud d'Oracle Solaris pour supprimer à chaud un périphérique d'extrémité PCIe
ID de bogue 15721872 : vous ne pouvez pas utiliser les opérations d'enfichage à chaud Oracle Solaris pour supprimer à chaud un périphérique d'extrémité PCIe lorsque celui-ci a été supprimé du domaine primary à l'aide de la commande ldm rm-io. Pour savoir comment remplacer ou retirer un périphérique d'extrémité PCIe, reportez-vous à la section Procédure de modification matérielle PCIe du manuel Guide d’administration d’Oracle VM Server for SPARC 3.2 .
Le service d'agent de Logical Domains n'est pas disponible en ligne si le service de journal système n'est pas en ligne
ID de bogue 15707426 : si le service de journal système svc:/system/system-log, ne démarre pas et n'est pas en ligne, le service d'agent de Logical Domains n'est pas disponible en ligne non plus. Lorsque le service d'agent de Logical Domains n'est pas en ligne, les commandes virtinfo, ldm add-vsw, ldm add-vdsdev et ldm list-io risquent de ne pas se comporter normalement.
Solution de contournement : assurez-vous que le service svc:/ldoms/agents:default est activé et en ligne :
# svcs -l svc:/ldoms/agents:default
Si le service svc:/ldoms/agents:default est hors ligne, vérifiez qu'il est actif et que tous les services dépendants sont en ligne.
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 15702475 : 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.
Echec de délai d'attente de CPU virtuelles lors de la reconfiguration dynamique
ID de bogue 15701258 : l'exécution de la commande ldm set-vcpu 1 sur un domaine invité contenant plus de 100 CPU virtuelles et quelques unités de chiffrement ne parvient pas à supprimer les CPU virtuelles. Les CPU virtuelles ne sont pas supprimées en raison d'un échec du délai d'attente de la reconfiguration dynamique. Les unités de chiffrement, par contre, sont bien supprimées
Solution de contournement : utilisez la commande ldm rm-vcpu pour supprimer l'ensemble du contenu du domaine invité à l'exception des CPU virtuelles. Ne supprimez pas plus de 100 CPU virtuelles à la fois.
La commande pkgadd ne parvient pas à définir les entrées ACL sur /var/svc/manifest/platform/sun4v/ldmd.xml
ID de bogue 15668881 : lorsque vous utilisez la commande pkgadd pour installer le package SUNWldm.v depuis un répertoire exporté via NFS à partir d'un produit Sun ZFS Storage Appliance, le message d'erreur suivant peut s'afficher :
cp: failed to set acl entries on /var/svc/manifest/platform/sun4v/ldmd.xml
Solution de contournement : ignorez ce message.
SPARC T3-1 : problème lié aux disques accessibles via plusieurs chemins d'E/S directes
ID de bogue 15668368 : un système 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 système 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
Domaines invités exécutant Oracle Solaris 10 : les opérations de suppression de la reconfiguration dynamique de la mémoire avec plusieurs instances nxge NIU associées peuvent se bloquer indéfiniment et ne pas s'effectuer entièrement
ID de bogue 15667770 : lorsque plusieurs instances nxge NIU sont associées sur un domaine, les commandes ldm rm-mem et ldm set-mem utilisées pour supprimer la mémoire du domaine ne s'exécutent pas entièrement. Pour déterminer si le problème est survenu durant une opération de suppression de mémoire, surveillez l'avancement de l'opération au moyen de la commande ldm list -o status. Vous rencontrerez peut-être ce problème si le pourcentage d'avancement reste constant pendant plusieurs minutes.
Solution de contournement : annulez la commande ldm rm-mem ou ldm set-mem, puis vérifiez si une quantité de mémoire suffisante a été supprimée. Si ce n'est pas le cas, une autre commande de suppression de mémoire pourra être effectuée sans erreur afin de supprimer une plus petite quantité de mémoire.
Lancez une opération de reconfiguration retardée sur le domaine primary.
# ldm start-reconf primary
Assignez la quantité de mémoire souhaitée au domaine.
Réinitialisez le domaine primary.
Si le problème est survenu sur le domaine primary, procédez comme suit :
Si le problème survient sur un autre domaine, arrêtez-le avant de modifier la quantité de mémoire assignée au domaine.
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.
Une adresse MAC en cours d'utilisation peut être réaffectée
ID de bogue 15655199 : il arrive qu'une adresse MAC active ne soit pas détectée et soit réaffectée à tort.
Solution de contournement : vérifiez manuellement que les adresses MAC actives ne puissent pas être réaffectées.
Impossible de créer une configuration de domaine sur le processeur de service pour ldmconfig
ID de bogue 15654965 : le script ldmconfig ne peut pas créer correctement une configuration de domaines logique stockée sur le processeur de service.
Ajoutez la configuration au processeur de service.
# ldm add-spconfig new-config-name
Supprimez la configuration primary-with-clients du processeur de service.
# ldm rm-spconfig primary-with-clients
Arrêtez et redémarrez le système.
Solution de contournement : n'effectuez pas de cycle d'alimentation du système une fois le script ldmconfig terminé et le domaine réinitialisé. Réalisez plutôt la procédure manuelle suivante :
Si vous n'effectuez pas cette procédure avant le cycle d'alimentation du système, la présence de la configuration primary-with-client désactive les domaines. Dans ce cas, vous devez relier les domaines un à un, puis les démarrer à l'aide de la commande ldm start -a. Une fois les invités initialisés, répétez cette séquence pour initialiser les domaines invités automatiquement après le cycle d'alimentation.
Echec possible de la reconfiguration dynamique des valeurs MTU de périphériques réseau virtuel
ID de bogue 15631119 : si vous modifiez l'unité de transmission maximale (MTU) d'un périphérique réseau virtuel sur le domaine de contrôle, une opération de reconfiguration retardée est déclenchée. Si vous annulez ensuite la reconfiguration retardée, la valeur MTU du périphérique n'est pas rétablie à sa valeur initiale.
Reprise : réexécutez la commande ldm set-vnet pour définir la valeur MTU sur sa valeur initiale. La redéfinition de la valeur MTU a pour effet de placer le domaine de contrôle en mode de reconfiguration retardée que vous devez désactiver. La valeur MTU résultante est à présent la valeur MTU correcte initiale.
# ldm set-vnet mtu=orig-value vnet1 primary # ldm cancel-op reconf primary
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.
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.
La carte fibre 10 Gigabit Ethernet double, PCI Express Atlas affiche quatre sous-périphériques dans la sortie ldm list-io -l
ID de bogue 15597025 : lorsque vous exécutez la commande ldm ls-io -l sur un système équipé d'une carte fibre 10 Gigabit Ethernet double, PCI Express (X1027A-Z), la sortie peut afficher les informations suivantes :
primary# ldm ls-io -l ... pci@500/pci@0/pci@c PCIE5 OCC primary network@0 network@0,1 ethernet ethernet
La sortie affiche quatre sous-périphériques même si la carte Ethernet ne possède que deux ports. Cette anomalie se présente si la carte comporte quatre fonctions PCI. Deux de ces fonctions sont désactivées en interne et s'affichent comme étant des ports ethernet dans la sortie ldm ls-io -l.
Solution de contournement : vous pouvez ignorer les entrées ethernet dans la sortie ldm ls-io -l.
ldm : ces commandes mettent beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés
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 : évitez 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.
Oracle Solaris 11 : les zones configurées à l'aide d'une interface réseau automatique risquent de ne pas pouvoir démarrer
ID de bogue 15560811 : dans Oracle Solaris 11, les zones configurées à l'aide d'une interface réseau automatique (anet) risquent de ne pas démarrer dans un domaine possédant uniquement des périphériques de réseau virtuel Logical Domains.
Solution 1 : affectez un ou plusieurs périphériques réseau physique au domaine invité. Utilisez la fonctionnalité d'affectation de bus PCIe, d'E/S directes (DIO) ou la fonctionnalité SR-IOV pour affecter un NIC physique au domaine.
Solution 2 : si la configuration requise pour la configuration des zones consiste en une configuration entre les zones du domaine, créez un périphérique etherstub. Utilisez le périphérique etherstub en tant que "liaison inférieure" dans la configuration des zones afin que les cartes NIC virtuelles soient créées sur le périphérique etherstub.
Solution 3 : utilisez une affectation de lien exclusive pour attribuer un périphérique de réseau virtuel Logical Domains à une zone. Affectez des périphériques de réseau virtuel au domaine en fonction de vos besoins. Vous pouvez également choisir de désactiver les liens inter-vnet afin de créer un grand nombre de périphériques de réseau virtuel.
Oracle Solaris 10 : les périphériques réseau virtuels ne sont pas créés correctement sur le domaine de contrôle
ID de bogue 15560201 : il arrive que la commande ifconfig indique que le périphérique n'existe pas après l'ajout d'un périphérique de réseau virtuel ou de disque virtuel à un domaine. Ce problème survient car l'entrée /devices n'a pas été créée.
Bien que ce problème ne devrait pas se produire en fonctionnement normal, l'erreur peut se présenter lorsque le numéro d'instance d'un périphérique réseau virtuel ne correspond pas à celui répertorié dans le fichier /etc/path_to_inst.
Par exemple :
# ifconfig vnet0 plumb ifconfig: plumb: vnet0: no such interface
Le numéro d'instance d'un périphérique virtuel est indiqué dans la colonne DEVICE de la sortie ldm list :
# ldm list -o network primary NAME primary MAC 00:14:4f:86:6a:64 VSW NAME MAC NET-DEV DEVICE DEFAULT-VLAN-ID PVID VID MTU MODE primary-vsw0 00:14:4f:f9:86:f3 nxge0 switch@0 1 1 1500 NETWORK NAME SERVICE DEVICE MAC MODE PVID VID MTU vnet1 primary-vsw0@primary network@0 00:14:4f:f8:76:6d 1 1500
Le numéro d'instance (0 pour les deux périphériques vnet et vsw de la sortie affichée précédemment) peut être comparé au numéro d'instance indiqué dans le fichier path_to_inst afin de s'assurer qu'ils sont identiques.
# egrep '(vnet|vsw)' /etc/path_to_inst "/virtual-devices@100/channel-devices@200/virtual-network-switch@0" 0 "vsw" "/virtual-devices@100/channel-devices@200/network@0" 0 "vnet"
Solution de contournement : si les numéros d'instance ne sont pas identiques, supprimez le périphérique de réseau virtuel ou de commutateur virtuel. Ensuite, rajoutez-le en spécifiant explicitement le numéro d'instance requis en définissant la propriété id.
Vous pouvez également modifier manuellement le fichier /etc/path_to_inst. Reportez-vous à la page de manuel path_to_inst(4).
 | Mise en garde - Aucune modification ne doit pas être apportée à /etc/path_to_inst sans un examen attentif. |
Les cartes NIU/XAUI récemment ajoutées ne sont pas visibles pour le SE hôte si le logiciel Logical Domains est configuré
ID de bogue15555509 : si le logiciel Logical Domains est configuré sur un système et que vous ajoutez une autre carte réseau XAUI, celle-ci n'est pas visible après l'arrêt et le redémarrage de la machine.
Reprise : pour que la carte XAUI récemment ajoutée soit visible dans le domaine de contrôle, suivez les étapes ci-dessous :
Définissez et effacez une variable factice dans le domaine de contrôle.
Les commandes suivantes utilisent une variable factice appelée fix-xaui :
# ldm set-var fix-xaui=yes primary # ldm rm-var fix-xaui primary
Enregistrez la configuration modifiée sur le processeur de service (SP) en écrasant l'actuelle.
Les commandes suivantes utilisent une configuration appelée fix-config1 :
# ldm rm-spconfig config1 # ldm add-spconfig config1
Effectuez une réinitialisation de reconfiguration sur le domaine de contrôle.
# reboot -- -r
A ce stade, vous pouvez configurer les réseaux récemment disponibles pour que le logiciel Logical Domains puisse les utiliser.
Panique possible du domaine d'E/S ou du domaine invité lors d'une initialisation à partir de e1000g
ID de bogue 15543982 : vous pouvez configurer deux domaines au maximum avec des complexes root PCI-E dédiés sur des systèmes tels que le Sun Fire T5240. Ces systèmes sont dotés de deux CPU UltraSPARC T2 Plus et de deux complexes root d'E/S.
pci@500 et pci@400 sont les deux complexes root du système. Le domaine primary contient toujours au moins un complexe root. Un second domaine peut être configuré avec un complexe root non assigné ou non lié.
Si le système est configuré avec un domaine primary contenant pci@500 et un second domaine contenant pci@400
Remarque - Sur certaines lames, le domaine primary (disque système) est par défaut présent sur le bus pci@400.Le périphérique e1000g de la structure pci@400 est utilisé pour initialiser le second domaine
La structure (ou noeud terminal) pci@400 contient la carte réseau intégrée e1000g. Une panique de domaine peut survenir dans les circonstances suivantes :
Evitez les périphériques réseau suivants s'ils sont configurés dans un domaine qui n'est pas le domaine primary :
/pci@400/pci@0/pci@c/network@0,1 /pci@400/pci@0/pci@c/network@0
Si ces conditions sont réunies, le domaine panique en générant une erreur PCI-E fatale.
Evitez une telle configuration, ou si vous l'utilisez, n'initialisez pas le système à partir des périphériques répertoriés.
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
Il arrive que l'exécution de la commande uadmin 1 0 à partir d'un système Logical Domains ne retourne pas le système à l'invite OK
ID de bogue 15511551 : il arrive qu'un système Logical Domains ne revienne pas à l'invite ok après une réinitialisation consécutive à l'exécution de la commande uadmin 1 0 à partir de la ligne de commande. Ce comportement anormal se présente uniquement si la variable Logical Domains auto-reboot? est définie sur true. Si auto-reboot? est définie sur false, la commande génère le résultat attendu.
Solution de contournement : exécutez la commande suivante à la place :
uadmin 2 0
Ou, exécutez la commande avec la variable auto-reboot? toujours définie sur false.
Logical Domains Manager met parfois plus de 15 minutes pour arrêter un domaine
ID de bogue 15505014 : l'arrêt d'un domaine ou le nettoyage de la mémoire peut prendre plus de 15 minutes avec une seule CPU et une configuration de mémoire très importante. Durant l'arrêt, les CPU d'un domaine sont utilisées pour nettoyer l'ensemble de la mémoire détenue par le domaine. Le temps mis pour effectuer le nettoyage peut être assez long si une configuration donnée est déséquilibrée, par exemple, si un domaine à une seule CPU comporte 512 giga-octets de mémoire. Ce délai de nettoyage prolongé vient augmenter le temps nécessaire pour arrêter un domaine.
Solution de contournement : assurez-vous que les configurations de mémoire importante (plus de 100 giga-octets) comportent au moins un coeur.
La commande scadm peut se bloquer à la suite d'une réinitialisation d'un contrôleur système ou d'un processeur de service
ID de bogue 15469227 : la commande scadm d'un domaine de contrôle exécutant le SE Oracle Solaris 10 5/08 ou ultérieur peut se bloquer à la suite d'une réinitialisation de contrôleur système. Le système ne parvient pas à rétablir correctement une connexion après une réinitialisation de contrôleur système.
Reprise : réinitialisez l'hôte pour rétablir la connexion avec le contrôleur système.
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.
Un domaine invité comportant un nombre trop important de réseaux virtuels sur le même réseau utilisant DHCP peut devenir non réactif
ID de bogue ID 15422900 : si vous configurez plus de quatre réseaux virtuels (vnets) dans un domaine invité sur le même réseau utilisant le protocole DHCP (Dynamic Host Configuration Protocol), le domaine peut devenir non réactif pour traiter le trafic réseau.
Solution de contournement : définissez ip_ire_min_bucket_cnt et ip_ire_max_bucket_cnt sur des valeurs plus grandes comme 32, si vous disposez de huit interfaces.
Récupération : exécutez une commande ldm stop-domain domain-name suivie d'une commande ldm start-domain domain-name sur le domaine invité (domain-name) en question.
Les variables OpenBoot PROM ne peuvent pas être modifiées par la commande eeprom lorsque Logical Domains Manager est en cours d'exécution
ID de bogue 15387338 : ce problème est sommairement décrit dans la section Persistance des variables Logical Domains du manuel Guide d’administration d’Oracle VM Server for SPARC 3.2 et concerne uniquement le domaine de contrôle.
Impossible de définir des clés de sécurité durant l'exécution de Logical Domains
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.
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