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.
Les bogues suivants du SE Oracle Solaris ont été corrigés dans les versions complètes du SE Oracle Solaris. Ces bogues sont peut-être encore présents dans les versions du SE Oracle Solaris 10. Pour éviter ces problèmes, veillez à exécuter l'une des versions du SE Oracle Solaris associée à l'ID de bogue.
Pour plus d'informations sur les bogues de ce tableau, passez en revue les signalements de bogues.
|
ID de bogue 21953704 : la commande ldm list-io peut ne pas afficher les informations les plus récentes relatives à IOV immédiatement après l'exécution d'une commande cfgadm. Vous devrez peut-être attendre jusqu'à quatre minutes pour que les informations mises à jour soient disponibles.
Solution de contournement : aucune.
ID de bogue 21780045: L'utilitaire ovmtcreate génère une chaîne NULL pour les informations de Version dans le fichier OVF s'il ne s'agit pas de l'environnement linguistique C (non anglais).
La valeur des propriétés Version et FullVersion est nulle, tel qu'indiqué par les lignes XML affichées en gras dans cet exemple :
<ovf:VirtualSystem ovf:id="templates">
<ovf:Info>Oracle VM Template</ovf:Info>
<ovf:ProductSection ovf:class="com.oracle.ovmt">
<ovf:Info>Oracle VM Template</ovf:Info>
<ovf:Product>Oracle VM Template</ovf:Product>
<ovf:Version></ovf:Version>
<ovf:FullVersion></ovf:FullVersion>
Lorsque l'utilitaire ovmtdeploy se sert des modèles créés à l'aide de l'utilitaire ovmtcreate dans un environnement linguistique non-C, une exception java se produit, car les modèles incluent les chaînes NULL.
# /opt/ovmtutils/bin/ovmtdeploy -d guest10 -o /export/home/ovm \
/export/home/templates.ova
Oracle Virtual Machine for SPARC Deployment Utility
ovmtdeploy Version
Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved.
STAGE 1 - EXAMINING SYSTEM AND ENVIRONMENT
------------------------------------------
Checking user privilege
Performing platform & prerequisite checks
Checking for required services
Named resourced available
2 - ANALYZING ARCHIVE & RESOURCE REQUIREMENTS
---------------------------------------------------
Checking .ova format and contents
Validating archive configuration
Exception in thread "main" java.lang.NullPointerException
at ovfparse.OvfParse.getTagValue(OvfParse.java:233)
at ovfparse.VmProduct.<init>(VmProduct.java:33)
at ovfparse.VmSys.<init>(VmSys.java:72)
at ovfparse.OvfParse.parseOVFByDOM(OvfParse.java:371)
at ovfparse.OvfParse.<init>(OvfParse.java:56)
at ovmtdeploy.Ovmtdeploy.exec(Ovmtdeploy.java:1841)
at ovmtdeploy.Ovmtdeploy.main(Ovmtdeploy.java:1946)
Solution de contournement : effectuez les opérations suivantes :
Modifiez le fichier OVF pour ajouter les numéros de version au contenu des propriétés Version et FullVersion.
Réarchivez le modèle ova à l'aide de la commande gtar.
Par exemple :
# /usr/bin/gtar -cf templates.ova templates.ovf templates.mf System.img.gz
Exécutez l'utilitaire ovmtdeploy avec l'option –k pour ignorer le contrôle de somme.
ID de bogue 21674282 : Lorsque vous remplacez une carte PCIe dans le même emplacement, l'utilisation de la commande ldm add-vsan qui spécifie un alias pour le périphérique HBA SCSI physique (/SYS) risque d'échouer.
Solution : ne spécifiez pas de nom d'alias de périphérique. A la place, indiquez le chemin d'accès complet du périphérique (/pci) pour la commande ldm add-vsan.
ID de bogue 21635033 : Lorsqu'un domaine de service possède plusieurs serveurs de disque virtuel (vds), l'exécution de l'utilitaire ovmtcreate pour un domaine invité risque d'échouer, car l'utilitaire contrôle uniquement la première instance vds du domaine de service.
Par exemple, l'utilitaire ovmtcreate pour le domaine gdom3 échoue si le disque virtuel est configuré comme suit :
Le domaine primary dispose de quatre serveurs de disque virtuel (vds)
Le serveur de disque virtuel qui correspond au disque virtuel du domaine gdom3 est associé à vds3
Dans l'exemple de sortie suivant, les lignes en gras indiquent que vds0 est le premier serveur de disque virtuel et que le périphérique de serveur de disque virtuel pour le disque virtuel gdom3 n'est pas vds0.
primary# ldm list -l -p -o disk VERSION 1.15 DOMAIN|name=primary| VDS|name=vds0|nclients=1 |vol=vol0|opts=|dev=/export/home/ovm/gdom0.img|mpgroup= VDS|name=vds1|nclients=1 |vol=vol0|opts=|dev=/export/home/ovm/gdom1.img|mpgroup= VDS|name=vds2|nclients=1 |vol=vol0|opts=|dev=/export/home/ovm/gdom2.img|mpgroup= VDS|name=cdrom|nclients=3 |vol=1|opts=|dev=/export/home/ovm/sol-113_1.iso|mpgroup= |vol=2|opts=|dev=/export/home/ovm/sol-113_2.iso|mpgroup= |vol=3|opts=|dev=/export/home/ovm/sol-113_3.iso|mpgroup= |vol=4|opts=|dev=/export/home/ovm/sol-113_4.iso|mpgroup= VDS|name=vds3|nclients=1 |vol=disk0|opts=|dev=/export/home/ovm/gdom3.img|mpgroup= DOMAIN|name=gdom0| VDISK|name=vdisk0|vol=vol0@vds0|timeout=|dev=disk@0|server=primary|mpgroup=|id=0 VDISK|name=cdrom|vol=1@cdrom|timeout=|dev=disk@1|server=primary|mpgroup=|id=1 DOMAIN|name=gdom1| VDISK|name=vdisk0|vol=vol0@vds1|timeout=|dev=disk@0|server=primary|mpgroup=|id=0 VDISK|name=cdrom|vol=2@cdrom|timeout=|dev=disk@1|server=primary|mpgroup=|id=1 DOMAIN|name=gdom2| VDISK|name=vdisk0|vol=vol0@vds2|timeout=|dev=disk@0|server=primary|mpgroup=|id=0 VDISK|name=cdrom|vol=3@cdrom|timeout=|dev=disk@1|server=primary|mpgroup=|id=1 DOMAIN|name=gdom3| VDISK|name=vdisk0|vol=disk0@vds3|timeout=|dev=disk@0|server=primary|mpgroup=|id=0
La commande ldm list suivante indique l'état du domaine gdom3 :
primary# ldm list NAME STATE FLAGS CONS VCPU MEMORY UTIL NORM UPTIME primary active -n-cv- UART 32 46848M 0.3% 0.3% 1d 51m gdom0 active -n---- 5000 24 24G 0.0% 0.0% 1d 35m gdom1 active -n---- 5001 24 24G 0.0% 0.0% 8d 18h 21m gdom2 active -n---- 5002 24 24G 0.0% 0.0% 8d 17h 43m gdom3 bound ------ 5003 24 24G
La commande suivante affiche l'erreur qui se produit lors de l'exécution de la commande ovmtcreate pour le domaine gdom3 :
# /opt/ovmtutils/bin/ovmtcreate -d gdom3 -o /export/home/ovmt STAGE 1 - EXAMINING SYSTEM AND ENVIRONMENT ------------------------------------------- Performing platform & prerequisite checks Checking user permissions Checking for required packages Checking for required services Checking directory permissions STAGE 2 - ANALYZING DOMAIN --------------------------- Retrieving and processing attributes Checking domain state Getting domain resource settings Discovering network topology Discovering disk topology ERROR: VDS Device does not exist or not readable
Solution : assurez-vous que le domaine de service possède un seul serveur de disque virtuel avant d'exécuter l'utilitaire ovmtcreate.
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 systèmes 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 système 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 : modifiez le fichier XML pour supprimer les sections qui font référence au type de ressource socket.
ID de bogue 21561834 : si le nombre de CPU virtuelles d'un domaine est inférieur à quatre, la stratégie DRM risque de ne pas pouvoir ajouter de CPU virtuelles au domaine même si leur utilisation dépasse de manière significative le niveau d'utilisation supérieur. Si la valeur de propriété util-upper est supérieure à 70, la valeur par défaut, la stratégie DRM risque de ne pas pouvoir ajouter de CPU virtuelles même si le domaine possède plus de quatre CPU virtuelles.
Solution : attribuez au moins la valeur 15 à la propriété elastic-margin de la stratégie DRM.
primary# ldm set-policy elastic-margin=15 name=policy-name domain-name
Si la valeur de propriété util-upper est supérieure à 70, affectez au moins la valeur 20 à la propriété elastic-margin de la stratégie DRM.
primary# ldm set-policy elastic-margin=20 name=policy-name domain-name
ID de bogue 21527087 : dans de rares cas, l'utilisation de la commande ldm set-socket pour spécifier des sockets pour un domaine en cours d'exécution risque de provoquer le comportement inattendu suivant :
Le Logical Domains Manager risque de s'arrêter brutalement
La commande ldm set-socket finit de s'exécuter mais une partie des CPU et de la mémoire du domaine n'est pas remappée vers les sockets spécifiés
Cependant, si la partition physique (PPAR) comporte plus de 12 sockets, n'utilisez pas les commandes ldm set-socket --restored-degraded et ldm set-socket socket_id=id lorsque le domaine est en cours d'exécution. Si vous exécutez ces commandes sur un domaine en cours d'exécution, l'état de la commande ldmd peut être endommagé.
Solution : arrêtez le domaine avant d'exécuter une commande ldm set-socket.
Il est recommandé d'annuler les contraintes de socket d'un domaine actif à l'aide la commande ldm set-socket pour attribuer la valeur NULL à la propriété socket_id.
ID de bogue 21510615 : parfois, des échecs persistants de type device busy ou ldm remove-io peuvent survenir lors de la suppression d'un ou plusieurs bus PCIe.
Solution : vérifiez le service gdm, désactivez manuellement (ou vérifiez et arrêtez Xorg) et recommencez l'opération ldm remove-io.
# svcs | grep gdm # svcadm disable -st svc:/application/graphical-login/gdm:default
Ou :
# ps -ef | grep Xorg # pkill Xorg
ID de bogue 21367043 : dans de rares cas, les contraintes de socket risquent de se désynchroniser des ressources de CPU et de mémoire associées d'un domaine. Les commandes ldm rm-vcpu, ldm set-vcpu, ldm rm-core et ldm set-core risquent d'entraîner l'arrêt brutal du Logical Domains Manager avec le message d'erreur suivant dans le fichier journal SMF ldmd :
fatal error: xcalloc(0,4) : one of number or size is <= 0 at line 1183 of affinity_core.c
Solution : effacez les contraintes de socket du domaine à l'aide des commandes suivantes :
primary# ldm list-socket domain-name primary# ldm set-socket socket_id= domain-name
ID de bogue 21369897 : au cours de l'administration d'un domaine invité, l'exécution de la commande ldmpower provoque une erreur de segmentation du démon ldmd.
Solution : n'exécutez pas la commande ldmpower pendant que vous effectuez d'autres opérations d'ajout ou de suppression sur un domaine invité.
ID de bogue 21352084, 21861284 et 21861327 : dans de rares cas, un domaine root peut rencontrer une grave erreur si une erreur d'E/S se produit et qu'il commence à l'analyser pendant la réinitialisation d'un domaine d'E/S.
Le message de panique affiché est similaire à ce qui suit :
panic[cpu15]/thread=2a1017d3c20: Fatal error has occured in: PCIe fabric.(0x2)(0x245)
Les ereports sont transférés sur la console lorsque l'erreur grave se produit. Les ereports indiquent que certaines valeurs de registre d'état, y compris celle de pcie_ue_status, sont égales à FFs. Après l'erreur grave, le domaine root est rétabli une fois réinitialisé.
Solution de contournement : aucune.
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 : 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 21299404 : si vous utilisez la commande ldm shrink-socket pour effectuer une opération de reconfiguration dynamique et que l'un des blocs de mémoire du domaine n'est pas aligné à 256 Mo, la commande risque de supprimer 256 Mo de mémoire supplémentaires du domaine actif. Si la mémoire du domaine est fragmentée, le démon ldmd risque de tenter de supprimer de la mémoire supplémentaire.
Solution de contournement : aucune.
ID de bogue 21283102 : la commande ldm list-rsrc-group risque d'indiquer les mêmes informations sur la mémoire et les ressources d'E/S sous /SYS/MB (carte mère) et les autres groupes de ressources. Par exemple :
primary# ldm list-group
NAME CORE MEMORY IO
/SYS/PM0 32 64G 4
/SYS/PM1 32 256G 4
/SYS/PM2 32 128G 4
/SYS/PM3 32 128G 4
/SYS/MB 0 576G 16
primary# ldm list-group -a -l
NAME CORE MEMORY IO
/SYS/PM0 32 64G 4
CORE
CID BOUND
0, 1 primary
2, 3, 4, 5, 6, 7, 8, 9
10, 11, 12, 13, 14, 15, 16, 17
18, 19, 20, 21, 22, 23, 24, 25
26, 27, 28, 29, 30, 31
MEMORY
PA SIZE BOUND
0x0 57M _sys_
0x3900000 32M _sys_
0x5900000 94M _sys_
0xb700000 393M _sys_
0x24000000 192M _sys_
0x30000000 31488M
0x7e0000000 64M _sys_
0x7e4000000 64M _sys_
0x7e8000000 384M _sys_
0x80000000000 32G
IO
DEVICE PSEUDONYM BOUND
pci@300 pci_0 primary
pci@340 pci_1 primary
pci@380 pci_2 primary
pci@3c0 pci_3 primary
------------------------------------------------------------------------------
NAME CORE MEMORY IO
/SYS/PM1 32 256G 4
CORE
CID BOUND
32, 33, 34, 35, 36, 37, 38, 39
40, 41, 42, 43, 44, 45, 46, 47
48, 49, 50, 51, 52, 53, 54, 55
56, 57, 58, 59, 60, 61, 62, 63
MEMORY
PA SIZE BOUND
0x100000000000 768M
0x100030000000 24G primary
0x100630000000 105728M
0x180000000000 128G
IO
DEVICE PSEUDONYM BOUND
pci@400 pci_4 primary
pci@440 pci_5 primary
pci@480 pci_6 primary
pci@4c0 pci_7 primary
------------------------------------------------------------------------------
NAME CORE MEMORY IO
/SYS/PM2 32 128G 4
CORE
CID BOUND
64, 65, 66, 67, 68, 69, 70, 71
72, 73, 74, 75, 76, 77, 78, 79
80, 81, 82, 83, 84, 85, 86, 87
88, 89, 90, 91, 92, 93, 94, 95
MEMORY
PA SIZE BOUND
0x200000000000 64G
0x280000000000 64G
IO
DEVICE PSEUDONYM BOUND
pci@500 pci_8 primary
pci@540 pci_9 primary
pci@580 pci_10 primary
pci@5c0 pci_11 primary
------------------------------------------------------------------------------
NAME CORE MEMORY IO
/SYS/PM3 32 128G 4
CORE
CID BOUND
96, 97, 98, 99, 100, 101, 102, 103
104, 105, 106, 107, 108, 109, 110, 111
112, 113, 114, 115, 116, 117, 118, 119
120, 121, 122, 123, 124, 125, 126, 127
MEMORY
PA SIZE BOUND
0x300000000000 64G
0x380000000000 64G
IO
DEVICE PSEUDONYM BOUND
pci@600 pci_12 primary
pci@640 pci_13 primary
pci@680 pci_14 primary
pci@6c0 pci_15 primary
------------------------------------------------------------------------------
NAME CORE MEMORY IO
/SYS/MB 0 576G 16
MEMORY
PA SIZE BOUND
0x0 57M _sys_
0x3900000 32M _sys_
0x5900000 94M _sys_
0xb700000 393M _sys_
0x24000000 192M _sys_
0x30000000 31488M
0x7e0000000 64M _sys_
0x7e4000000 64M _sys_
0x7e8000000 384M _sys_
0x80000000000 32G
0x100000000000 768M
0x100030000000 24G primary
0x100630000000 105728M
0x180000000000 128G
0x200000000000 64G
0x280000000000 64G
0x300000000000 64G
0x380000000000 64G
IO
DEVICE PSEUDONYM BOUND
pci@300 pci_0 primary
pci@340 pci_1 primary
pci@380 pci_2 primary
pci@3c0 pci_3 primary
pci@400 pci_4 primary
pci@440 pci_5 primary
pci@480 pci_6 primary
pci@4c0 pci_7 primary
pci@500 pci_8 primary
pci@540 pci_9 primary
pci@580 pci_10 primary
pci@5c0 pci_11 primary
pci@600 pci_12 primary
pci@640 pci_13 primary
pci@680 pci_14 primary
pci@6c0 pci_15 primary
Solution : reportez-vous aux informations détaillées relatives à la mémoire et à l'E/S dans les colonnes suivantes pour déterminer si les mêmes informations de ressource sont indiquées :
Mémoire : PA, SIZE et BOUND
E/S : DEVICE, PSEUDONYM et BOUND
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 : supprimez et 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 21114622 : lorsque vous exécutez la commande ldm create-vf ou ldm destroy-vf, le pilote de la fonction physique associée est détaché puis rattaché, ce qui peut prendre un temps considérable non quantifiable. La durée dépend du nombre de fonctions virtuelles impliquées et de la complexité du périphérique matériel cible.
L'exécution de la commande ldm list-io risque d'indiquer que la fonction physique (et ses fonctions virtuelles enfants) présente le statut INV (non valide).
Actuellement, le Logical Domains Manager interroge l'agent pendant un temps déterminé, puis l'interrogation s'arrête. Si la période d'interrogation est trop courte, le périphérique risque d'afficher le statut INV indéfiniment.
Solution : dans le domaine root propriétaire du périphérique de la fonction physique, redémarrez le service ldoms/agents.
primary# svcadm restart ldoms/agents
Exécutez cette commande si le statut INV persiste pendant au moins six minutes après l'exécution de la commande ldm create-vf ou ldm destroy-vf.
ID de bogue 20951004 : vhba doit prendre en charge les HBA SCSI lorsque MPxIO est activé dans le domaine de service.
Solution : désactivez MPxIO pour tous les ports initiateur du domaine de service en exécutant la commande suivante :
# stmsboot -d
ID de bogue 20882700 : lorsqu'un périphérique PCIe (ou une fonction virtuelle SR-IOV) est supprimé ou ajouté dans un domaine, le démon du gestionnaire de pannes fmd d'Oracle Solaris 11.3 signale l'événement exactement comme s'il s'agissait de l'ajout ou de la suppression physique d'une FRU.
Des messages similaires à ce qui suit peuvent s'afficher sur la console et dans le fichier /var/adm/messages :
SUNW-MSG-ID: FMD-8000-A0, TYPE: Alert, VER: 1, SEVERITY: Minor EVENT-TIME: Tue May 19 18:39:41 PDT 2015 PLATFORM: unknown, CSN: unknown, HOSTNAME: starbuck SOURCE: software-diagnosis, REV: 0.1 EVENT-ID: 5077e6c3-6a15-457e-a55b-cb72ea5f9728 DESC: FRU has been added to the system. AUTO-RESPONSE: FMD topology will be updated. IMPACT: System impact depends on the type of FRU. REC-ACTION: Use fmadm faulty to provide a more detailed view of this event. Please refer to the associated reference document at http://support.oracle.com/msg/FMD-8000-A0 for the latest service procedures and policies regarding this diagnosis.
# fmadm faulty
--------------- ------------------------------------ ----------- ---------
TIME EVENT-ID MSG-ID SEVERITY
--------------- ------------------------------------ ----------- ---------
Apr 14 10:04:00 2d981602-975c-4861-9f26-e37360eca697 FMD-8000-CV Minor
Problem Status : open
Diag Engine : software-diagnosis / 0.1
System
Manufacturer : Oracle Corporation
Name : SPARC T7-2
Part_Number : T7_2
Serial_Number : T7_2
Host_ID : 86582a8c
----------------------------------------
Suspect 1 of 1 :
Problem class : alert.oracle.solaris.fmd.fru-monitor.fru-remove
Certainty : 100%
FRU
Status : active/not present
Location : "/SYS/MB/PCIE1"
Manufacturer : unknown
Name : unknown
Part_Number : unknown
Revision : unknown
Serial_Number : unknown
Chassis
Manufacturer : Oracle-Corporation
Name : SPARC-T7-2
Part_Number : T7_2
Serial_Number : T7_2
Resource
Status : active/not present
Description : FRU '/SYS/MB/PCIE1' has been removed from the system.
Response : FMD topology will be updated.
Impact : System impact depends on the type of FRU.
Action : Use 'fmadm faulty' to provide a more detailed view of this event.
Please refer to the associated reference document at
http://support.oracle.com/msg/FMD-8000-CV for the latest service
procedures and policies regarding this diagnosis.Solution : vous pouvez ignorer ces alertes si elles ont été générées par des actions d'administrateur explicites pour ajouter ou supprimer un périphérique d'E/S dans un domaine.
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. Par ailleurs, le retrait du câble entraîne l'échec des opérations d'E/S dans le domaine invité.
Solution : 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 20774477 : si vous utilisez des unités de stockage prenant en charge le SES, l'erreur device busy apparaît lorsque vous tentez de retirer un bus PCIe qui héberge ces unités. Pour savoir si vous utilisez ce type d'unité de stockage, recherchez la chaîne ses ou enclosure dans la sortie ldm list-io -l pour le bus PCIe.
Solution : appliquez l'une des solutions suivantes pour retirer le bus PCIe :
Retirer le bus PCIe de façon dynamique.
Désactivez le service FMD.
primary# svcadm disable -st svc:/system/fmd
Retirez le bus PCIe.
primary# ldm remove-io bus
Réactivez le service FMD.
primary# svcadm enable svc:/system/fmd
Retirer le bus PCIe de façon statique.
Placez le domaine racine associé au bus PCIe dans une reconfiguration retardée.
primary# ldm start-reconf root-domain
Retirez le bus PCIe.
primary# ldm remove-io bus
Effectuez une réinitialisation dans la console du domaine racine.
root-domain# reboot
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é.
ID de bogue 20532270 : vous devez connaître toutes les opérations d'E/S directes ou de suppression de bus dynamique qui tentent de supprimer le HBA SCSI physique du contrôle du SAN virtuel.
Si vous effectuez une opération ldm remove-io sur une ressource PCIe référencée par un périphérique SAN virtuel, ce dernier est inutilisable s'il n'a jamais été référencé par une commande ldm add-vhba. Si l'opération ldm remove-io intervient après l'exécution de la commande ldm add-vhba, le module vsan empêche la suppression de la ressource PCIe.
Solution : supprimez le SAN virtuel.
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.
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 : 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 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
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
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.
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 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.
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.
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 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.
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é.
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.
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.
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 : 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 : 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 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.
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
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.
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.
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.
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.
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%
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
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
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.
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 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.
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 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.3 .
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 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
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.
Si le problème est survenu sur le domaine primary, procédez comme suit :
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 survient sur un autre domaine, arrêtez-le avant de modifier la quantité de mémoire assignée au domaine.
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 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
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.
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 de la commande ldm ls-io -l.
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.
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.
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 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.
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 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.3 et concerne uniquement le domaine de contrôle.
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