Bogues liés au logiciel 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.

Remarque - Certains bogues décrits dans cette section ont été résolus depuis la version Oracle VM Server for SPARC 3.1. Les notes concernant ces bogues sont toutefois conservées pour les utilisateurs exécutant encore la version 3.1 d'Oracle VM Server for SPARC.

Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1.2

Panne système lors de l'application de la contrainte whole-core à un domaine `primary` à coeur partiel

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.

La commande `format` se bloque après la migration d'un domaine invité ou une console de domaine invité ne tire pas parti des entrées

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.

Les zones de noyau bloquent la migration en direct des domaines hôtes

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
```

Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1.1

La migration en direct peut échouer avec le message `Unable to restore ldc resource state on target Domain Migration of LDom failed`

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.

Le mode de récupération échoue avec la commande `ldmd` en mode de maintenance lorsque le commutateur virtuel net-dev manque

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.

La migration vers un système SPARC M5 ou SPARC T5 peut paniquer avec le message `suspend: get stick freq failed`

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.

Le Logical Domains Manager n'empêche pas la création de dépendances circulaires

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.

Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1

De très grands nombres de LDC peuvent entraîner des problèmes relatifs à Oracle Solaris dans les domaines invités.

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

La fonction physique Fibre Channel est défaillante et désactivée par FMA

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.

Problèmes de protocole de transfert LDC de réseau virtuel en cas d'un nombre important de périphériques de réseau virtuel

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 N² 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.

Le microprogramme des cartes Sun Storage 16 Gb Fibre Channel Universal HBA ne prend pas en charge les contrôles de la bande passante

ID de bogue 18083904 : le microprogramme des cartes Sun Storage 16 Gb Fibre Channel Universal HBA, Emulex ne prend pas en charge la configuration des contrôles de la bande passante. Le microprogramme du HBA ignore les valeurs que vous indiquez pour la propriété bw-percent.

Solution de contournement : aucune.

L'ajout de mémoire après une migration entre plusieurs CPU peut provoquer une panique du domaine invité

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.

Chemin de périphérique incorrect pour les fonctions virtuelles Fibre Channel dans un domaine root

ID de bogue 18001028 : dans le domaine root, le chemin de périphérique Oracle Solaris d'une fonction virtuelle Fibre Channel est incorrect.

Par exemple, le nom de chemin incorrect est pci@380/pci@1/pci@0/pci@6/fibre-channel@0,2, alors qu'il devrait être pci@380/pci@1/pci@0/pci@6/SUNW,emlxs@0,2.

La sortie ldm list-io -l présente le chemin de périphérique correct pour les fonctions virtuelles Fibre Channel.

Solution de contournement : aucune.

`ldmd` vide le coeur lors de la tentative d'association d'un domaine en état d'association ou de dissociation

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.

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

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.

Impossible de démarrer le service `ldmd` en raison d'un retard de la création de `virtual-channel@0:hvctl`

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.

Affinité médiocre sur le domaine de contrôle lorsque vous affectez de la mémoire avant d'affecter des CPU dans le cadre d'une reconfiguration retardée

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

Impossible d'installer le SE Oracle Solaris 11.1 à l'aide d'une étiquette de disque GPT EFI sur un disque virtuel à tranche unique.

ID de bogue 17422973 : l'installation du SE Oracle Solaris 11.1 sur un disque à tranche unique risque d'échouer avec l'erreur suivante sur un serveur SPARC T4 exécutant 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.

Après sa migration, un domaine peut paniquer lors de l'initialisation après avoir été démarré ou réinitialisé

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.

La taille du tampon de description de la machine préallouée est utilisée lors de la migration

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

La tentative de redimensionnement des CPU virtuelles d'un domaine invité en cas de réussite de l'opération de reconfiguration de coeur peut échouer

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.

Oracle Solaris 10 : un domaine root non `primary` se bloque à l'initialisation lors d'une réinitialisation de `primary` si `failure-policy=reset`

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.

Un blocage du réseau virtuel empêche la migration de domaine

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.

Remarque - Cette commande déclenche une reconfiguration retardée si ldom est primary. Dans tous les autres cas, arrêtez le domaine avant d'exécuter cette commande.

primary# ldm set-domain extended-mapin-space=on ldom

La sortie `ldmpower` n'inclut pas toujours les horodatages

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.

`mac_do_softlso` abandonne les paquets LSO

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

Echec de la migration : `Invalid Shutdown-group: 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.

La configuration enregistrée automatiquement n'est pas mise à jour après la suppression d'une fonction virtuelle ou d'un périphérique PCIe

ID de bogue 17051532 : lorsqu'un périphérique PCIe ou une fonction virtuelle est supprimé d'un domaine invité, la configuration enregistrée automatiquement n'est pas mise à jour. Ce problème peut entraîner la réapparition du périphérique ou de fonction virtuelle dans le domaine invité une fois l'enregistrement automatique récupéré, à savoir autorecovery_policy=3. Ce problème peut également entraîner l'échec de la commande ldm add-spconfig -r et l'affichage du message Autosave configuration config-name is invalid si vous n'exécutez pas une autre commande ldm déclenchant la mise à jour de l'enregistrement automatique.

Solution de contournement : effectuez l'une des opérations suivantes :

Enregistrez une nouvelle configuration une fois que vous avez supprimé le périphérique PCIe ou la fonction virtuelle.
```
primary# ldm add-config new-config-name
```
Actualisez la configuration enregistrée suite à la suppression du périphérique PCIe ou de la fonction virtuelle en supprimant puis en recréant la configuration.
```
primary# ldm rm-config config-name
primary# ldm add-config config-name
```
Notez que ce bogue empêche le bon fonctionnement de la commande ldm add-config -r config-name.
Exécutez une autre commande ldm qui entraîne une mise à jour de l'enregistrement automatique telle que ldm set-vcpu, ldm bind ou ldm unbind.

L'échec de la commande `ldmp2v convert` provoque une mise à niveau en boucle

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

Les migrations de domaines à partir de systèmes SPARC T4 exécutant le microprogramme système 8.3 vers des systèmes SPARC T5, SPARC M5 ou SPARC M6 sont autorisées à tort

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).

Panique de domaine invité à `lgrp_lineage_add(mutex_enter: bad mutex, lp=10351178)`

ID de bogue 17020950 : après la migration d'un domaine actif à partir d'une plate-forme SPARC T4 vers une plate-forme SPARC T5, SPARC M5 ou SPARC M6 liée à l'aide de la version 8.3 du microprogramme, une opération de reconfiguration dynamique peut entraîner la panique d'un domaine invité.

Solution de contournement : avant d'effectuer la migration, mettez à jour le système SPARC T4 avec la version 8.4 du microprogramme système. Ensuite, associez à nouveau le domaine.

Domaines invités en état de transition après la réinitialisation du domaine `primary`

ID de bogue 17020481 : un domaine invité est en état de transition (t) après la réinitialisation du domaine primary. Ce problème se produit lorsqu'un grand nombre de fonctions virtuelles sont configurées sur le système.

Solution de contournement : pour éviter ce problème, tentez à nouveau d'exécuter la commande d'initialisation des disques OBP plusieurs fois, ce qui permet d'éviter une initialisation à partir du réseau.

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
```

Dans de rares circonstances, une panique se produit lorsque le pilote du périphérique réseau virtuel fonctionne en mode `TxDring`

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.

Remarque - Cette commande déclenche une reconfiguration retardée si ldom est primary. Dans tous les autres cas, arrêtez le domaine avant d'exécuter cette commande.

primary# ldm set-domain extended-mapin-space=on ldom

Les domaines auxquels une seule CPU virtuelle a été assignée peuvent paniquer lors d'une migration en direct

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.

La commande `ldm migrate -n` devrait échouer en cas de migration de CPU à CPU à partir d'un système SPARC T5, SPARC M5 ou SPARC M6 vers un système UltraSPARC T2 ou SPARC T3

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.

Le mode de récupération devrait prendre en charge la suppression d'emplacements PCIe dans les domaines root non `primary`

ID de bogue 16713362 : à l'heure actuelle, les emplacements PCIe ne peuvent pas être supprimés des domaines root non primary pendant une opération de récupération. Les emplacements PCIe restent assignés au domaine root non primary.

Solution de contournement : les emplacements PCIe doivent être supprimés manuellement à partir du domaine root non primary et assignés au(x) domaine(s) d'E/S approprié(s) une fois l'opération de récupération terminée.

Pour plus d'informations sur la suppression d'emplacements PCIe à partir d'un domaine 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.

`ldm list` n'affiche pas la propriété `evacuated` pour les périphériques d'E/S physiques

ID de bogue 16617981 : la sortie ldm list n'affiche pas la propriété evacuated pour les périphériques d'E/S physiques.

Solution de contournement : utilisez l'option –p avec n'importe laquelle des commandes ldm list afin d'afficher la propriété evacuated pour les périphériques d'E/S physiques.

Une adresse physique non valide est reçue pendant la migration d'un domaine

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.

La panique `send_mondo_set: timeout` se produit en cas d'utilisation de la commande `ldm stop` sur un domaine invité soumis à une charge de travail importante

ID de bogue 16486383 : ce problème peut se produire si vous affectez directement un périphérique ou bus PCI à un domaine invité auquel aucun coeur n'a été attribué à partir du /SYS/DCU où la carte PCI réside physiquement. Etant donné que l'hyperviseur réinitialise les périphériques PCI pour le compte des domaines invités, il est possible qu'au cours de chaque réinitialisation de domaine invité, un domaine comportant des coeurs sur le DCU connecté au périphérique PCI panique. Lorsque plusieurs périphériques PCI sont affectés à des invités non-DCU-local, le risque de panique augmente.

Solution de contournement : effectuez l'une des opérations suivantes :

Assurez-vous que lorsque vous affectez des périphériques PCI à un domaine invité, la carte se trouve physiquement dans le même DCU que les coeurs.
Affectez manuellement les coeurs afin de disposer d'une certaine flexibilité pour le placement de la carte.

Par exemple, pour un périphérique PCI sur IOU0 (pci_0 à pci_15), choisissez un coeur entre 0 et 127 et allouez-le au domaine.
```
# ldm add-core cid=16 domain
```
Visualisez les coeurs du système à l'aide de la commande suivante :
```
# ldm ls-devices -a core
```
Pour un périphérique PCI sur IOU1 (pci_16 à pci_31), choisissez un coeur entre 128 et 255. Pour un périphérique PCI sur IOU2 (pci_32 à pci_47), choisissez un coeur entre 256 et 383. Pour un périphérique PCI sur IOU3 (pci_48 à pci_63), choisissez un coeur entre 384 et 511.

Des sous-périphériques subordonnés à un périphérique PCIe retournent à l'état "sans nom"

ID de bogue 16299053 : lorsque vous désactivez un périphérique PCIe, un comportement inattendu peut s'ensuivre. Les sous-périphériques subordonnés au périphérique PCIe désactivé retournent à l'état "sans nom" tandis que le périphérique PCIe est toujours la propriété du domaine.

Solution de contournement : si vous décidez de désactiver un emplacement PCIe sur ILOM, assurez-vous que l'emplacement PCIe n'est pas affecté à un domaine à l'aide de la fonction d'E/S directes (DIO). En d'autres termes, assurez-vous d'abord que l'emplacement PCIe est affecté au domaine root correspondant avant de désactiver l'emplacement sur ILOM.

Si vous désactivez l'emplacement PCIe sur ILOM alors que l'emplacement PCIe est affecté à un domaine avec DIO, arrêtez le domaine concerné et réaffectez le périphérique au domaine root pour que le comportement soit normal.

Le message `WARNING: ddi_intr_alloc: cannot fit into interrupt pool` signifie que l'approvisionnement d'interruptions est épuisé lorsque les pilotes de périphériques d'E/S ont été joints

ID de bogue 16284767 : cet avertissement sur la console Oracle Solaris signifie que l'approvisionnement d'interruptions a été épuisé lorsque les pilotes de périphériques d'E/S ont été joints :

WARNING: ddi_intr_alloc: cannot fit into interrupt pool

Le matériel fournit un nombre défini d'interruptions, Oracle Solaris limite donc le nombre d'interruptions que chaque périphérique peut utiliser. Une limite par défaut est conçue pour répondre aux besoins des configurations système classiques. Cependant, cette limite peut nécessiter des ajustements pour certaines configurations système.

Plus précisément, la limite peut nécessiter des ajustements si le système est divisé en plusieurs domaines logiques et si un nombre trop important de périphériques d'E/S est assigné à un domaine invité. Oracle VM Server for SPARC divise le total des interruptions en ensembles plus petits assignés à des domaines invités. Si un nombre trop important de périphériques d'E/S est assigné à un domaine invité, ses approvisionnements risquent d'être trop faibles pour assigner à chaque périphérique la limite par défauts d'interruptions. Son approvisionnement s'épuise donc avant d'être entièrement associé à tous les pilotes.

Certains pilotes fournissent une routine de rappels facultatifs qui permet à Oracle Solaris d'ajuster automatiquement leurs interruptions. La limite par défaut ne s'applique pas à ces pilotes.

Solution de contournement : utilisez les macros MDB ::irmpools and ::irmreqs pour déterminer l'utilisation des interruptions. La macro ::irmpools affiche l'approvisionnement global des interruptions divisées en pools. La macro ::irmreqs affiche les périphériques qui sont mappés vers chaque pool. Pour chaque périphérique, ::irmreqs affiche si la limite par défaut est appliquée par une routine de rappels facultatifs, le nombre d'interruptions demandées par chaque pilote et le nombre d'interruptions accordées au pilote.

Les macros n'affichent pas d'informations sur les pilotes qui n'ont pas pu être joints. Toutefois, les informations affichées permettent de calculer dans quelle mesure vous pouvez ajuster la limite par défaut. Un périphérique qui utilise plus d'une interruption sans fournir de routine de rappels peut être forcé d'utiliser moins d'interruptions en ajustant la limite par défaut. La réduction de la limite par défaut à un niveau inférieur à celui est utilisé par un tel périphérique peut se traduire par la libération d'interruptions en vue d'une utilisation par d'autres périphériques.

Pour ajuster la limite par défaut, définissez la propriété ddi_msix_alloc_limit sur une valeur comprise entre 1 to 8 dans le fichier /etc/system. Réinitialisez ensuite le système pour que la modification prenne effet.

Pour optimiser les performances, commencez par affecter de grandes valeurs et réduisez les valeurs par petits incréments jusqu'à la réussite de l'initialisation du système, sans avertissements. Utilisez les macros ::irmpools et ::irmreqs pour mesurer l'impact de l'ajustement sur tous les pilotes joints.

Par exemple, supposez que les avertissements suivants sont émis lors de l'initialisation du SE Oracle Solaris dans un domaine invité :

WARNING: emlxs3: interrupt pool too full.
WARNING: ddi_intr_alloc: cannot fit into interrupt pool

Les macros ::irmpools et ::irmreqs affichent les informations suivantes :

# echo "::irmpools" | mdb -k
ADDR             OWNER   TYPE   SIZE  REQUESTED  RESERVED
00000400016be970 px#0    MSI/X  36    36         36

# echo "00000400016be970::irmreqs" | mdb -k
ADDR             OWNER   TYPE   CALLBACK NINTRS NREQ NAVAIL
00001000143acaa8 emlxs#0 MSI-X  No       32     8    8
00001000170199f8 emlxs#1 MSI-X  No       32     8    8
000010001400ca28 emlxs#2 MSI-X  No       32     8    8
0000100016151328 igb#3   MSI-X  No       10     3    3
0000100019549d30 igb#2   MSI-X  No       10     3    3
0000040000e0f878 igb#1   MSI-X  No       10     3    3
000010001955a5c8 igb#0   MSI-X  No       10     3    3

La limite par défaut dans cet exemple comporte huit interruptions par périphérique, ce qui n'est pas suffisant pour stocker la pièce jointe du périphérique emlxs3 sur le système. En supposant que toutes les instances emlxs se comportent de la même manière, emlxs3 a probablement demandé 8 interruptions.

En soustrayant les 12 interruptions utilisées par tous les périphériques igb de la taille totale du pool des 36 interruptions, 24 interruptions sont disponibles pour les périphériques emlxs. La division des 24 interruptions par 4 suggère que 6 interruptions par périphérique permettent à tous les périphériques emlxs de se joindre avec des performances égales. L'ajustement suivant est ainsi ajouté au fichier /etc/system :

set ddi_msix_alloc_limit = 6

Lorsque le système réussit à s'initialiser sans avertissement, les macros ::irmpools et ::irmreqs affichent les informations mises à jour suivantes :

# echo "::irmpools" | mdb -k
ADDR             OWNER   TYPE   SIZE  REQUESTED  RESERVED
00000400018ca868 px#0    MSI/X  36    36         36
 
# echo "00000400018ca868::irmreqs" | mdb -k
ADDR             OWNER   TYPE   CALLBACK NINTRS NREQ NAVAIL
0000100016143218 emlxs#0 MSI-X  No       32     8    6
0000100014269920 emlxs#1 MSI-X  No       32     8    6
000010001540be30 emlxs#2 MSI-X  No       32     8    6
00001000140cbe10 emlxs#3 MSI-X  No       32     8    6
00001000141210c0 igb#3   MSI-X  No       10     3    3
0000100017549d38 igb#2   MSI-X  No       10     3    3
0000040001ceac40 igb#1   MSI-X  No       10     3    3
000010001acc3480 igb#0   MSI-X  No       10     3    3

SPARC M5-32 et SPARC M6-32 : `panic: mpo_cpu_add: Cannot read MD`

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.

SPARC M5-32 et SPARC M6-32 : problème lié aux disques accessibles via plusieurs chemins d'E/S directs

ID de bogue 16232834 : lorsque vous utilisez la commande ldm add-vcpu pour assigner des CPU à un domaine, le SE Oracle Solaris peut paniquer avec affichage du message suivant :

panic[cpu16]/thread=c4012102c860: mpo_cpu_add: Cannot read MD

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
```

Le périphérique `ixgbevf` des domaines SR-IOV risque d'être désactivé après la réinitialisation du domaine `primary`

ID de bogue 16224353 : après avoir réinitialisé le domaine primary, les instances ixgbevf du domaine primary risquent de ne pas fonctionner.

Solution de contournement : aucune.

Après la réinitialisation du domaine `primary` d'Oracle Solaris 10 1/13, une interface de fonction virtuelle risque de ne pas être automatiquement raccordée ou de ne pas se voir attribuer d'adresse IP

ID de bogue 16219069 : sur un domaine primary exécutant le SE Oracle Solaris 10 1/13, les interfaces de fonction virtuelle risquent de ne pas être automatiquement raccordées ou de ne pas se voir attribuer d'adresse IP sur la base du fichier /etc/hostname.vf-interface.

Ce problème se produit lorsque vous initialisez ou réinitialisez un système SPARC T3, SPARC T4 ou SPARC T5 exécutant le SE Oracle Solaris 10 1/13 sur le domaine primary. Ce problème affecte les fonctions virtuelles créées sur les fonctions physiques intégrées et sur les fonctions physiques additionnelles. Ce problème ne se produit pas lorsque vous initialisez une image de domaine invité Logical Domains.

Oracle Solaris 10 uniquement : `mutex_enter: bad mutex` panique dans le domaine `primary` lors de la réinitialisation ou de l'arrêt

ID de bogue 16080855 : lors d'une réinitialisation ou d'un arrêt du domaine primary, le domaine primary peut subir une panique du noyau avec un message semblable au suivant :

panic[cpu2]/thread=c40043b818a0: mutex_enter: bad mutex, lp=c4005fa01c88
owner=c4005f70aa80 thread=c40043b818a0

000002a1075c3630 ldc:ldc_mem_rdwr_cookie+20 (c4005fa01c80,
c4004e2c2000,2a1075c37c8, 6c80000, 1, 0)
%l0-3: 00000000001356a4 0000000000136800 0000000000000380
00000000000002ff
%l4-7: 00000000001ad3f8 0000000000000004 00000000ffbffb9c
0000c4005fa01c88
000002a1075c3710 vldc:i_vldc_ioctl_write_cookie+a4 (c4004c400030,
380,ffbff898, 100003, 0, 70233400)
%l0-3: 0000000006c80000 0000000000156dc8 0000000000000380
0000000000100003
%l4-7: 00000000702337b0 000002a1075c37c8 0000000000040000
0000000000000000
000002a1075c37f0 vldc:vldc_ioctl+1a4 (3101, c4004c400030,
ffbff898,c4004c400000, c4004c438030, 0)
%l0-3: 0000000000100003 0000000000000000 000000007b340400
0000c4004c438030
%l4-7: 0000c4004c400030 0000000000000000 0000000000000000
0000000000000000
000002a1075c38a0 genunix:fop_ioctl+d0 (c4004d327800, 0, ffbff898,
100003,c4004384f718, 2a1075c3acc)
%l0-3: 0000000000003103 0000000000100003 000000000133ce94
0000c4002352a480
%l4-7: 0000000000000000 0000000000000002 00000000000000c0
0000000000000000
000002a1075c3970 genunix:ioctl+16c (3, 3103, ffbff898, 3, 134d50, 0)
%l0-3: 0000c40040e00a50 000000000000c6d3 0000000000000003
0000030000002000
%l4-7: 0000000000000003 0000000000000004 0000000000000000
0000000000000000

Reprise : autorisez le domaine primary à se réinitialiser. Si le domaine primary est configuré pour ne pas se réinitialiser après un arrêt brutal, initialisez-le manuellement.

SPARC M5-32 et SPARC M6-32 : le contrôleur LSI-SAS est exporté de façon incorrecte avec SR-IOV

ID de bogue 16071170 : sur un système SPARC M5-32 ou SPARC M6-32, les contrôleurs SAS internes sont exportés en tant que contrôleurs SR-IOV bien que ces cartes ne prennent pas en charge SR-IOV.

Le journal d'Oracle VM Server for SPARC consigne les messages suivants lors de la tentative de création de la fonction physique sur ces cartes :

Dec 11 04:27:54 warning: Dropping pf
pci@d00/pci@1/pci@0/pci@0/pci@0/pci@4/LSI,sas@0: no IOV capable driver
Dec 11 04:27:54 warning: Dropping pf
pci@d80/pci@1/pci@0/pci@c/pci@0/pci@4/LSI,sas@0: no IOV capable driver
Dec 11 04:27:54 warning: Dropping pf
pci@c00/pci@1/pci@0/pci@c/pci@0/pci@4/LSI,sas@0: no IOV capable driver
Dec 11 04:27:54 warning: Dropping pf
pci@e00/pci@1/pci@0/pci@0/pci@0/pci@4/LSI,sas@0: no IOV capable driver

Le système est doté de quatre ports de contrôleur SAS LSI, chacun situé dans un IOU de l'assemblage SPARC M5-32 et SPARC M6-32. Cette erreur est signalée pour chaque port.

Solution de contournement : vous pouvez ignorer ces messages. Ces messages indiquent seulement que les contrôleurs SAS LSI du système sont compatibles avec SR-IOV, mais qu'aucune prise en charge de SR-IOV n'est disponible pour ce matériel.

SPARC T5-8 : les données de temps de disponibilité affichent une valeur nulle pour certaines commandes de liste `ldm`

ID de bogue 16068376 : sur un système T5-8 comprenant approximativement 128 domaines, certaines commandes ldm telles que ldm list peuvent afficher 0 seconde comme temps de disponibilité de tous les domaines.

Solution de contournement : connectez-vous au domaine et utilisez la commande uptime pour déterminer le temps de disponibilité du domaine.

Impossible de définir un MTU Jumbo pour les fonctions virtuelles `sxge` dans le domaine `primary` d'un système SPARC T5-1B

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é.

`ldmd` ne peut pas définir les valeurs des propriétés `mac-addr` et `alt-mac-addr` pour le périphérique `sxge`

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.

Deux propriétés sont manquantes dans la sortie `ldm list-io -d` d'un périphérique `sxge` sur SPARC T5-1B

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.

`ldm` ne parvient pas à évacuer un coeur défectueux d'un domaine invité

ID de bogue 15962837 : une évacuation de coeur ne se termine pas lorsqu'une panne se produit au niveau de la puce. Une évacuation qui est suivie d'une panne de coeur fonctionne correctement, mais la panne au niveau de la puce ne prend pas fin lorsque vous essayez de retirer un noeud CMP complet.

Solution de contournement : aucune. Planifiez le remplacement de la puce lorsque vous diagnostiquez une panne au niveau de celle-ci.

Les opérations de DR de mémoire se bloquent lorsque la mémoire est réduite à moins de quatre giga-octets

ID de bogue 15942036 : si vous effectuez une opération de DR de la mémoire pour réduire la mémoire à moins de quatre giga-octets, l'opération risque de se bloquer indéfiniment. Si vous exécutez une commande ldm cancel-op memdr sur ce domaine, un message incorrect est émis :

The memory removal operation has completed. You cannot cancel this operation.

Malgré ce message, l'opération de DR de mémoire se bloque et vous risquez de ne pas être en mesure d'effectuer d'autres opérations ldmd sur le domaine invité concerné.

Solution de contournement : ne tentez de réduire la mémoire à moins de quatre giga-octets dans aucun domaine. Si vous êtes déjà dans cet état, exécutez la commande ldm stop -f ou connectez-vous au domaine et réinitialisez-le.

La reconfiguration dynamique de CPU d'un très grand nombre de CPU virtuelles peut échouer

ID de bogue 15826354 : la reconfiguration dynamique (DR) d'un très grand nombre de CPU entraîne le renvoi d'un échec par le démon ldmd. Bien que ldmd arrive à expiration, l'opération de reconfiguration dynamique continue en arrière-plan et finit par aboutir. Néanmoins, ldmd n'est plus aligné avec le domaine résultant et les opérations de reconfiguration dynamique ultérieures risquent de ne pas être autorisées.

Par exemple :

# ldm ls
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  NORM  UPTIME
primary          active     -n-cv-  UART    7     20G      2.7%  0.4%  1h 41m
ldg0             active     -n----  5000    761   16G       75%   51%  6m

# ldm rm-vcpu 760 ldg0
Request to remove cpu(s) sent, but no valid response received
VCPU(s) will remain allocated to the domain, but might
not be available to the guest OS
Resource removal failed
 
# ldm set-vcpu 1 ldg0
Busy executing earlier command; please try again later.
Unable to remove the requested VCPUs from domain ldg0
Resource modification failed
 
# ldm ls
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  NORM  UPTIME
primary          active     -n-cv-  UART    7     20G      0.9%  0.1%  1h 45m
ldg0             active     -n----  5000    761   16G      100%  0.0%  10m

Solution de contournement : attendez quelques minutes, puis réexécutez la commande ldm set-vcpu :

# ldm set-vcpu 1 ldg0
# ldm ls
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  NORM  UPTIME
primary          active     -n-cv-  UART    7     20G      0.9%  0.1%  1h 50m
ldg0             active     -n----  5000    1     16G       52%  0.0%  15m

Notez que 760 dépasse le maximum recommandé.

Le délai d'attente de la migration d'un domaine invité avec réseaux virtuels HIO et `cpu-arch=generic` expire lors de l'attente de la suspension du domaine

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.

SPARCT4-4 : impossible d'associer un domaine invité

ID de bogue 15825330 : Oracle VM Server for SPARC se bloque au démarrage de certaines configurations SPARC T4-4 comportant une seule carte de processeur.

Solution de contournement : assurez-vous qu'il y a toujours une carte processeur dans les emplacements dédiés aux processeurs 0 et 1. Le redémarrage du système dans une configuration de ce type permet au logiciel Oracle VM Server for SPARC de démarrer.

Panique du domaine invité lorsque la propriété threading est modifiée de `max-throughput` à `max-ipc`

ID de bogue 15821246 : sur un système qui exécute le SE Oracle Solaris 11.1, la modification de la valeur de la propriété threading sur un domaine migré de max-ipc à max-throughput peut entraîner une panique sur le domaine invité.

Solution de contournement : ne modifiez pas le statut de la propriété threading d'un domaine invité tant qu'il n'a pas été réinitialisé.

Le domaine de contrôle se bloque lors d'une réinitialisation avec deux domaines d'E/S directs actifs

ID de bogue 15820741 : sur un système Oracle Solaris 11.1 comportant deux domaines avec des configurations d'E/S directes, le domaine de contrôle peut se bloquer lors de la réinitialisation.

Reprise : pour effectuer une reprise après un blocage de la réinitialisation, effectuez une remise à zéro du domaine de contrôle en lançant la commande suivante sur le processeur de service :

-> reset -f /HOST/domain/control

Absence d'un message d'erreur lorsqu'un ajout de reconfiguration dynamique de mémoire est en partie réussi

ID de bogue 15812823 : dans les cas où la mémoire restante est faible, les blocs de mémoire ne peuvent pas tous être utilisés pour l'opération de DR de la mémoire en raison d'espace mémoire insuffisant. Cependant, ces blocs de mémoire sont inclus dans l'espace de mémoire libre. La situation peut conduire à ce qu'une quantité moins importante que prévu soit ajoutée au domaine. Aucun message d'erreur n'apparaît lorsque cette situation se produit.

Solution de contournement : aucune.

Panique du domaine primary ou invité en cas de migration ou d'annulation de la liaison d'un domaine invité comportant des périphériques réseau d'E/S hybrides

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.

Echec de la recréation d'un domaine avec des fonctions virtuelles PCIe à partir d'un fichier XML

ID de bogue 15783851 : un problème peut survenir lors de la recréation d'une configuration à partir d'un fichier XML représentant de façon incorrecte les contraintes de la fonction virtuelle.

Ce problème survient lorsque vous utilisez la commande ldm list-constraints -x pour enregistrer la configuration d'un domaine possédant des fonctions virtuelles PCIe.

Si vous recréez ultérieurement le domaine à l'aide de la commande ldm add-domain -i, les fonctions virtuelles d'origine n'existent pas, une tentative de liaison de domaine échoue et le message d'erreur suivant s'affiche :

No free matching PCIe device...

Même si vous créez les fonctions virtuelles manquantes, une autre tentative de liaison de domaine échoue et contient les mêmes messages d'erreur car les fonctions virtuelles sont déclassées en tant que périphériques PCIe par la commande ldm add-domain.

Solution de contournement : effectuez les opérations suivantes :

Enregistrez les informations relatives aux fonctions virtuelles à l'aide de la commande ldm list-io.
Détruisez chaque domaine affecté à l'aide de la commande ldm rm-dom.
Créer toutes les fonctions virtuelles requises à l'aide de la commande ldm create-vf.
Regénérez les domaines à l'aide de la commande ldm.

Lorsque vous utilisez la commande ldm add-io pour ajouter chaque fonction virtuelle, cette dernière est correctement classée en tant que périphérique de fonction virtuelle afin de pouvoir détecter le domaine.

Pour plus d'informations sur la regénération d'une configuration de domaine utilisant des fonctions virtuelles, reportez-vous à la section La commande ldm init-system peut ne pas correctement restaurer une configuration de domaine sur lesquels des modifications d'E/S physiques ont été apportées.

Emission de messages d'erreur incorrects lorsque le domaine de contrôle utilise des coeurs partiels au lieu de coeurs complets

ID de bogue 15783608 : lorsque vous faites basculer le domaine de contrôle d'une utilisation de coeurs physiquement limités à une utilisation de ressources de CPU non limitées, le message superflu suivant peut s'afficher :

Whole-core partitioning has been removed from domain primary,because
dynamic reconfiguration has failed and the domain is now configured
with a partial CPU core.

Solution de contournement : vous pouvez ignorer ce message.

La commande `ldm init-system` peut ne pas correctement restaurer une configuration de domaine sur lesquels des modifications d'E/S physiques ont été apportées

ID de bogue 15783031 : vous risquez de rencontrer des problèmes lorsque vous utilisez la commande ldm init-system pour restaurer une configuration de domaine qui a utilisé des opérations d'E/S directes ou SR-IOV.

Un 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.

Arrêt brutal et redémarrage possibles de Logical Domains Manager en cas de modification simultanée de nombreux domaines

ID de bogue 15782994: Logical Domains Manager risque de s'arrêter brutalement et de redémarrer si vous tentez une opération concernant de nombreux domaines. Ce problème risque de se produire lorsque vous tentez d'apporter des modifications à la configuration de la mise en réseau virtuelle et qu'un grand nombre de périphériques réseau virtuels est situé sur le même commutateur virtuel dans plusieurs domaines. En règle générale, ce problème survient lorsque environ 90 domaines ou plus possèdent des périphériques réseau virtuels connectés au même commutateur virtuel et que la propriété inter-vnet-link est activée (le comportement par défaut). Confirmez le diagnostic en recherchant le message suivant dans le fichier journal ldmd et un fichier core dans le répertoire /var/opt/SUNWldm

Frag alloc for 'domain-name'/MD memory of size 0x80000 failed

Solution de contournement : évitez de créer un trop grand nombre de périphériques de réseau virtuel connectés au même commutateur virtuel. Le cas échéant, définissez la propriété inter-vnet-link sur off dans le commutateur virtuel. N'oubliez pas que cette option risque d'avoir une incidence négative sur les performances du réseau entre les domaines invités.

La commande `ldm list -o` n'accepte plus les abréviations pour format

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).

Domaine de contrôle nécessitant le coeur le plus bas du système

ID de bogue 15778392 : le domaine de contrôle requiert le coeur le plus bas du système. Par conséquent, si l'ID coeur 0 est le coeur le plus bas, il ne peut pas être partagé avec un autre domaine si vous souhaitez appliquer la contrainte whole-core au domaine de contrôle.

Par exemple, si le coeur le plus bas dans le système est l'ID coeur 0, le domaine de contrôle doit ressembler à la sortie suivante :

# ldm ls -o cpu primary
NAME
primary

VCPU
VID    PID    CID    UTIL STRAND
0      0      0      0.4%   100%
1      1      0      0.2%   100%
2      2      0      0.1%   100%
3      3      0      0.2%   100%
4      4      0      0.3%   100%
5      5      0      0.2%   100%
6      6      0      0.1%   100%
7      7      0      0.1%   100%

Non-réactivité des commandes `ldm` exécutées sur le système cible après annulation d'une migration

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.

Non-fonctionnement de certaines cartes Emulex lorsqu'elles sont assignées à un domaine d'E/S

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.

Panique du domaine invité lors de l'exécution de la commande `cputrack` lors de l'une migration vers un système SPARC T4

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.

Oracle Solaris 11 : signalement d'usurpation et d'échec RD Oracle Solaris par les DRM

ID de bogue 15775668 : un domaine doté d'une stratégie de priorité supérieure peut voler des ressources de CPU virtuelles à partir d'une stratégie de priorité inférieure. Pendant que cette action de "vol" est en cours, les messages d'avertissement suivants peuvent s'afficher dans le journal ldmd toutes les 10 secondes :

warning: Unable to unconfigure CPUs out of guest domain-name

Solution de contournement : vous pouvez ignorer ces messages qui vous induisent en erreur.

Limitation du nombre maximum de fonctions virtuelles qu'il est possible d'affecter à un domaine

ID de bogue 15775637 : un domaine d'E/S possède un nombre limité de ressources d'interruptions disponibles par complexe root.

Sur les systèmes SPARC T3 et SPARC T4, la limite est fixée à environ 63 vecteurs MSI/X. Chaque fonction virtuelle igb utilise trois interruptions. La fonction virtuelle ixgbe utilise deux interruptions.

Si vous affectez un grand nombre de fonctions virtuelles à un domaine, le domaine manque de ressources système pour prendre en charge ces périphériques. Des messages similaires au message suivant peuvent s'afficher :

WARNING: ixgbevf32: interrupt pool too full.
WARNING: ddi_intr_alloc: cannot fit into interrupt pool

Signalement, au terme de la migration, de temps de disponibilité aléatoires par un domaine invité recourant à la migration entre plusieurs CPU

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.

Oracle Solaris 10 : panique susceptible d'être entraînée par le pilote `ixgbe` lorsque l'initialisation se fait à partir d'une carte Intel Dual Port Ethernet Controller X540

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.

La console de domaine invité se bloque de manière aléatoire sur les systèmes SPARC T4

ID de bogue 15771384 : la console invitée d'un domaine est susceptible de se figer en cas de tentatives répétées pour vous connecter à la console avant et pendant l'opération de liaison de la console. Par exemple, ce problème peut se produire si vous utilisez un script automatisé pour saisir la console lorsqu'un domaine est en cours de migration sur la machine.

Solution de contournement : pour libérer la console, exécutez les commandes suivantes sur le domaine hôte qui héberge le concentrateur de console du domaine (habituellement le domaine de contrôle) :

primary# svcadm disable vntsd
primary# svcadm enable vntsd

Destruction de l'ensemble des fonctions virtuelles et renvoi des emplacements vers le domaine root n'entraînant aucune restauration des ressources de complexe root

ID de bogue 15765858 : les ressources situées sur le complexe root ne sont pas restaurées après la destruction de l'ensemble des fonctions virtuelles et le renvoi des emplacements vers le domaine root.

Solution de contournement : définissez l'option iov sur off pour le bus PCIe spécifique.

primary# ldm start-reconf primary
primary# ldm set-io iov=off pci_0

Désactivation conseillée de l'option `ldm remove-io` des cartes PCIe possédant des ponts PCIe vers PCI

ID de bogue 15761509 : utilisez uniquement les cartes PCIe prenant en charge la fonction d'E/S directes (DIO) qui sont répertoriées dans ce support document.

Solution de contournement : utilisez la commande ldm add-io pour rajouter la carte au domaine primary.

Echec probable de la commande `ldm stop` en cas d'émission immédiatement après une commande `ldm start`

ID de bogue 15759601 : si vous émettez une commande ldm stop immédiatement après une commande ldm start, la commande ldm stop risque d'échouer avec l'erreur suivante :

LDom domain stop notification failed

Solution de contournement : relancez la commande ldm stop.

`init-system` ne restaure pas les contraintes de coeur nommées pour les domaines invités à partir des fichiers XML enregistrés

ID de bogue 15758883 : la commande ldm init-system ne parvient pas à restaurer les contraintes de coeur des CPU nommés pour les domaines invités à partir d'un fichier XML enregistré.

Solution de contournement : effectuez les opérations suivantes :

Créez un fichier XML pour le domaine primary.

# ldm ls-constraints -x primary > primary.xml

Créez un fichier XML pour le ou les domaines invités.

# ldm ls-constraints -x 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
```

Panique du système lors de la réinitialisation d'un domaine `primary` possédant un très grand nombre de fonctions virtuelles affectées

ID de bogue 15750727 : un système peut paniquer lorsque vous réinitialisez un domaine primary auquel un très grand nombre de fonctions virtuelles est assigné.

Solution de contournement : effectuez l'une des opérations suivantes :

Diminuez le nombre de fonctions virtuelles pour réduire le nombre de fonctions virtuelles ayant échoué. Cette modification peut maintenir la puce active.
Créez plusieurs pools IRM (Interrupt Resource Management) pour la fonction virtuelle ixgbe étant donné qu'un seul pool IRM est créé par défaut pour toutes les fonctions virtuelles ixgbe sur le système.

Echec de l'autorisation des transitions DR whole-core par le coeur partiel `primary`

ID de bogue 15748348 : lorsque le domaine primary partage le coeur physique le plus bas (généralement 0) avec un autre domaine, toute tentative de définir la contrainte de coeur complet (whole-core) pour le domaine primary échoue.

Solution de contournement : effectuez les opérations suivantes :

Déterminez le coeur lié le plus bas partagé par les domaines.
```
# ldm list -o cpu
```
Dissociez tous les threads de CPU du coeur le plus bas de tous les domaines autres que le domaine primary.

Par conséquent, les threads de CPU du coeur le plus bas ne sont pas partagés et sont disponibles pour être liés au domaine primary.
Définissez la contrainte whole-core en effectuant l'une des opérations suivantes :
- Liez les threads de CPU au domaine primary et définissez la contrainte whole-core à l'aide de la commande ldm set-vcpu -c.
- Utilisez la commande ldm set-core pour lier les threads de CPU et définissez la contrainte whole-core en une seule étape.

Affichage de l'état UNK ou INV par la commande `ldm list-io` après l'initialisation

ID de bogue 15738561 : la commande ldm list-io peut afficher l'état UNK ou INV pour les emplacements PCIe et les fonctions virtuelles SR-IOV si la commande s'exécute immédiatement après l'initialisation du domaine primary. Ce problème est causé par le délai de la réponse de l'agent Logical Domains à partir du SE Oracle Solaris.

Ce problème a uniquement été signalé sur un nombre limité de systèmes.

Solution de contournement : l'état des emplacements PCIe et les fonctions virtuelles sont automatiquement mis à jour après réception des informations par l'agent Logical Domains.

La migration d'un domaine à mémoire très volumineuse sur un serveur SPARC T4-4 a pour effet de paniquer le domaine sur le système cible

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.

Echec de la suppression d'un grand nombre de CPU d'un domaine invité

ID de bogue ID 15726205 : le message d'erreur suivant peut s'afficher lorsque vous tentez de supprimer un grand nombre de CPU d'un domaine invité.

Request to remove cpu(s) sent, but no valid response received
VCPU(s) will remain allocated to the domain, but might
not be available to the guest OS
Resource modification failed

Solution de contournement : arrêtez le domaine invité avant de supprimer plus de 100 CPU.

Impossible d'utiliser les opérations d'enfichage à chaud d'Oracle Solaris pour supprimer à chaud un périphérique d'extrémité PCIe

ID de bogue 15721872 : vous ne pouvez pas utiliser les opérations d'enfichage à chaud Oracle Solaris pour supprimer à chaud un périphérique d'extrémité PCIe lorsque celui-ci a été supprimé du domaine primary à l'aide de la commande ldm rm-io. Pour savoir comment remplacer ou retirer un périphérique d'extrémité PCIe, reportez-vous à la section Procédure de modification matérielle PCIe du manuel Guide d’administration d’Oracle VM Server for SPARC 3.1 .

Panique de la commande `nxge` lors de la migration d'un domaine invité comportant des périphériques réseau virtuels d'E/S virtuels et hybrides

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

Blocage de toutes les commandes `ldm` lorsque des ressources NFS partagées sont absentes des migrations

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é.

Le service d'agent de Logical Domains n'est pas disponible en ligne si le service de journal système n'est pas en ligne

ID de bogue 15707426 : si le service de journal système svc:/system/system-log, ne démarre pas et n'est pas en ligne, le service d'agent de Logical Domains n'est pas disponible en ligne non plus. Lorsque le service d'agent de Logical Domains n'est pas en ligne, les commandes virtinfo, ldm add-vsw, ldm add-vdsdev et ldm list-io risquent de ne pas se comporter normalement.

Solution de contournement : assurez-vous que le service svc:/ldoms/agents:default est activé et en ligne :

# svcs -l svc:/ldoms/agents:default

Si le service svc:/ldoms/agents:default est hors ligne, vérifiez qu'il est actif et que tous les services dépendants sont en ligne.

Un interblocage de noyau provoque le blocage de la machine pendant une migration

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.

La stratégie DRM et la sortie `ldm list` présentent un nombre de CPU virtuelles différent du nombre de CPU virtuelles réellement contenues dans le domaine invité

ID de bogue 15702475 : le message No response peut s'afficher dans le journal de Oracle VM Server for SPARC lorsque la stratégie DRM d'un domaine chargé expire après une réduction significative du nombre de CPU. La sortie ldm list montre qu'il y a plus de ressources CPU affectées au domaine que celles affichées dans la sortie psrinfo.

Solution de contournement : utilisez la commande ldm set-vcpu pour redéfinir le nombre de CPU du domaine sur la valeur présentée dans la sortie psrinfo.

Migration en direct d'un domaine dépendant d'un domaine maître inactif sur la machine cible entraînant l'erreur de la commande `ldmd` avec une erreur de segmentation

ID de bogue 15701865 : si vous tentez une migration en direct d'un domaine dépendant d'un domaine inactif sur la machine cible, le démon ldmd échoue avec une erreur de segmentation et 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.

Echec du rétablissement du nombre par défaut de CPU virtuelles pour un domaine migré par la stratégie DRM lorsque la stratégie a été supprimée ou qu'elle a expiré

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.

Echec de délai d'attente de CPU virtuelles lors de la reconfiguration dynamique

ID de bogue 15701258 : l'exécution de la commande ldm set-vcpu 1 sur un domaine invité contenant plus de 100 CPU virtuelles et quelques unités de chiffrement ne parvient pas à supprimer les CPU virtuelles. Les CPU virtuelles ne sont pas supprimées en raison d'un échec du délai d'attente de la reconfiguration dynamique. Les unités de chiffrement, par contre, sont bien supprimées

Solution de contournement : utilisez la commande ldm rm-vcpu pour supprimer l'ensemble du contenu du domaine invité à l'exception des CPU virtuelles. Ne supprimez pas plus de 100 CPU virtuelles à la fois.

Motif de l'échec de migration non signalé lorsque l'adresse MAC du système entre en conflit avec une autre adresse MAC

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.

Des opérations de migration simultanées dans des "directions opposées" risquent d'entraîner le blocage de `ldm`

ID de bogue 15696986 : si deux commandes ldm migrate sont émises simultanément 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.

Echec de la suppression d'un grand nombre de CPU d'un domaine de contrôle

ID de bogue 15677358 : utilisez une reconfiguration retardée plutôt qu'une reconfiguration dynamique pour supprimer plus de 100 CPU du domaine de contrôle (également appelé domaine primary). Utilisez les étapes suivantes :

Utilisez la commande ldm start-reconf primary pour mettre le domaine de contrôle en mode de reconfiguration retardée.
Supprimez le nombre de ressources de CPU de votre choix.

Si vous vous trompez lors de la suppression des ressources de CPU, ne tentez pas d'exécuter une nouvelle demande de suppression de CPU tant que le domaine de contrôle est à l'état de reconfiguration retardée. Le cas échéant, les commandes échoueront (reportez-vous à la section Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée). 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.

Le système exécutant le SE Oracle Solaris 10 8/11 sur lequel la stratégie élastique est définie peut se bloquer

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.

La commande `pkgadd` ne parvient pas à définir les entrées ACL sur `/var/svc/manifest/platform/sun4v/ldmd.xml`

ID de bogue 15668881 : lorsque vous utilisez la commande pkgadd pour installer le package SUNWldm.v depuis un répertoire exporté via NFS à partir d'un produit Sun ZFS Storage Appliance, le message d'erreur suivant peut s'afficher :

cp: failed to set acl entries on /var/svc/manifest/platform/sun4v/ldmd.xml

Solution de contournement : ignorez ce message.

SPARC T3-1 : problème lié aux disques accessibles via plusieurs chemins d'E/S directes

ID de bogue 15668368 : un système SPARC T3-1 peut être installé avec des disques double port, lesquels peuvent être accessibles via deux périphériques d'E/S directes différents. Dans ce cas, l'assignation de ces périphériques d'E/S directes à des domaines différents entraîne parfois l'utilisation des disques par les deux domaines et une incidence mutuelle sur l'utilisation réelle de ces disques.

Solution de contournement : n'assignez pas des périphériques d'E/S directes ayant accès au même ensemble de disques sur différents domaines d'E/S. Pour déterminer si votre système SPARC T3-1 contient des disques à deux ports, exécutez la commande suivante sur le SP :

-> show /SYS/SASBP

Si la sortie contient la valeur fru_description, le système correspondant contient des disques double port :

fru_description = BD,SAS2,16DSK,LOUISE

Lorsque des disques double port sont présents dans le système, assurez-vous que les deux périphériques d'E/S directes suivants sont toujours assignés au même domaine :

pci@400/pci@1/pci@0/pci@4  /SYS/MB/SASHBA0
pci@400/pci@2/pci@0/pci@4  /SYS/MB/SASHBA1

Les opérations de suppression de la reconfiguration dynamique de la mémoire avec plusieurs instances `nxge` NIU associées peuvent se bloquer indéfiniment et ne pas s'effectuer entièrement

ID de bogue 15667770 : lorsque plusieurs instances nxge NIU sont associées sur un domaine, les commandes ldm rm-mem et ldm set-mem utilisées pour supprimer la mémoire du domaine ne s'exécutent pas entièrement. Pour déterminer si le problème est survenu durant une opération de suppression de mémoire, surveillez l'avancement de l'opération au moyen de la commande ldm list -o status. Vous rencontrerez peut-être ce problème si le pourcentage d'avancement reste constant pendant plusieurs minutes.

Solution de contournement : annulez la commande ldm rm-mem ou ldm set-mem, puis vérifiez si une quantité de mémoire suffisante a été supprimée. Si ce n'est pas le cas, une autre commande de suppression de mémoire pourra être effectuée sans erreur afin de supprimer une plus petite quantité de mémoire.

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.

L'exécution de la commande `ldm stop -a` sur des domaines participant à une relation maître-esclave laisse l'esclave avec l'indicateur défini sur `stopping`

ID de bogue 15664666 : lorsqu'une relation de dépendance de réinitialisation est créée, la commande ldm stop -a peut entraîner le redémarrage au lieu de l'arrêt seul d'un domaine participant à une relation de dépendance de réinitialisation.

Solution de contournement : exécutez d'abord la commande ldm stop pour le domaine maître. Exécutez ensuite la commande ldm stop pour le domaine esclave. Si l'arrêt initial du domaine esclave échoue, exécutez la commande ldm stop -f pour le domaine esclave.

La migration d'un domaine sur laquelle une stratégie DRM par défaut est active entraîne l'assignation de toutes les CPU disponibles à un domaine cible

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.

Une adresse MAC en cours d'utilisation peut être réaffectée

ID de bogue 15655199 : il arrive qu'une adresse MAC active ne soit pas détectée et soit réaffectée à tort.

Solution de contournement : vérifiez manuellement que les adresses MAC actives ne puissent pas être réaffectées.

Impossible de créer une configuration de domaine sur le processeur de service pour `ldmconfig`

ID de bogue 15654965 : le script ldmconfig ne peut pas créer correctement une configuration de domaines logique stockée sur le processeur de service.

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.

La migration non coopérative de domaines Oracle Solaris peut se bloquer si `cpu0` est hors ligne

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.

La reconfiguration dynamique de la mémoire est désactivée à la suite de l'annulation d'une migration

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.

Echec possible de la reconfiguration dynamique des valeurs MTU de périphériques réseau virtuel

ID de bogue 15631119 : si vous modifiez l'unité de transmission maximale (MTU) d'un périphérique réseau virtuel sur le domaine de contrôle, une opération de reconfiguration retardée est déclenchée. Si vous annulez ensuite la reconfiguration retardée, la valeur MTU du périphérique n'est pas rétablie à sa valeur initiale.

Reprise : réexécutez la commande ldm set-vnet pour définir la valeur MTU sur sa valeur initiale. La redéfinition de la valeur MTU a pour effet de placer le domaine de contrôle en mode de reconfiguration retardée que vous devez désactiver. La valeur MTU résultante est à présent la valeur MTU correcte initiale.

# ldm set-vnet mtu=orig-value vnet1 primary
# ldm cancel-op reconf primary

Un domaine migré avec des MAU contient une seule CPU lorsque le SE cible ne prend pas en charge la reconfiguration dynamique d'unités cryptographiques

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.

Le message d'échec de migration concernant de réels échecs de liaison de mémoire d'adresses manque de clarté

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.

La suppression dynamique de toutes les unités cryptographiques d'un domaine entraîne l'arrêt de SSH

ID de bogue 15600969 : si toutes les unités cryptographiques matérielles sont supprimées de manière dynamique dans un domaine actif, la structure cryptographique ne peut pas recourir aux fournisseurs cryptographiques de logiciels sans erreur, et arrête l'ensemble des connexions ssh.

Reprise : rétablissez les connexions ssh après avoir supprimé les unités cryptographiques du domaine.

Solution de contournement : définissez la propriété UseOpenSSLEngine=no du fichier /etc/ssh/sshd_config sur le côté serveur et exécutez la commande svcadm restart ssh.

Aucune des connexions ssh ne recourt plus aux unités cryptographiques matérielles (et ne tire donc plus parti des améliorations des performances qui y sont associées) et les connexions ssh ne sont plus arrêtées lorsque des unités cryptographiques sont supprimées.

La carte fibre 10 Gigabit Ethernet double, PCI Express Atlas affiche quatre sous-périphériques dans la sortie `ldm list-io -l`

ID de bogue 15597025 : lorsque vous exécutez la commande ldm ls-io -l sur un système équipé d'une carte fibre 10 Gigabit Ethernet double, PCI Express (X1027A-Z), la sortie peut afficher les informations suivantes :

primary# ldm ls-io -l
...
pci@500/pci@0/pci@c PCIE5 OCC primary
network@0
network@0,1
ethernet
ethernet

La sortie affiche quatre sous-périphériques même si la carte Ethernet ne possède que deux ports. Cette anomalie se présente si la carte comporte quatre fonctions PCI. Deux de ces fonctions sont désactivées en interne et s'affichent comme étant des ports ethernet dans la sortie ldm ls-io -l.

Solution de contournement : vous pouvez ignorer les entrées ethernet dans la sortie ldm ls-io -l.

Utilisation du mpgroup Logical Domains avec configuration de baie de stockage MPXIO permettant une grande disponibilité du disque

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

`ldm` : ces commandes mettent beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés

ID de bogue 15572184 : une commande ldm risque de mettre beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés. Si vous exécutez une commande ldm à ce stade, elle peut sembler se bloquer. Sachez que la commande ldm revient normalement, une fois que la tâche attendue est effectuée. Lorsque la commande revient, le système doit répondre normalement aux commandes ldm.

Solution de contournement : évitez d'initialiser plusieurs domaines à la fois. Toutefois, si vous y êtes contraint, évitez d'exécuter d'autres commandes ldm tant que le système ne retourne pas à son état de fonctionnement normal. Par exemple, patientez environ deux minutes sur des serveurs Sun SPARC Enterprise T5140 et T5240 et environ quatre minutes sur le serveur Sun SPARC Enterprise T5440 Server ou Sun Netra T5440.

Oracle Solaris 11 : les zones configurées à l'aide d'une interface réseau automatique risquent de ne pas pouvoir démarrer

ID de bogue 15560811 : dans Oracle Solaris 11, les zones configurées à l'aide d'une interface réseau automatique (anet) risquent de ne pas démarrer dans un domaine possédant uniquement des périphériques de réseau virtuel Logical Domains.

Solution 1 : affectez un ou plusieurs périphériques réseau physique au domaine invité. Utilisez la fonctionnalité d'affectation de bus PCIe, d'E/S directes (DIO) ou la fonctionnalité SR-IOV pour affecter un NIC physique au domaine.
Solution 2 : si la configuration requise pour la configuration des zones consiste en une configuration entre les zones du domaine, créez un périphérique etherstub. Utilisez le périphérique etherstub en tant que "liaison inférieure" dans la configuration des zones afin que les cartes NIC virtuelles soient créées sur le périphérique etherstub.
Solution 3 : utilisez une affectation de lien exclusive pour attribuer un périphérique de réseau virtuel Logical Domains à une zone. Affectez des périphériques de réseau virtuel au domaine en fonction de vos besoins. Vous pouvez également choisir de désactiver les liens inter-vnet afin de créer un grand nombre de périphériques de réseau virtuel.

Oracle Solaris 10 : les périphériques réseau virtuels ne sont pas créés correctement sur le domaine de contrôle

ID de bogue 15560201 : il arrive que la commande ifconfig indique que le périphérique n'existe pas après l'ajout d'un périphérique de réseau virtuel ou de disque virtuel à un domaine. Ce problème survient car l'entrée /devices n'a pas été créée.

Bien que ce problème ne devrait pas se produire en fonctionnement normal, l'erreur peut se présenter lorsque le numéro d'instance d'un périphérique réseau virtuel ne correspond pas à celui répertorié dans le fichier /etc/path_to_inst.

Par exemple :

# ifconfig vnet0 plumb
ifconfig: plumb: vnet0: no such interface

Le numéro d'instance d'un périphérique virtuel est indiqué dans la colonne DEVICE de la sortie ldm list :

# ldm list -o network primary
NAME             
primary          

MAC
 00:14:4f:86:6a:64

VSW
 NAME         MAC               NET-DEV DEVICE   DEFAULT-VLAN-ID PVID VID MTU  MODE  
 primary-vsw0 00:14:4f:f9:86:f3 nxge0   switch@0 1               1        1500        

NETWORK
 NAME   SERVICE              DEVICE    MAC               MODE PVID VID MTU  
 vnet1  primary-vsw0@primary network@0 00:14:4f:f8:76:6d      1        1500

Le numéro d'instance (0 pour les deux périphériques vnet et vsw de la sortie affichée précédemment) peut être comparé au numéro d'instance indiqué dans le fichier path_to_inst afin de s'assurer qu'ils sont identiques.

# egrep '(vnet|vsw)' /etc/path_to_inst
"/virtual-devices@100/channel-devices@200/virtual-network-switch@0" 0 "vsw"
"/virtual-devices@100/channel-devices@200/network@0" 0 "vnet"

Solution de contournement : si les numéros d'instance ne sont pas identiques, supprimez le périphérique de réseau virtuel ou de commutateur virtuel. Ensuite, rajoutez-le en spécifiant explicitement le numéro d'instance requis en définissant la propriété id.

Vous pouvez également modifier manuellement le fichier /etc/path_to_inst. Reportez-vous à la page de manuel path_to_inst(4).

Mise en garde - Aucune modification ne doit pas être apportée à /etc/path_to_inst sans un examen attentif.

Les cartes NIU/XAUI récemment ajoutées ne sont pas visibles pour le SE hôte si le logiciel Logical Domains est configuré

ID de bogue15555509 : si le logiciel Logical Domains est configuré sur un système et que vous ajoutez une autre carte réseau XAUI, celle-ci n'est pas visible après l'arrêt et le redémarrage de la machine.

Reprise : pour que la carte XAUI récemment ajoutée soit visible dans le domaine de contrôle, suivez les étapes ci-dessous :

Définissez et effacez une variable factice dans le domaine de contrôle.

Les commandes suivantes utilisent une variable factice appelée fix-xaui :
```
# ldm set-var fix-xaui=yes primary
# ldm rm-var fix-xaui primary
```
Enregistrez la configuration modifiée sur le processeur de service (SP) en écrasant l'actuelle.

Les commandes suivantes utilisent une configuration appelée fix-config1 :
```
# ldm rm-spconfig config1
# ldm add-spconfig config1
```
Effectuez une réinitialisation de reconfiguration sur le domaine de contrôle.
```
# reboot -- -r
```
A ce stade, vous pouvez configurer les réseaux récemment disponibles pour que le logiciel Logical Domains puisse les utiliser.

Panique possible du domaine d'E/S ou du domaine invité lors d'une initialisation à partir de `e1000g`

ID de bogue 15543982 : vous pouvez configurer deux domaines au maximum avec des complexes root PCI-E dédiés sur des systèmes tels que le Sun Fire T5240. Ces systèmes sont dotés de deux CPU UltraSPARC T2 Plus et de deux complexes root d'E/S.

pci@500 et pci@400 sont les deux complexes root du système. Le domaine primary contient toujours au moins un complexe root. Un second domaine peut être configuré avec un complexe root non assigné ou non lié.

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

Remarque - Sur certaines lames, le domaine primary (disque système) est par défaut présent sur le bus pci@400.
Le périphérique e1000g de la structure pci@400 est utilisé pour initialiser le second domaine

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.

Les liaisons de groupe de consoles et de port explicites ne sont pas migrées

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.

La migration n'échoue pas si un `vdsdev` a un moteur de traitement différent sur la cible

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.
1. Remigrez le domaine vers la machine source.
2. Corrigez le volume vdsdev sur la cible de sorte qu'il pointe vers le bon moteur de traitement de disque.
3. 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 :
1. Exécutez la commande ldm rm-vdisk pour supprimer le disque.
2. Corrigez le volume vdsdev.
3. Exécutez la commande ldm add-vdisk pour rajouter le disque virtuel.

La migration ne permet pas toujours la liaison de mémoire si la quantité de mémoire disponible est suffisante sur la cible

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.

Logical Domains Manager ne démarre pas si la machine n'est pas mise en réseau et qu'un client NIS est exécuté

ID de bogue 15518409 : si vous ne disposez pas d'un réseau configuré sur votre machine et qu'un client NIS (Network Information Services, services d'information réseau) est actif, Logical Domains Manager ne démarre pas sur votre système.

Solution de contournement : désactivez le client NIS sur la machine non mise en réseau :

# svcadm disable nis/client

Logical Domains Manager affiche les domaines migrés à l'état de transition lorsqu'ils sont déjà initialisés

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.

Impossible de se connecter à la console d'un domaine migré sauf si le service `vntsd` est redémarré

ID de bogue 15513998 : il arrive qu'il soit impossible de se connecter à la console d'un domaine qui vient d'être migré.

Solution de contournement : redémarrez le service SMF vntsd pour activer les connexions à la console :

# svcadm restart vntsd

Remarque - Cette commande déconnecte toutes les connexions de console actives.

Il arrive que l'exécution de la commande `uadmin 1 0` à partir d'un système Logical Domains ne retourne pas le système à l'invite OK

ID de bogue 15511551 : il arrive qu'un système Logical Domains ne revienne pas à l'invite ok après une réinitialisation consécutive à l'exécution de la commande uadmin 1 0 à partir de la ligne de commande. Ce comportement anormal se présente uniquement si la variable Logical Domains auto-reboot? est définie sur true. Si auto-reboot? est définie sur false, la commande génère le résultat attendu.

Solution de contournement : exécutez la commande suivante à la place :

uadmin 2 0

Ou, exécutez la commande avec la variable auto-reboot? toujours définie sur false.

Logical Domains Manager met parfois plus de 15 minutes pour arrêter un domaine

ID de bogue 15505014 : l'arrêt d'un domaine ou le nettoyage de la mémoire peut prendre plus de 15 minutes avec une seule CPU et une configuration de mémoire très importante. Durant l'arrêt, les CPU d'un domaine sont utilisées pour nettoyer l'ensemble de la mémoire détenue par le domaine. Le temps mis pour effectuer le nettoyage peut être assez long si une configuration donnée est déséquilibrée, par exemple, si un domaine à une seule CPU comporte 512 giga-octets de mémoire. Ce délai de nettoyage prolongé vient augmenter le temps nécessaire pour arrêter un domaine.

Solution de contournement : assurez-vous que les configurations de mémoire importante (plus de 100 giga-octets) comportent au moins un coeur.

La commande `scadm` peut se bloquer à la suite d'une réinitialisation d'un contrôleur système ou d'un processeur de service

ID de bogue 15469227 : la commande scadm d'un domaine de contrôle exécutant le SE Oracle Solaris 10 5/08 ou ultérieur peut se bloquer à la suite d'une réinitialisation de contrôleur système. Le système ne parvient pas à rétablir correctement une connexion après une réinitialisation de contrôleur système.

Reprise : réinitialisez l'hôte pour rétablir la connexion avec le contrôleur système.

Une installation réseau simultanée de plusieurs domaines échoue lorsqu'il s'agit d'un groupe de consoles commun

ID de bogue 15453968 : une installation réseau simultanée de plusieurs domaines invités échoue sur les systèmes ayant un groupe de consoles commun.

Solution de contournement : procédez à une installation réseau uniquement sur des domaines invités ayant chacun leur propre groupe de consoles. Cette panne se rencontre uniquement sur les domaines ayant un groupe de consoles commun partagé entre plusieurs domaines à installation réseau.

Un domaine invité comportant un nombre trop important de réseaux virtuels sur le même réseau utilisant DHCP peut devenir non réactif

ID de bogue ID 15422900 : si vous configurez plus de quatre réseaux virtuels (vnets) dans un domaine invité sur le même réseau utilisant le protocole DHCP (Dynamic Host Configuration Protocol), le domaine peut devenir non réactif pour traiter le trafic réseau.

Solution de contournement : définissez ip_ire_min_bucket_cnt et ip_ire_max_bucket_cnt sur des valeurs plus grandes comme 32, si vous disposez de huit interfaces.

Reprise : Exécutez une commande ldm stop-domain ldom suivie d'une commande ldm start-domain ldom sur le domaine invité (ldom) en question.

Les variables OpenBoot PROM ne peuvent pas être modifiées par la commande `eeprom` lorsque Logical Domains Manager est en cours d'exécution

ID de bogue 15387338 : ce problème est sommairement décrit dans la section Persistance des variables Logical Domains et concerne uniquement le domaine de contrôle.

Impossible de définir des clés de sécurité durant l'exécution de Logical Domains

ID de bogue 15370442 : l'environnement Logical Domains ne prend pas en charge la définition ou la suppression de clés d'initialisation de connexion WAN à partir du SE Oracle Solaris à l'aide de la commande ickey(1M). Toutes les opérations ickey échouent avec le message d'erreur suivant :

ickey: setkey: ioctl: I/O error

De plus, les clés d'initialisation via connexion WAN qui sont définies en utilisant le microprogramme OpenBoot sur des domaines logiques autres que le domaine de contrôle ne sont pas mémorisées après la réinitialisation du domaine. Sur ces domaines, les clés définies à partir du microprogramme OpenBoot sont valides uniquement pour un seul usage.

Le comportement de la commande `ldm stop-domain` n'est pas toujours très clair

ID de bogue 15368170 : dans certains cas, le comportement de la commande ldm stop-domain est déroutant.

# ldm stop-domain -f 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

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