Ignorer les liens de navigation | |
Quitter la vue de l'impression | |
Notes de produit d'Oracle® VM Server for SPARC 3.1.1.2, 3.1.1.1, 3.1.1 et 3.1 |
Utilisation de cette documentation
Chapitre 1 Notes de version d'Oracle VM Server for SPARC 3.1.1.2, 3.1.1.1, 3.1.1 et 3.1
Mise à jour de maintenance d'Oracle VM Server for SPARC 3.1.1.2
Mise à jour de maintenance d'Oracle VM Server for SPARC 3.1.1.1
Nouveautés de la mise à jour de maintenance d'Oracle VM Server for SPARC 3.1.1.1
Nouveautés d'Oracle VM Server for SPARC 3.1.1
Nouveautés d'Oracle VM Server for SPARC 3.1
Plates-formes prises en charge
Versions du SE Oracle Solaris requises
Versions du SE Oracle Solaris requises pour Oracle VM Server for SPARC 3.1.1
Versions du SE Oracle Solaris requises pour Oracle VM Server for SPARC 3.1
Logiciels requis pour activer les dernières fonctionnalités d'Oracle VM Server for SPARC
Patchs du microprogramme système requis
Version logicielle minimale requise
Configuration matérielle et logicielle requise pour les E/S directes
Configuration matérielle et logicielle SR-IOV PCIe
Configuration logicielle et matérielle requise pour les domaines root non primary
Configuration matérielle et logicielle requise pour le mode de récupération
Emplacement du logiciel Oracle VM Server for SPARC
Emplacement de la documentation
Logiciels compatibles avec le logiciel Oracle VM Server for SPARC
Logiciels de contrôleur système utilisés avec Oracle VM Server for SPARC
Mise à niveau vers le logiciel Oracle VM Server for SPARC actuel
Mise à niveau vers le logiciel Oracle VM Server for SPARC 3.1.1.1
Mise à niveau vers le logiciel Oracle VM Server for SPARC 3.1.1
Mise à niveau vers le logiciel Oracle VM Server for SPARC 3.1
Fonctionnalités Oracle VM Server for SPARC en phase d'abandon
Impossible de dissocier des domaines lorsqu'ils se fournissent mutuellement des services
Impossible pour un domaine d'exécuter le SE Oracle Solaris 10 si plus de 1 024 CPU sont associés
Eviter la création d'une configuration où deux domaines se fournissent mutuellement des services
Mise à niveau à partir d'un SE Oracle Solaris 10 antérieur au SE Oracle Solaris 10 5/08
Les termes Processeur de service et Contrôleur système sont utilisés de manière interchangeable
Détection de la configuration ou des métapériphériques Solaris Volume Manager d'un domaine invité
Initialisation d'un grand nombre de domaines
Arrêt correct et cycle d'alimentation d'un système Oracle VM Server for SPARC
Mise hors tension d'un système comportant plusieurs domaines actifs
Arrêt et redémarrage du système
Taille de la mémoire requise différente de la mémoire allouée
Persistance des variables Logical Domains
Sun SNMP Management Agent d'Oracle ne prend pas en charge plusieurs domaines
Commande ldmp2v convert : des messages d'avertissement VxVM durant une initialisation
Configuration requise pour le partitionnement forcé Oracle des licences logicielles
Option de mise à niveau absente lors de l'utilisation de ldmp2v prepare -R
ldmp2v : la méthode d'archivage ufsdump n'est plus utilisée avec cette commande
Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée
Compatibilité du disque d'initialisation d'Oracle Solaris
Restrictions de la migration de domaine
Restrictions de version pour la migration
Restrictions de la CPU pour la migration
Restrictions applicables aux versions pour la migration entre CPU
Problèmes liés à Oracle VM Server for SPARC MIB
La commande snmptable ne fonctionne pas avec l'option Version 2 ou Version 3
Blocage du domaine de contrôle lors de l'arrêt ou du démarrage de domaines d'E/S
Affichage d'avertissements sur la console lors de la création de fonctions virtuelles Fibre Channel
La modification de la configuration des fonctions physiques de Fibre Channel prend quelques minutes
Les restrictions de la fonction SR-IOV du Système Fujitsu M10 sont différentes
Problèmes liés à SR-IOV InfiniBand
Affichage de messages induisant en erreur pour les opérations SR-IOV InfiniBand
Bogues liés au logiciel Oracle VM Server for SPARC
Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1.2
Panne système lors de l'application de la contrainte whole-core à un domaine primary à coeur partiel
Les zones de noyau bloquent la migration en direct des domaines hôtes
Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1.1
Le Logical Domains Manager n'empêche pas la création de dépendances circulaires
Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1
La fonction physique Fibre Channel est défaillante et désactivée par FMA
Chemin de périphérique incorrect pour les fonctions virtuelles Fibre Channel dans un domaine root
Bogues liés au logiciel Oracle VM Server for SPARC 3.1
Des problèmes peuvent survenir lorsque l'architecture FMA détecte de la mémoire défectueuse
La taille du tampon de description de la machine préallouée est utilisée lors de la migration
Un blocage du réseau virtuel empêche la migration de domaine
La sortie ldmpower n'inclut pas toujours les horodatages
mac_do_softlso abandonne les paquets LSO
Echec de la migration : Invalid Shutdown-group: 0
L'échec de la commande ldmp2v convert provoque une mise à niveau en boucle
Panique de domaine invité à lgrp_lineage_add(mutex_enter: bad mutex, lp=10351178)
Domaines invités en état de transition après la réinitialisation du domaine primary
ldm list n'affiche pas la propriété evacuated pour les périphériques d'E/S physiques
Une adresse physique non valide est reçue pendant la migration d'un domaine
Des sous-périphériques subordonnés à un périphérique PCIe retournent à l'état
SPARC M5-32 et SPARC M6-32 : panic: mpo_cpu_add: Cannot read MD
SPARC M5-32 et SPARC M6-32 : le contrôleur LSI-SAS est exporté de façon incorrecte avec SR-IOV
Deux propriétés sont manquantes dans la sortie ldm list-io -d d'un périphérique sxge sur SPARC T5-1B
ldm ne parvient pas à évacuer un coeur défectueux d'un domaine invité
La reconfiguration dynamique de CPU d'un très grand nombre de CPU virtuelles peut échouer
SPARCT4-4 : impossible d'associer un domaine invité
Panique du domaine invité lorsque la propriété threading est modifiée de max-throughput à max-ipc
Le domaine de contrôle se bloque lors d'une réinitialisation avec deux domaines d'E/S directs actifs
Echec de la recréation d'un domaine avec des fonctions virtuelles PCIe à partir d'un fichier XML
La commande ldm list -o n'accepte plus les abréviations pour format
Domaine de contrôle nécessitant le coeur le plus bas du système
Non-réactivité des commandes ldm exécutées sur le système cible après annulation d'une migration
Non-fonctionnement de certaines cartes Emulex lorsqu'elles sont assignées à un domaine d'E/S
Oracle Solaris 11 : signalement d'usurpation et d'échec RD Oracle Solaris par les DRM
Limitation du nombre maximum de fonctions virtuelles qu'il est possible d'affecter à un domaine
La console de domaine invité se bloque de manière aléatoire sur les systèmes SPARC T4
Désactivation conseillée de l'option ldm remove-io des cartes PCIe possédant des ponts PCIe vers PCI
Echec probable de la commande ldm stop en cas d'émission immédiatement après une commande ldm start
Echec de l'autorisation des transitions DR whole-core par le coeur partiel primary
Affichage de l'état UNK ou INV par la commande ldm list-io après l'initialisation
Echec de la suppression d'un grand nombre de CPU d'un domaine invité
Un interblocage de noyau provoque le blocage de la machine pendant une migration
Echec de délai d'attente de CPU virtuelles lors de la reconfiguration dynamique
Des opérations de migration simultanées dans des
Echec de la suppression d'un grand nombre de CPU d'un domaine de contrôle
SPARC T3-1 : problème lié aux disques accessibles via plusieurs chemins d'E/S directes
Une adresse MAC en cours d'utilisation peut être réaffectée
Impossible de créer une configuration de domaine sur le processeur de service pour ldmconfig
La migration non coopérative de domaines Oracle Solaris peut se bloquer si cpu0 est hors ligne
La reconfiguration dynamique de la mémoire est désactivée à la suite de l'annulation d'une migration
Echec possible de la reconfiguration dynamique des valeurs MTU de périphériques réseau virtuel
La suppression dynamique de toutes les unités cryptographiques d'un domaine entraîne l'arrêt de SSH
ldm : ces commandes mettent beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés
Panique possible du domaine d'E/S ou du domaine invité lors d'une initialisation à partir de e1000g
Les liaisons de groupe de consoles et de port explicites ne sont pas migrées
La migration n'échoue pas si un vdsdev a un moteur de traitement différent sur la cible
Impossible de se connecter à la console d'un domaine migré sauf si le service vntsd est redémarré
Logical Domains Manager met parfois plus de 15 minutes pour arrêter un domaine
Impossible de définir des clés de sécurité durant l'exécution de Logical Domains
Le comportement de la commande ldm stop-domain n'est pas toujours très clair
Problèmes identifiés dans la documentation
ldm1M Page de manuel : Décrire les restrictions d'utilisation de la propriété mblock
ldm1M Page de manuel : Améliorer la description de la commande ldm list -o status
Page de manuel ldm1M : seule la commande ldm add-spconfig -r permet d'effectuer une reprise manuelle
Problèmes résolus dans la version 3.1.1.2 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1.1.1 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1.1 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1.0.1 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1 d'Oracle VM Server for SPARC
Les sections suivantes récapitulent les bogues que vous risquez de rencontrer lors de l'utilisation de chaque version du logiciel Oracle VM Server for SPARC 3.1. Chaque section contient les bogues détectés dans cette version. Les bogues risquent de se produire dans une ou plusieurs des versions de Oracle VM Server for SPARC 3.1. Les bogues les plus récents sont décrits en premier. Des solutions de contournement et des procédures de récupération sont spécifiées, le cas échéant.
ID de bogue 19456310 : lors de l'utilisation de la reconfiguration dynamique afin d'appliquer une contrainte whole-core à un domaine primary, la suppression des coeurs partiels provoque la panique du système d'exploitation ou un cycle d'alimentation du système.
Un coeur partiel est supprimé du coeur si ce dernier est partagé avec un autre domaine ou si l'un des strands libres du coeur est défectueux.
Solution de contournement : utilisez une reconfiguration retardée pour appliquer la contrainte whole-core à un domaine primary qui dispose de coeurs partiels.
Vérifiez que le domaine primary n'est pas soumis à la contrainte whole-core.
primary# ldm list -o resmgmt primary
Vérifiez que le domaine primary dispose de coeurs partiels.
primary# ldm list -o core primary
Déclenchez une reconfiguration retardée sur le domaine primary.
primary# ldm start-reconf primary
Appliquez la contrainte whole-core.
Par exemple, la commande suivante alloue deux coeurs complets au domaine primary :
primary# ldm set-core 2 primary
Réinitialisez le domaine primary.
Vous pouvez rencontrer les bogues suivants si votre système exécute la version du microprogramme système 8.5.1.b, 9.2.1.b ou 9.2.1.c. Pour plus d'informations, reportez-vous à la section Les domaines invités Oracle Virtual Machine (OVM) for SPARC peuvent ne pas accepter l'entrée de la console sur les serveurs SPARC de séries T4/T5/M5/M6 exécutant les versions 8.5.1.b et 9.2.1.B/C des microprogrammes système Sun (Doc ID 1946535.1)
ID de bogue 19430884 : un domaine invité configuré avec 108 disques virtuels à partir de deux domaines de service est migré. Après la migration, la commande format se bloque même si les disques sont disponibles et accessibles.
Solution de contournement : réinitialisez le système.
ID de bogue 19388985 : la tentative de connexion à une console de domaine invité réussit mais la console ne tire pas parti des entrées Cette situation se produit parfois après l'arrêt et le démarrage des domaines invités, le redémarrage du domaine primary et la liaison et le démarrage des domaines invités.
Solution de contournement : annulez la liaison puis reliez le domaine invité.
Récupération : enregistrez la configuration des domaines invités, puis effectuez un cycle d'alimentation.
ID de bogue 18289196 : sur un système SPARC, une zone de noyau en cours d'exécution dans un domaine Oracle VM Server for SPARC bloquera la migration en direct du domaine invité. Le message d'erreur suivant s'affiche :
Live migration failed because Kernel Zones are active. Stop Kernel Zones and retry.
Solution de contournement : choisissez l'une des solutions suivantes :
Arrêter l'exécution de la zone de noyau.
# zoneadm -z zonename shutdown
Suspendre la zone de noyau.
# zoneadm -z zonename suspend
ID de bogue 19454837 : une migration en direct d'un domaine sur un système exécutant des versions particulières du microprogramme système SPARC peut échouer avec le message d'erreur suivant :
system1 # ldm migrate ldg1 system2 Target Password: Unable to restore ldc resource state on target Domain Migration of LDom ldg1 failed
Le message d'erreur survient après le transfert de l'intégralité de l'état du domaine à la machine cible, mais avant la tentative d'interruption du domaine à migrer sur la machine source. Le domaine à migrer reste en cours d'exécution sur le système source.
Les versions du microprogramme système affectées sont les suivantes :
SPARC T5, SPARC M5, SPARC M6 : version 9.2.1 du microprogramme système
SPARC T4 : version 8.5.1 du microprogramme système
Réduction des risques : à moins que vous ne souhaitiez tirer parti des nouvelles limites de LDC accrues (et ne pas utiliser la fonctionnalité de migration en direct), évitez de mettre votre système à jour avec les versions 8.5.1 ou 9.2.1 du microprogramme système avant que les versions 8.6 et 9.3, au minimum, ne soient publiées.
Récupération : effectuez un cycle d'alimentation de la machine source afin de permettre la migration en direct du domaine.
Solution de contournement : aucune.
ID de bogue 18770805 : si un commutateur virtuel net-dev et défectueux et ne peut être validé, l'opération de récupération échoue et le démon ldmd vide le coeur.
Récupération : désactivez le mode de récupération et récupérez la configuration manuellement.
ID de bogue 16934400 : lors de la migration d'un domaine invité vers un système SPARC M5 ou SPARC T5, le SE sur le domaine invité peut paniquer et afficher le message suspend: get stick freq failed.
Solution de contournement : ajoutez la ligne suivante au fichier /etc/system dans le domaine invité à migrer :
set migmd_buf_addl_size = 0x100000
Réinitialisez le domaine invité pour que les changements soient appliqués.
ID de bogue 15751041 : le Logical Domains Manager permet la création d'une configuration circulaire où deux domaines se fournissent mutuellement des services. Une telle configuration n'est pas recommandée car elle crée un point de panne unique où un domaine peut mettre l'autre domaine hors service. En outre, une dépendance circulaire empêche de dissocier les domaines concernés.
Solution de contournement : si une configuration de dépendance circulaire vous empêche de dissocier un domaine, supprimez les périphériques qui provoquent des dépendances circulaires puis tentez une nouvelle opération de dissociation.
ID de bogue 19480835 : les versions du microprogramme Sun System augmentent le nombre maximum de canaux de domaines logiques (LDC) par domaine invité :
SPARC T5, SPARC M5, SPARC M6 : 9.2.1
SPARC T4 : 8.5.1
Cette augmentation du nombre de LDC par domaine invité requiert l'exécution du Logical Domains Manager 3.1.1.1 au minimum.
Pour éviter les problèmes éventuels lors de l'utilisation de versions du Logical Domains Manager antérieures à la version 3.1.1 (incluse), n'augmentez pas le nombre de LDC par domaine invité au-delà des 768 pris en charge par les versions antérieures du microprogramme système. Par exemple, n'ajoutez pas un grand nombre de disques virtuels et d'interfaces réseau virtuelles avant d'avoir installé Logical Domains Manager 3.1.1.1 au minimum.
Les symptômes possibles suivants peuvent apparaître lorsque vous dépassez la limite de 768 LDC par domaine avec des versions d'Oracle VM Server for SPARC antérieure à la version 3.1.1 (incluse) :
Dépassement de dictionnaire dans OBP :
Dictionary overflow - here f21ffe58 limit f2200000 Dictionary overflow - here f21ffe70 limit f2200000 WARNING: /virtual-devices@100/channel-devices@200/disk@5b2: Problem creating devalias for virtual device node Dictionary overflow - here f21ffe70 limit f2200000 Dictionary overflow - here f21ffe70 limit f2200000 Dictionary overflow - here f21ffe70 limit f2200000 Stack Underflow ok
Panique dans vmem_xalloc :
panic[cpu6]/thread=2a10020fc80: vmem_xalloc(1a04610, 29360128, 29360128, 0, 0, 0, 0, 1): parameters inconsistent or invalid 000002a10020f000 genunix:vmem_xalloc+850 (1a04610, 1c00000, 0, 0, 1bfffff, 0) %l0-3: 0000000000001fff 0000000000002000 0000000000420000 0000000000000010 %l4-7: 0000000001c00000 0000000000000008 0000000001c00000 0000000000000000 000002a10020f180 unix:contig_vmem_xalloc_aligned_wrapper+24 (1a04610, 1c00000, 1, 0, 1000000, 1) %l0-3: 000002a10020f9a4 0000000000000008 0000000001a4bd90 0000000000000018 %l4-7: 0000000000000002 ffffffffffffffff 000000000136efe8 00000000013722c0 000002a10020f240 genunix:vmem_xalloc+5c8 (300150c2d98, 1c00000, 0, 0, 80000, 0) %l0-3: 00000300150c2ff0 ffffffffffffffff 00000300150c39e0 ffffffffff000000 %l4-7: 0000000000000000 ffffffffffffffff 0000000001000000 0000000000000004 000002a10020f3c0 unix:contig_mem_span_alloc+24 (300150c2d98, 1000000, 1, 1, cd4000, 3) %l0-3: 00000000000f4000 0000000000000000 0000000000000000 0000000001921897 %l4-7: 0000000000000006 00000000fe53dce8 00000000fee3a844 000000007ffffa4c 000002a10020f490 genunix:vmem_xalloc+5c8 (300150c4000, cd4000, 0, 0, 80000, 0) %l0-3: 00000300150c4258 ffffffffffffffff 00000300150c4c48 ffffffffffffe000 %l4-7: 0000000000000000 ffffffffffffffff 0000000000002000 0000000000000003 000002a10020f610 unix:contig_mem_alloc_align+28 (cd4000, 2000, 600957feaf8, 1, 600957feaf8, 18e3000) %l0-3: 0000000000000001 0000000000003000 00000300051c01d8 0000000000000000 %l4-7: 0000000000002000 0000000001a29e20 00000300051c01b0 00000300051c0380 000002a10020f6d0 unix:mach_descrip_buf_alloc+8 (cd4000, 2000, 4, 1, 2a10020f838, 10448d0) %l0-3: 0000000000000000 0000000000003000 00000300002141d8 0000000000000000 %l4-7: 0000000000000001 0000000000000100 00000300002141b0 0000030000214380 000002a10020f780 unix:mach_descrip_update+84 (1864c00, 1c00, cd4000, 18e31d8, 0, 0) %l0-3: 0000000001864c58 000002a10020f830 0000000000002000 ffffffffffffe000 %l4-7: 000002a10020f838 0000000000cd27b0 0000000001864c30 00000600957feaf8 000002a10020f840 platsvc:ps_md_data_handler+30 (1a4bcc0, 3003a822be0, 8, 18, 10, 1) %l0-3: 0000000000001d03 0000000000420000 0000000000420000 0000000000000010 %l4-7: 000003003a822bd8 0000000000000008 0000000000000008 000003000d9bb940 000002a10020f900 ds:ds_dispatch_event+30 (6009fef4df8, 1372000, 48, 9, 9, 3003a822bd0) %l0-3: 000002a10020f9a4 0000000000000008 0000000001a4bd90 0000000000000018 %l4-7: 0000000000000002 ffffffffffffffff 000000000136efe8 00000000013722c0 000002a10020f9b0 genunix:taskq_thread+3cc (600957fd390, 600957fd328, 260fe5123efd, 600957fd35a, 260fe5124083, 600957fd35c) %l0-3: 00000600957feaf8 00000600957fd358 0000000000000001 0000000000080000 %l4-7: 00000600957fd348 0000000000010000 00000000fffeffff 00000600957fd350
ID de bogue 18168525 et 18156291 : vous devez connecter la carte PCIe Fibre Channel à un commutateur Fibre Channel prenant en charge NPIV et compatible avec la carte PCIe. Si vous n'utilisez pas cette configuration, l'utilisation de la commande format ou la création ou suppression d'une fonction virtuelle peut provoquer la défaillance de la fonction physique et sa désactivation par FMA. Si cette défaillance se produit, le message qui s'affiche ressemble à l'exemple suivant
SUNW-MSG-ID: PCIEX-8000-0A, TYPE: Fault, VER: 1, SEVERITY: Critical EVENT-TIME: event-time PLATFORM: platform-type SOURCE: eft, REV: 1.16 EVENT-ID: event-ID DESC: A problem was detected for a PCIEX device. AUTO_RESPONSE: One or more device instances may be disabled IMPACT: Loss of services provided by the device instances associated with this fault 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/PCIEX-8000-0A for the latest service procedures and policies regarding this diagnosis.
Solution : si la carte a été mise en défaillance par FMA, vérifiez tout d'abord ses connexions et assurez-vous que la carte n'est pas connectée directement au stockage. Ensuite, exécutez l'étape correspondant à votre configuration
La carte est connectée directement au stockage – Configurez correctement la carte PCIe Fibre Channel en la connectant au commutateur Fibre Channel prenant en charge NPIV et compatible avec la carte PCIe. Ensuite, exécutez la commande fmadm repair pour ignorer le diagnostic FMA.
La carte n'est pas connectée directement au stockage– Remplacez la carte.
ID de bogue 18166010 : vous pouvez rencontrer des problèmes liés au protocole de transfert LDC de réseau virtuel si votre déploiement possède un grand nombre de périphériques de réseau virtuel.
Solution de contournement : effectuez les opérations suivantes :
Augmentez le nombre de nouvelles tentatives du protocole de transfert sur tous les domaines équipés d'un périphérique de réseau virtuel en ajoutant l'entrée suivante au fichier /etc/system :
set vnet:vgen_ldc_max_resets = 25
Remarque : vous devez réinitialiser tous les domaines sur lesquels vous avez mis à jour le fichier /etc/system pour que les modifications prennent effet. Pour obtenir des informations sur les réglages /etc/system, reportez-vous à la page de manuel system(4).
Désactivez les liens inter-vnet si un grand nombre de périphériques de réseau virtuel sont requis dans un commutateur virtuel.
Si plus de huit périphériques de réseau virtuel utilisent un commutateur virtuel donné, définissez la propriété inter-vnet-link sur off. La désactivation de la propriété inter-vnet-link empêche l'utilisation des canaux N2 pour les communications inter-vnet. Cette modification peut avoir des effets négatifs sur les performances des communications inter-vnet. Ainsi, si les performances entre invités sont essentielles pour votre déploiement, créez un commutateur virtuel distinct privé sur le système (sans indiquer de périphérique net-dev) qui utilise uniquement les périphériques de réseau virtuel nécessitant des communications inter-vnet.
Si votre déploiement ne nécessite pas de communications hautes performances entre les invités, définissez la propriété inter-vnet-link sur off même si moins de périphériques de réseau virtuel utilisent un commutateur virtuel donné.
primary# ldm set-vsw inter-vnet-link=off vsw0
Si cette solution ne résout pas votre problème, effectuez les modifications suivantes au fichier /etc/system sur tous les domaines disposant de périphériques de réseau virtuel et de périphériques de commutateur virtuel.
Remarque : la mise à jour du fichier /etc/system de cette manière peut avoir un effet négatif sur les performances des communications entre invités.
Ajoutez l'entrée suivante au fichier /etc/system d'un domaine disposant d'un périphérique de réseau virtuel :
set vnet:vnet_num_descriptors = 512
Ajoutez l'entrée suivante au fichier /etc/system d'un domaine disposant d'un périphérique de commutateur virtuel :
set vsw:vsw_num_descriptors = 512
Réinitialisez le système pour que ces paramètres prennent effet.
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 18032944 : la migration en direct entre plusieurs CPU d'un domaine d'une machine SPARC T5, SPARC M5 ou SPARC M6 vers une plate-forme exécutant un autre type de CPU a réussi. Cependant, une opération de reconfiguration dynamique ultérieure de la mémoire visant à augmenter la taille de la mémoire du domaine invité peut provoquer une panique telle que la suivante :
panic[cpu0]/thread=2a1003c9c60: kphysm_add_memory_dynamic(1018000, 200000): range has 2097152 pages, but memgr p_walk_pfnrange only reported 0 000002a1003c9500 genunix:kphysm_add_memory_dynamic+254 (1018000, 200000, 12e8000, 3, 1218000, 0) vpanic(12e8220, 1018000, 200000, 200000, 0, 2a1003c95c8) kphysm_add_memory_dynamic+0x254(1018000, 200000, 12e8000, 3, 1218000, 0) dr_mem_configure+0x94(1018000, 2a1003c97b4, fffffff, 2430000000, 1068ac00, 1068ac00) dr_mem_list_wrk+0x15c(4c01b3382b8, 0, 20, 4c014ba27c8, 1, 1) dr_mem_data_handler+0xa8(0, 4c01b3382b8, 20, 2a1003c9890, 7bac0644, 16) ds_dispatch_event+0x2c(4c01ee33478, 7bf888b8, 48, 7bf88800, 9, 9) taskq_thread+0x3a8(95af9e15e84, 4c010a5caf0, 95af9e15f74, 4c010a5cb22, 4c010a5cb24, 4c01e24d688) thread_start+4(4c010a5caf0, 0, 0, 0, 0, 0)
Cette panique se produit lorsque le système cible est l'un des suivants :
Systèmes SPARC T-Series avec socket 0 désactivé
Systèmes SPARC M-Series avec socket 0 désactivé
Domaines physiques sur un système SPARC M-Series ne contenant pas DCU0
Cette situation n'a aucun effet sur les migrations entre les systèmes ayant le même type de CPU ou les domaines ayant cpu-arch=native.
Solution : après la migration d'un domaine d'un système avec l'une de ces configurations, vous devez réinitialiser le domaine invité avant de tenter d'ajouter de la mémoire à l'aide d'une reconfiguration dynamique.
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 17796639 : Lorsque Oracle Enterprise Manager Ops Center 12c Version 1 Mise à jour 4 (12.1.4.0.0) est en cours d'exécution, si vous tentez d'effectuer une opération d'association, de dissociation, de démarrage ou d'arrêt sur un domaine en état d'association ou de dissociation, le service ldmd peut vider le coeur et le domaine basculera en mode de maintenance.
Récupération : si le service ldmd a déjà vidé le coeur, effectuez un cycle d'alimentation du système pour remettre le service ldmd en ligne.
Solution : déterminez si le domaine est en état d'association ou de dissociation en exécutant la commande ldm list. Si le domaine est dans l'un de ces deux états, patientez jusqu'à ce que l'opération soit terminée et que le domaine soit en état associé ou inactif.
ID de bogue 17663828 et 17576087 : lorsque l'architecture FMA tente d'isoler une plage de mémoire extrêmement restreinte en tant que pourcentage de la capacité de mémoire totale du système, Logical Domains Manager risque de désigner une très grande plage de mémoire comme placée sur liste noire.
Cette erreur peut avoir un impact important sur la capacité de mémoire utilisable, ce qui peut entraîner les problèmes suivants :
La réinitialisation d'un domaine invité affecté peut empêcher le démarrage de ce domaine car une quantité de mémoire excessive a été retirée à tort.
Il est possible qu'une très grande plage de mémoire ne soit plus affectable aux domaines invités si une demande de mise sur liste noire est appliquée à la mémoire non liée. Par conséquent, si vous tentez d'utiliser la majeure partie de la mémoire du système, vous risquez de ne pas pouvoir créer de domaine invité.
Logical Domains Manager risque de s'arrêter brutalement s'il redémarre avant que la mémoire défectueuse ne soit réparée car le bloc de mémoire placé sur liste noire risque de ne pas avoir été correctement marqué en interne.
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 : si une grande quantité de mémoire n'apparaît plus dans la sortie ldm list-devices -a memory, contactez Oracle Service pour confirmer et identifier le module DIMM qu'il convient de remplacer.
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.
ID de bogue 17627526 : il peut parfois arriver lors de l'initialisation du système qu'une condition de compétitivité se produise, dans laquelle le périphérique qu'utilise le démon ldmd pour communiquer avec l'hyperviseur n'est pas créé au moment du démarrage du service SMF svc:/ldoms/ldmd:default. Ce comportement entraîne le basculement du service SMF ldmd en mode de maintenance.
Le message d'erreur suivant s'affiche dans le fichier journal SMF ldmd :
ldmd cannot communicate with the hypervisor as the required device does not exist: /devices/virtual-devices@100/channel-devices@200/virtual-channel@0:hvctl
Ce problème peut se produire si le domaine de contrôle exécute l'une des versions de SE suivantes :
Au moins Oracle Solaris 11.1.12.3.0
Au moins Oracle Solaris 10 1/13 et le patch portant l'ID 150840-01
Récupération : vérifiez que le périphérique /devices/virtual-devices@100/channel-devices@200/virtual-channel@0:hvctl existe, puis exécutez la commande svcadm clear ldmd.
ID de bogue 17606070 : si vous affectez de la mémoire avant d'affecter des CPU au domaine primary dans le cadre d'une reconfiguration retardée, la mémoire possède une affinité avec les CPU allouées au moment de l'exécution de la commande ldm set-memory même si vous effectuez des commandes ldm set-vcpu ou ldm set-core supplémentaires. Par exemple, les commandes suivantes peuvent engendrer une situation où les 16 Go de mémoire alloués au domaine primary risquent de ne pas posséder d'affinité avec les huit coeurs alloués par la suite par la commande ldm set-core :
primary# ldm start-reconf primary primary# ldm set-mem 16G primary primary# ldm set-core 8 primary primary# reboot
Solution de contournement : assurez-vous d'affecter les coeurs au domaine primary avant d'affecter la mémoire. Par exemple, les commandes suivantes affectent tout d'abord huit coeurs au domaine primary, puis elles affectent 16 Go de mémoire :
primary# ldm start-reconf primary primary# ldm set-core 8 primary primary# ldm set-mem 16G primary primary# reboot
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 la version 8.4.0 ou une version ultérieure du microprogramme du système ou sur un serveur SPARC T5, SPARC M5 ou SPARC M6 exécutant la version 9.1.0 ou une version ultérieure du microprogramme du système, ou sur un système Système Fujitsu M10 exécutant 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 17285811 : un domaine invité qui a précédemment été migré ne parvient pas toujours à se réinitialiser lors des réinitialisations suivantes ou des opérations de démarrage du domaine à cause d'une panique du noyau. Ce problème se produit lorsque le domaine s'initialise. Le message de panique affiché est similaire à ce qui suit :
panic[cpu0]/thread=10012000: tilelet_assign_cb: assigning pfns [50000, c0000) to mgid 1, mnodeid 1: pachunk 1 already assigned to mgid 0, mnodeid 0
Solution de contournement : ne réinitialisez pas le domaine. Commencez par arrêter et dissocier le domaine, puis associez à nouveau le domaine et démarrez-le. Par exemple :
primary# ldm stop domain primary# ldm unbind domain primary# ldm bind domain primary# ldm start domain
Reprise : lorsque le problème se produit, arrêtez et dissociez le domaine, puis associez à nouveau le domaine et démarrez-le.
ID de bogue 17285745 : la migration d'un domaine invité vers un système SPARC T5, SPARC M5 ou SPARC M6 peut entraîner une panique du noyau sur le domaine invité avec affichage du message suspend: get stick freq failed.
Solution de contournement : ajoutez le paramètre suivant au fichier /etc/system dans le domaine invité à migrer. Puis réinitialisez le domaine invité.
set migmd_buf_addl_size = 0x100000
ID de bogue 17245915 : lorsque l'architecture FMA détecte un coeur défectueux, Logical Domains Manager tente de l'évacuer en procédant à une opération de reconfiguration du coeur si celui-ci est disponible pour être utilisé comme cible. Une fois cette opération réussie et le coeur défectueux remplacé, toute tentative de redimensionnement des CPU virtuelles d'un domaine invité à l'aide de la commande ldm add-vcpu peut échouer et le message d'erreur Invalid response s'affiche.
L'échec est intermittent et dépend de la configuration du système.
Solution de contournement : aucune.
Reprise : effectuez les opérations suivantes pour ajouter davantage de CPU au domaine invité :
Dissociez le domaine invité.
Supprimez toutes les CPU virtuelles.
Ajoutez à nouveau les CPU virtuelles.
Liez le domaine invité.
La possibilité d'utiliser la reconfiguration dynamique en toute fiabilité pour ajouter des CPU est entièrement restaurée lorsque les CPU sur liste noire sont réparées.
ID de bogue 17232035 : un domaine esclave peut se bloquer pendant une initialisation lorsque la valeur failure-policy=reset est réglée dans le domaine maître. Ce problème ne peut pas être reproduit avec des paramètres différents de la propriété failure-policy.
Reprise : arrêtez les domaines d'E/S associés à ce domaine root et démarrez le domaine root non primary.
Solution de contournement : définissez la propriété failure-policy sur une valeur autre que reset.
ID de bogue 17191488 : lors de la tentative de migration d'un domaine à partir d'un système SPARC T5-8 vers un système SPARC T4-4, l'erreur suivante se produit :
primary# ldm migrate ldg1 system2 Target Password: Timeout waiting for domain ldg1 to suspend Domain Migration of LDom ldg1 failed
Solution de contournement : pour éviter ce problème, définissez extended-mapin-space=on.
primary# ldm set-domain extended-mapin-space=on ldom
ID de bogue 17188920 : Les options –-suppress et –-timestamp n'affichent pas correctement les valeur d'horodatage.
Solution de contournement : incluez l'option –r lorsque vous utilisez les options –-suppress et –-timestamp de façon à afficher la sortie correcte.
ID de bogue 17182503 : mac_do_softlso() abandonne les paquets LSO qui sont générés par les fonctions vnet_vlan_insert_tag() et vnet_vlan_remove_tag().
Solution de contournement : pour éviter ce problème des paquets LSO balisés VLAN, désactivez la fonctionnalité LSO de réseau virtuel sur tous les domaines qui la prennent en charge.
Ajoutez les lignes suivantes dans le fichier /etc/system :
set vnet_enable_lso = 0 set vsw_enable_lso = 0
Réinitialisez le système.
Contrôlez les modifications à l'aide de la commande mdb -k.
# mdb -k > vnet_enable_lso/D vnet_enable_lso: vnet_enable_lso:0 > vsw_enable_lso/D vsw_enable_lso: vsw_enable_lso: 0
ID de bogue 17088083 : la migration d'un domaine comportant plus de huit CPU virtuelles peut entraîner l'altération de la mémoire si l'ID de groupe de processeurs le plus élevé du domaine dépasse un multiple de 64 unités. Par exemple, l'ID de groupe de processeurs le plus élevé sur le domaine est 63 avant la migration et 64 après la migration.
Utilisez la commande pginfo pour déterminer l'ID de groupe de processeurs dans un domaine. Au sein d'un domaine, exécutez la commande suivante pour imprimer l'ID de groupe de processeurs le plus élevé :
# pginfo -I|tr ' ' '\n'|sort -n|tail -1
Solution de contournement : réduisez le nombre de CPU virtuelles dans le domaine à huit avant d'effectuer la migration. A la fin de la migration, vous pouvez restaurer le nombre de CPU virtuelles d'origine dans le domaine.
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.
ID de bogue 17026219 : si une erreur se produit au cours de l'exécution de la commande ldmp2v convert, la propriété boot-device de l'invité risque de ne pas être définie sur son disque d'initialisation. Cette erreur entraîne l'initialisation de l'invité à partir de l'image d'installation d'Oracle Solaris une fois la mise à niveau d'Oracle Solaris terminée.
Solution de contournement : modifiez la propriété boot-device sur le domaine invité à partir du domaine de contrôle. Effectuez cette modification lorsque vous entrez à nouveau dans le programme d'installation d'Oracle Solaris, puis effectuez à nouveau la mise à niveau d'Oracle Solaris. Le domaine invité se réinitialise alors à partir du disque d'initialisation mis à niveau une fois la mise à niveau terminée.
Pour définir le périphérique d'initialisation, exécutez la commande suivante sur le domaine de contrôle. Cette commande considère que le système de fichiers root (/) du système physique d'origine se trouve sur la tranche 0 du disque d'initialisation. Si le système d'origine s'est initialisé à partir d'une autre tranche, modifiez en conséquence la lettre après les deux-points. Par exemple, utilisez a pour la tranche 0, b pour la tranche 1, et ainsi de suite.
primary# ldm set-variable boot-device=disk0:a domain-name
ID de bogue 17027275 : les migrations de domaines entre des systèmes SPARC T4 exécutant le microprogramme système 8.3 et des systèmes SPARC T5, SPARC M5 ou SPARC M6 ne devraient pas être autorisées. Bien que la migration soit réussie, une opération de reconfiguration dynamique ultérieure entraîne une panique.
Solution de contournement : mettez à jour le microprogramme vers la version 8.4 sur le système SPARC T4. Voir la solution de contournement pour les 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.
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.
Procédez comme suit sur chaque domaine :
Accédez à la console du domaine.
primary# telnet localhost domain-name
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 16991255 : une panique se produit dans de rares circonstances lorsque le pilote du périphérique réseau virtuel fonctionne ne mode TxDring.
Solution de contournement : pour éviter cette panique, définissez la valeur de la propriété extended-mapin-space sur on.
primary# ldm set-domain extended-mapin-space=on ldom
ID de bogue 16895816 : La migration d'un domaine auquel une seule CPU virtuelle est associée peut paniquer sur le domaine invité dans la fonction pg_cmt_cpu_fini().
Solution : assignez au moins deux CPU virtuelles au domaine invité avant de procéder à sa migration. Par exemple, utilisez la commande ldm add-vcpu 2 domain-name pour augmenter le nombre de CPU virtuelles associées au domaine invité domain-name.
ID de bogue 16864417 : la commande ldm migrate -n ne signale pas d'échec lors d'une tentative de migration entre une machine SPARC T5, SPARC M5 ou SPARC M6 et une machine UltraSPARC T2 ou SPARC T3.
Solution de contournement : aucune.
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 non primary, reportez-vous à la section Utilisation de domaines root différents du domaine primary du manuel Guide d’administration d’Oracle VM Server for SPARC 3.1 .
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.
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.
ID de bogue 16494899 : dans de rares circonstances, la migration d'un domaine est refusée et le message suivant apparaît dans le journal SMF ldmd :
Mar 08 17:42:12 warning: Received invalid physical address during migration of domain rztcrmdev2: base RA: 0x400000000, offset: 0x1ffff0000, PA: 0x87fff0000 size: 0x1001a
Etant donné que la migration échoue avant que le domaine ne soit suspendu sur le système source, il n'y a pas de perte de service.
Cet échec se produit dans les circonstances suivantes, qui entraînent le refus de la migration :
Le contenu de la dernière tranche de la mémoire du domaine est compressé et sa taille compressée est supérieure à celle de la tranche de mémoire.
Le démon ldmd détermine de manière incorrecte que des données ont été enregistrées dans la mémoire en dehors du domaine sur la cible.
Le mode d'échec dépend de la charge de travail du domaine et du contenu exact de la mémoire car la plupart des tranches sont compressées pour atteindre une taille plus petite.
Reprise : bien qu'il n'existe aucune solution de contournement garantie pour ce problème, une migration ultérieure peut fonctionner si la charge de travail et par conséquent le contenu de la mémoire sont modifiés. Vous pouvez également essayer d'utiliser la reconfiguration dynamique pour modifier la taille de la mémoire du domaine.
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
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.
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 16238762 : sur un serveur SPARC M5-32 ou SPARC M6-32 avec au moins 2,4 To de mémoire, une tentative d'augmenter le nombre de CPU dans le domaine primary de 6 à 1056 CPU entraîne une panique du noyau et le message suivant s'affiche :
mpo_cpu_add: Cannot read MD
La procédure suivante est à l'origine de la panique :
Procédez à la mise sous tension avec un DCU assigné à un hôte.
Par exemple, affectez DCU0 à HOST0.
Créez des domaines invités.
Enregistrez une configuration sur le processeur de service.
Mettez l'hôte hors tension.
Assignez un autre DCU à l'hôte.
Par exemple, assignez DCU1 à HOST0.
Mettez l'hôte sous tension.
Le microprogramme vérifie que la configuration est "amorçable". Cette vérification garantit que toutes les CPU, la mémoire et les E/S présentes au moment de la création de la configuration le sont toujours. Le microprogramme génère également un nouveau PRI pour décrire la configuration de l'ensemble du système.
La configuration est mise sous tension avec succès et les domaines invités sont initialisés.
Tentez d'ajouter de façon dynamique une CPU à un domaine existant.
Une nouvelle description de machine est générée et reflète les informations de latence correctes, mais le SE Oracle Solaris ne peut pas analyser les nouvelles informations et panique.
Solution de contournement : pour éviter la panique, n'effectuez pas les étapes énumérées dans la description du problème.
Si vous avez déjà effectué ces étapes et que vous avez subi la panique, procédez aux étapes suivantes :
Effectuez une action après avoir initialisé une configuration enregistrée dans un domaine physique de taille moindre. Retirez une CPU de chaque domaine actif par exemple.
Réinitialisez le domaine.
Dissociez le domaine.
Liez à nouveau tout domaine lié.
Enregistrez une nouvelle configuration sur le processeur de service.
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
Cette panique se produit dans les cas suivants :
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.
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
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 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.
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.
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 16059331 : le pilote sxge ne peut pas définir les MTU Jumbo correctement pour ses fonctions virtuelles sur le domaine primary.
Solution de contournement : modifiez manuellement le fichier /kernel/drv/sxge.conf pour configurer le MTU Jumbo sur les interfaces de fonction virtuelle sxge dans le domaine invité.
ID de bogue 15974640 : la commande ldm ne parvient pas à définir correctement les valeurs des propriétés mac-addr et alt-mac-addrs pour le périphérique sxge. Par conséquent, le démon ldmd signale une adresse MAC incohérente. D'autre part, tous les groupements de liaisons basés sur l'adresse MAC de la VNIC échouent également.
ID de bogue 15974547 : en cas d'exécution sur un système SPARC T5-1B comportant sxge, la sortie ldm list-io -d PF-device n'affiche pas les propriétés max-vlans ou max-vf-mtu. Ces propriétés sont présentes sur les systèmes SPARC T5-1B avec ixgbe ainsi que sur les systèmes autres que les lames.
La valeur de la propriété max-vlans est manquante. La valeur doit être égale à 0 car le périphérique sxge ne prend pas en charge le balisage VLAN du matériel. La valeur de propriété max-vf-mtu est fixée à 1500, ce qui empêche le périphérique de fonction physique de définir le MTU Jumbo pour les fonctions virtuelles.
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.
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.
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é.
ID de bogue 15825538 : en cas d'exécution d'une migration en direct sécurisée (ldm migrate) sur un domaine logique configuré avec les fonctions d'interfaces d'E/S réseau hybrides (mode=hybrid) et de migration entre les CPU activées (cpu-arch=generic), le délai d'attente de la migration peut expirer et le domaine rester dans un état suspendu.
Reprise : redémarrez le domaine logique.
Solution de contournement : n'utilisez pas de périphériques de réseau virtuel d'E/S hybride pour une migration en direct entre les CPU.
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.
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é.
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
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 15803617 : le domaine primary ou un domaine invité actif risque de paniquer durant une opération de migration en direct ou d'annulation de la liaison si le domaine est configuré avec des périphériques réseau virtuels d'E/S hybrides.
Reprise : redémarrez le domaine affecté.
Solution de contournement : n'utilisez pas de périphériques réseau virtuels d'E/S hybrides.
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.
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.
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 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.
ID de bogue 15781142 : la commande ldm list -o format n'accepte plus les abréviations pour format.
Alors qu'il était possible, dans le logiciel Oracle VM Server for SPARC 3.0, d'afficher des informations sur le réseau à l'aide de la commande ldm list -o net, ces abréviations ont été supprimées dans le logiciel Oracle VM Server for SPARC 3.1. Dans le logiciel Oracle VM Server for SPARC 3.1, vous devez utiliser la version complète de format dans la commande : ldm list -o network.
Solution de contournement : utilisez les noms de format indiqués dans la page de manuel ldm(1M).
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 15776752 : si vous annulez une migration en direct, le contenu de la mémoire de l'instance de domaine créé sur la cible doit être "nettoyé" par l'hyperviseur. Ce processus de nettoyage est effectué pour des raisons de sécurité et doit être terminé afin que la mémoire puisse être renvoyée vers le pool de mémoire libre. Durant la progression du nettoyage, les commandes ldm deviennent non réactives. Par conséquent, Logical Domains Manager semble suspendu.
Reprise : attendez la fin de la demande de nettoyage avant de tenter d'exécuter les autres commandes ldm. Ce processus peut être long. Par exemple, un domaine invité comptant 500 Go de mémoire peut mettre jusqu'à 7 minutes pour terminer le processus sur un serveur SPARC T4 ou jusqu'à 25 minutes sur un serveur SPARC T3.
ID de bogue 15776319 : sur un système qui exécute le SE Oracle Solaris sur le domaine de contrôle et le domaine d'E/S, certaines cartes Emulex affectées au domaine d'E/S ne fonctionnent pas correctement car celles-ci ne reçoivent pas les interruptions. Toutefois, lorsqu'elles sont affectées au domaine de contrôle, ces mêmes cartes fonctionnent correctement.
Ce problème survient avec les cartes Emulex suivantes :
Emulex 2-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM2)
Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE2FC-EB4-N)
Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM4)
Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-Z)
Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-N)
Solution de contournement : aucune.
ID de bogue 15776123 : si la commande cputrack est exécutée sur un domaine invité pendant la migration de ce domaine vers un système SPARC T4, le domaine invité peut paniquer sur la machine cible après avoir été migré.
Solution de contournement : n'exécutez pas la commande cputrack durant la migration d'un domaine invité vers un système SPARC T4.
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.
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 15775055 : après la migration d'un domaine entre deux machines possédant des fréquences de CPU différentes; le temps de disponibilité signalé par la commande ldm list peut être incorrect. Ces résultats incorrects surviennent car le temps de disponibilité est calculé par rapport à la fréquence STICK de la machine sur laquelle le domaine est exécuté. Si la fréquence STICK diffère entre les machines source et cible, le temps de disponibilité apparaît incorrect à l'échelle.
Le temps de disponibilité signalé et affiché par le domaine invité lui-même est correct. En outre, toute la comptabilisation effectuée par le SE Oracle Solaris dans le domaine invité est correcte.
ID de bogue 15773603 : lorsque l'initialisation se fait à partir d'une carte Intel dual port Ethernet Controller X540, le pilote ixgbe d'Oracle Solaris 10 peut entraîner une panique du système. Cette panique survient car le lecteur possède une horloge à haute priorité qui empêche les autres disques de se connecter.
Solution de contournement : réinitialisez le système.
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 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
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 stop notification failed
Solution de contournement : relancez la commande ldm stop.
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 ldom[,ldom][,...] > 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
Réinitialisez le système.
Appliquez la configuration XML aux domaines invités.
# ldm init-system -f -i guest.xml
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 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.
ID de bogue 15731303 : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire. Utilisez la commande ldm list -o mem pour afficher la configuration de mémoire de votre domaine. Certaines configurations de mémoire comportant plusieurs blocs équivalant à un total supérieur à 500 risquent de paniquer avec une pile ressemblant à ce qui suit :
panic[cpu21]/thread=2a100a5dca0: BAD TRAP: type=30 rp=2a100a5c930 addr=6f696e740a232000 mmu_fsr=10009 sched:data access exception: MMU sfsr=10009: Data or instruction address out of range context 0x1 pid=0, pc=0x1076e2c, sp=0x2a100a5c1d1, tstate=0x4480001607, context=0x0 g1-g7: 80000001, 0, 80a5dca0, 0, 0, 0, 2a100a5dca0 000002a100a5c650 unix:die+9c (30, 2a100a5c930, 6f696e740a232000, 10009, 2a100a5c710, 10000) 000002a100a5c730 unix:trap+75c (2a100a5c930, 0, 0, 10009, 30027b44000, 2a100a5dca0) 000002a100a5c880 unix:ktl0+64 (7022d6dba40, 0, 1, 2, 2, 18a8800) 000002a100a5c9d0 unix:page_trylock+38 (6f696e740a232020, 1, 6f69639927eda164, 7022d6dba40, 13, 1913800) 000002a100a5ca80 unix:page_trylock_cons+c (6f696e740a232020, 1, 1, 5, 7000e697c00, 6f696e740a232020) 000002a100a5cb30 unix:page_get_mnode_freelist+19c (701ee696d00, 12, 1, 0, 19, 3) 000002a100a5cc80 unix:page_get_cachelist+318 (12, 1849fe0, ffffffffffffffff, 3, 0, 1) 000002a100a5cd70 unix:page_create_va+284 (192aec0, 300ddbc6000, 0, 0, 2a100a5cf00, 300ddbc6000) 000002a100a5ce50 unix:segkmem_page_create+84 (18a8400, 2000, 1, 198e0d0, 1000, 11) 000002a100a5cf60 unix:segkmem_xalloc+b0 (30000002d98, 0, 2000, 300ddbc6000, 0, 107e290) 000002a100a5d020 unix:segkmem_alloc_vn+c0 (30000002d98, 2000, 107e000, 198e0d0, 30000000000, 18a8800) 000002a100a5d0e0 genunix:vmem_xalloc+5c8 (30000004000, 2000, 0, 0, 80000, 0) 000002a100a5d260 genunix:vmem_alloc+1d4 (30000004000, 2000, 1, 2000, 30000004020, 1) 000002a100a5d320 genunix:kmem_slab_create+44 (30000056008, 1, 300ddbc4000, 18a6840, 30000056200, 30000004000) 000002a100a5d3f0 genunix:kmem_slab_alloc+30 (30000056008, 1, ffffffffffffffff, 0, 300000560e0, 30000056148) 000002a100a5d4a0 genunix:kmem_cache_alloc+2dc (30000056008, 1, 0, b9, fffffffffffffffe, 2006) 000002a100a5d550 genunix:kmem_cpucache_magazine_alloc+64 (3000245a740, 3000245a008, 7, 6028f283750, 3000245a1d8, 193a880) 000002a100a5d600 genunix:kmem_cache_free+180 (3000245a008, 6028f2901c0, 7, 7, 7, 3000245a740) 000002a100a5d6b0 ldc:vio_destroy_mblks+c0 (6028efe8988, 800, 0, 200, 19de0c0, 0) 000002a100a5d760 ldc:vio_destroy_multipools+30 (6028f1542b0, 2a100a5d8c8, 40, 0, 10, 30000282240) 000002a100a5d810 vnet:vgen_unmap_rx_dring+18 (6028f154040, 0, 6028f1a3cc0, a00, 200, 6028f1abc00) 000002a100a5d8d0 vnet:vgen_process_reset+254 (1, 6028f154048, 6028f154068, 6028f154060, 6028f154050, 6028f154058) 000002a100a5d9b0 genunix:taskq_thread+3b8 (6028ed73908, 6028ed738a0, 18a6840, 6028ed738d2, e4f746ec17d8, 6028ed738d4)
Solution de contournement : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire.
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.
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.1 .
ID de bogue 15710957 : lorsqu'un domaine invité chargé a une configuration d'E/S hybrides et que vous tentez de le migrer, la commande nxge risque de paniquer.
Solution de contournement : ajoutez la ligne suivante au fichier /etc/system sur le domaine primary et sur tout domaine de service faisant partie de la configuration d'E/S hybrides pour le domaine
set vsw:vsw_hio_max_cleanup_retries = 0x200
ID de bogue 15708982 : une migration initialisée ou en cours, ou toute commande ldm se bloque. Cette situation se produit lorsque le domaine à migrer utilise un système de fichiers partagé issu d'un autre système et que ce système de fichiers n'est plus partagé.
Solution de contournement : restaurez l'accessibilité du système de fichiers partagé.
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.
ID de bogue 15704500 : la migration d'un domaine invité actif peut se bloquer et la machine source peut ne plus répondre. Quand ce problème se produit, le message suivant est écrit dans la console et le fichier /var/adm/messages :
vcc: i_vcc_ldc_fini: cannot close channel 15 vcc: [ID 815110 kern.notice] i_vcc_ldc_fini: cannot close channel 15
Notez que le numéro de canal désigne le numéro de canal interne de Oracle Solaris, lequel peut être différent pour chaque message d'avertissement.
Solution de contournement : avant de faire migrer le domaine, déconnectez-vous de la console du domaine invité.
Reprise : arrêtez et redémarrez la machine source.
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.
ID de bogue 15701865 : si vous tentez une migration en direct d'un domaine dépendant d'un domaine inactif sur la machine cible, le démon ldmd échoue avec une erreur de segmentation et le domaine de la machine cible est redémarré. Vous pouvez néanmoins effectuer une migration, mais pas une migration en direct.
Solution de contournement : effectuez l'une des actions suivantes avant de tenter la migration en direct :
Supprimez la dépendance invitée du domaine à migrer.
Démarrez le domaine maître sur la machine cible.
ID de bogue 15701853 : si vous effectuez une migration de domaine alors qu'une stratégie DRM est en vigueur et que, par la suite, la stratégie DRM expire ou est supprimée du domaine migré, DRM ne parvient pas à restaurer le nombre d'origine de CPU virtuelles sur le domaine.
Solution de contournement : si un domaine est migré alors qu'une stratégie DRM est active, puis que cette dernière expire ou est supprimée, redéfinissez le nombre de CPU virtuelles. Utilisez la commande ldm set-vcpu pour définir le nombre de CPU virtuelles sur la valeur d'origine sur le domaine.
ID de bogue 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.
ID de bogue 15699763 : un domaine ne peut pas être migré s'il contient une adresse MAC en double. En général, lorsqu'une migration échoue pour ce motif, le message d'échec affiche l'adresse MAC en double. Cependant, dans de rares circonstances, ce message d'échec ne signale pas l'adresse MAC en double.
# ldm migrate ldg2 system2 Target Password: Domain Migration of LDom ldg2 failed
Solution de contournement : assurez-vous que les adresses MAC sur la machine cible sont uniques.
ID de bogue 15696986 : si deux commandes ldm migrate sont émises simultanément dans des "directions opposées," elles risquent de se bloquer et de ne jamais aboutir. Une situation avec des directions opposées se présente lorsque vous démarrez simultanément une migration de la machine A vers la machine B ou une migration de la machine B vers la machine A.
Le blocage se produit même si les processus de migration sont initialisés en tant que simulations à l'aide de l'option –n. Lorsque ce problème se produit, toutes les autres commandes ldm risquent de se bloquer.
Solution de contournement : aucune.
ID de bogue 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). 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.
ID de bogue 15672651 et 15731467 : vous pouvez observer des blocages du SE à la connexion ou au cours de l'exécution de commandes lorsque les conditions suivantes sont réunies
Le SE Oracle Solaris 10 8/11 est exécuté sur un système SPARC sun4v
La fonction de gestion de l'alimentation élastique est définie sur le processeur de service ILOM du système.
Solution de contournement : appliquez le patch ID 147149-01.
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.
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 15655513 : suite à la migration d'un domaine actif, l'utilisation des CPU dans le domaine migré peut considérablement augmenter pendant un intervalle de temps très court. Si une stratégie de gestion des ressources dynamique (DRM) est en vigueur pour le domaine au moment de la migration, Logical Domains Manager risque d'ajouter des CPU. En particulier, si les propriétés vcpu-max et attack n'ont pas été définies pendant l'ajout de la stratégie, la valeur par défaut unlimited a pour effet l'ajout au domaine migré de toutes les CPU non liées sur la machine cible.
Reprise : aucune reprise n'est nécessaire. Une fois que l'utilisation des CPU redescend en dessous de la limite supérieure définie par la stratégie DRM, Logical Domains Manager supprime automatiquement les CPU.
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.
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.
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 :
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.
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.
ID de bogue 15653424 : la migration d'un domaine actif peut échouer s'il exécute une version antérieure au SE Oracle Solaris 10 10/09 et que la CPU portant le plus petit numéro est à l'état hors ligne. L'opération échoue lorsque Logical Domains Manager recourt à la reconfiguration dynamique des CPU jusqu'à ce qu'il ne reste qu'une seule CPU dans le domaine. Ce faisant, Logical Domains Manager tente de supprimer du domaine toutes les CPU sauf celle portant le plus petit numéro, mais puisque celle-ci est hors ligne, l'opération échoue.
Solution de contournement : avant d'effectuer la migration, assurez-vous que la CPU portant le plus petit numéro est à l'état en ligne.
ID de bogue 15646293 : suite à la suspension d'un domaine Oracle Solaris 10 9/10 dans le cadre d'une opération de migration, la reconfiguration dynamique de la mémoire est désactivée. Cette action ne survient que si la migration réussit ou si elle a été annulée, en dépit du fait que le domaine demeure sur la machine source.
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 15606220 : à partir de la version Logical Domains 1.3, un domaine peut être migré même s'il est lié à plusieurs unités cryptographiques.
Dans les circonstances suivantes, la machine cible ne contient qu'une seule CPU une fois la migration effectuée :
La machine cible exécute Logical Domains 1.2
Le domaine de contrôle sur la machine cible exécute une version du SE Oracle Solaris non compatible avec la reconfiguration dynamique d'unités cryptographiques
Vous migrez un domaine contenant des unités cryptographiques
Une fois la migration terminée, le domaine cible redevient normalement opérationnel, mais se trouve à l'état d'exclusion sélective (une seule CPU).
Solution de contournement : préalablement à la migration, supprimez les unités cryptographiques de la machine source exécutant Logical Domains 1.3.
Réduction des risques : pour éviter de rencontrer ce problème, effectuez l'une des étapes suivantes, voire les deux :
Installez le logiciel Oracle VM Server for SPARC sur la machine cible.
Installez le patch ID 142245-01 sur le domaine de contrôle de la machine cible ou effectuez une mise à niveau vers, au minimum, le SE Oracle Solaris 10 10/09.
ID de bogue 15605806 : dans certaines situations, la migration échoue avec le message d'erreur, et la commande ldmd signale que la liaison de la mémoire nécessaire pour le domaine source est impossible. Cette situation peut se produire même si la quantité totale de mémoire disponible sur la machine cible est supérieure à celle utilisée par le domaine source (comme indiqué par ldm ls-devices -a mem).
Unable to bind 29952M memory region at real address 0x8000000 Domain Migration of LDom ldg0 failed
Cause : cet échec est causé par l'incapacité de satisfaire les exigences de congruence entre l'adresse réelle et l'adresse physique sur la machine cible.
Solution de contournement : arrêtez le domaine et effectuez une migration à froid. Vous pouvez également réduire la taille de la mémoire sur le domaine invité de 128 Mo, ce qui permet à la migration de s'effectuer pendant que le domaine est actif.
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 ldm ls-io -l.
ID de bogue 15591769 : lors de la création d'un LUN, vous pouvez l'ajouter au service de disque virtuel des domaines principal et secondaire à l'aide du même mpgroup. Pour indiquer quel domaine utiliser en premier lors de l'accès au LUN, ajoutez ce périphérique de service de disque virtuel en premier.
Pour utiliser le LUN de primary-vds0 en premier, exécutez les commandes suivantes :
primary# ldm add-vdsdev mpgroup=ha lun1@primary-vds0 primary# ldm add-vdsdev mpgoup=ha lun1@alternate-vds0 primary# ldm add-vdisk disk1 lun1@primary-vds0 gd0
Pour utiliser le LUN de alternate-vds0 en premier, exécutez les commandes suivantes :
primary# ldm add-vdsdev mpgroup=ha lun1@alternate-vds0 primary# ldm add-vdsdev mpgoup=ha lun1@primary-vds0 primary# ldm add-vdisk disk1 lun1@alternate-vds0 gd0
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 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. |
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.
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é.
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 :
Si le système est configuré avec un domaine primary contenant pci@500 et un second domaine contenant pci@400
Le périphérique e1000g de la structure pci@400 est utilisé pour initialiser le second domaine
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.
ID de bogue 15527921 : au cours d'une migration, le groupe de consoles et le port explicitement assignés sont ignorés, et une console avec les propriétés par défaut est créée pour le domaine cible. Cette console est créée en utilisant le nom du domaine cible comme groupe de consoles et un port disponible sur le premier concentrateur de console virtuelle (vcc) du domaine de contrôle. S'il y a un conflit avec le nom de groupe par défaut, la migration échoue.
Reprise : pour restaurer les propriétés de la console explicite à la suite d'une migration, dissociez le domaine cible et définissez manuellement les propriétés souhaitées à l'aide de la commande ldm set-vcons.
ID de bogue 15523133 : si le disque virtuel sur la machine cible ne pointe pas vers le même moteur de traitement de disque que celui utilisé sur la machine source, le domaine migré ne peut pas accéder au disque virtuel à l'aide du moteur de traitement de disque. L'accès au disque virtuel sur le domaine risque de se bloquer.
Actuellement, Logical Domains Manager vérifie uniquement que les noms des volumes de disque virtuel correspondent entre machines source et cible. Dans ce cas de figure, aucun message d'erreur n'est affiché si les moteurs de traitement de disque ne correspondent pas.
Solution de contournement : lors de la configuration du domaine cible pour recevoir un domaine migré, assurez-vous que le volume de disque (vdsdev) correspond au moteur de traitement de disque utilisé sur le domaine source.
Reprise : effectuez l'une des procédures suivantes si vous déterminez que le périphérique de disque virtuel sur la machine cible pointe vers un moteur de traitement de disque incorrect :
Migrez le domaine et corrigez le vdsdev.
Remigrez le domaine vers la machine source.
Corrigez le volume vdsdev sur la cible de sorte qu'il pointe vers le bon moteur de traitement de disque.
Remigrez le domaine vers la machine cible.
Arrêtez et dissociez le domaine sur la cible, puis corrigez le volume vdsdev. Si le système d'exploitation prend en charge la reconfiguration dynamique des E/S virtuelles et que le disque virtuel incorrect n'est pas utilisé sur le domaine (c.-à-d. qu'il ne s'agit pas du disque d'initialisation et qu'il est démonté), procédez comme suit :
Exécutez la commande ldm rm-vdisk pour supprimer le disque.
Corrigez le volume vdsdev.
Exécutez la commande ldm add-vdisk pour rajouter le disque virtuel.
ID de bogue 15523120 : dans certaines situations, la migration échoue et la commande ldmd signale que la liaison de la mémoire nécessaire pour le domaine source est impossible. Cela peut se produire même si la quantité totale de mémoire disponible sur la machine cible est supérieure à celle utilisée par le domaine source.
Cet échec se produit car la migration de plages de mémoire spécifiques utilisées par le domaine source nécessite que des plages de mémoire compatibles soient également disponibles sur la cible. Si aucune plage de mémoire compatible n'est trouvée pour une plage de mémoire donnée dans la source, la migration échoue.
Reprise : si vous rencontrez ce problème, essayez de migrer le domaine en modifiant l'utilisation de la mémoire sur la machine cible. Pour ce faire, dissociez n'importe quel domaine logique actif sur la cible.
Exécutez la commande ldm list-devices -a mem pour déterminer la quantité de mémoire disponible et son utilisation. Envisagez également de réduire la quantité de mémoire assignée à un autre domaine.
ID de bogue 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 15516245 : il peut arriver qu'un domaine logique actif semble être à l'état de transition au lieu de normal longtemps après avoir été initialisé ou à la suite de la migration de domaines. Ce problème mineur est anodin, et le domaine est entièrement fonctionnel. Pour déterminer quel indicateur est défini, consultez le champ flags dans la sortie de la commande ldm list -l -p ou le champ FLAGS de la commande ldm list, qui affiche -n---- pour normal ou -t---- pour transition.
Reprise : après la réinitialisation suivante, le domaine affiche l'état correct.
ID de bogue 15513998 : il arrive qu'il soit impossible de se connecter à la console d'un domaine qui vient d'être migré.
Solution de contournement : redémarrez le service SMF vntsd pour activer les connexions à la console :
# svcadm restart vntsd
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 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.
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.
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 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.
Reprise : Exécutez une commande ldm stop-domain ldom suivie d'une commande ldm start-domain ldom sur le domaine invité (ldom) en question.
ID de bogue 15387338 : ce problème est sommairement décrit dans la section Persistance des variables Logical Domains 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 ldom
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