| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Notes de version d'Oracle VM Server for SPARC 3.0 Oracle VM Server for SPARC (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Notes de version d'Oracle VM Server for SPARC 3.0 Oracle VM Server for SPARC (Français) |
1. Notes de version d'Oracle VM Server for SPARC 3.0
Plates-formes prises en charge
Versions du SE Oracle Solaris requises et recommandées
Logiciels requis pour activer les fonctionnalités d'Oracle VM Server for SPARC 3.0.
Patchs de microprogramme système requis et recommandés
Version logicielle minimale requise
Configuration matérielle et logicielle requise pour les E/S directes
Configuration matérielle et logicielle SR-IOV PCIe
Emplacement du logiciel Oracle VM Server for SPARC 3.0
Emplacement de la documentation
Logiciels compatibles avec Logical Domains Manager
Logiciels de contrôleur système utilisés avec le logiciel Logical Domains
Mise à niveau vers le logiciel Oracle VM Server for SPARC 3.0
Fonctions désapprouvées dans cette version d'Oracle VM Server for SPARC 3.0
Mise à niveau à partir d'un SE Oracle Solaris 10 antérieur au SE Oracle Solaris 10 5/08
Les termes Processeur de service et Contrôleur système sont utilisés de manière interchangeable
Canaux de domaines logiques et Logical Domains
Initialisation d'un grand nombre de domaines
Arrêt et cycle d'alimentation d'un système Logical Domains
Taille de la mémoire requise différente de la mémoire allouée
Persistance des variables Logical Domains
Sun SNMP Management Agent d'Oracle ne prend pas en charge plusieurs domaines
Commande ldmp2v convert : des messages d'avertissement VxVM durant une initialisation
Configuration requise pour le partitionnement forcé Oracle des licences logicielles
Option de mise à niveau absente lors de l'utilisation de ldmp2v prepare -R
ldmp2v : la méthode d'archivage ufsdump n'est plus utilisée avec cette commande
Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée
Restrictions de la migration de domaine
Restrictions de version pour la migration
Prise en charge de la migration cpu-arch=generic pour SPARC M5 et SPARC T5
Restrictions de la CPU pour la migration
Problèmes liés à Oracle VM Server for SPARC MIB
La commande snmptable ne fonctionne pas avec l'option Version 2 ou Version 3
Bogues liés au logiciel Oracle VM Server for SPARC 3.0
L'ajout dynamique d'un strand défectueux à un domaine peut entraîner une panique
Des sous-périphériques subordonnés à un périphérique PCIe retournent à l'état "sans nom"
SPARC M5-32 : panic: mpo_cpu_add: Cannot read MD
SPARC M5-32 : problème lié aux disques accessibles via plusieurs chemins d'E/S directs
Un domaine invité ne peut pas s'initialiser lorsque les périphériques prêtés par IOV sont désactivés
Panique mutex_enter: bad mutex dans le domaine primary une réinitialisation ou un arrêt
SPARC M5-32 : le contrôleur LSI-SAS est exporté de façon incorrecte avec SR-IOV.
Deux propriétés sont manquantes dans la sortie ldm list-io -d d'un périphérique sxge sur SPARC T5-1B
Restrictions supplémentaires pour la migration
La reconfiguration dynamique de CPU d'un très grand nombre de CPU virtuelles peut échouer
SPARCT4-4 : impossible d'associer un domaine invité
Echec de la réinitialisation du domaine invité lorsque la mémoire est très fragmentée
La reconfiguration dynamique des CPU disponibles entraîne une panique lpl_topo_verify fail -5
Les domaines root ne peuvent pas présenter de dépendances à d'autres domaines root
Un domaine invité panique après une migration lorsque des coeurs sont ajoutés
Panique du domaine invité lorsque la propriété threading est modifiée de max-throughput à max-ipc
Le domaine de contrôle bloque lors d'une réinitialisation avec deux domaines d'E/S directs actifs
ldm rm-io doit accepter --dry-run en tant qu'alias pour -n
Echec de l'arrêt du domaine à l'aide des commandes ldm stop ou ldm stop -f
Echec de la recréation d'un domaine avec des fonctions virtuelles PCIe à partir d'un fichier XML
Domaine de contrôle nécessitant le coeur le plus bas du système
Démon ldmd indisponible en ligne
Non-réactivité des commandes ldm exécutées sur le système cible après annulation d'une migration
Non-fonctionnement de certaines cartes Emulex lorsqu'elles sont assignées à un domaine d'E/S
Oracle Solaris 11 : signalement d'usurpation et d'échec RD Oracle Solaris par les DRM
Limitation du nombre maximum de fonctions virtuelles qu'il est possible d'affecter à un domaine
La version 8.2.0 du microprogramme système contient une nouvelle version de la base de données scvar
Désactivation conseillée de l'option ldm remove-io des cartes PCIe possédant des ponts PCIe vers PCI
Echec probable de la commande ldm stop en cas d'émission immédiatement après une commande ldm start
Message d'erreur SR-IOV vague : Create vf failed
Echec de l'autorisation des transitions DR whole-core par le coeur partiel primary
Affichage de l'état UNK ou INV par la commande ldm list-io après l'initialisation
Echec de la suppression d'un grand nombre de CPU d'un domaine invité
La validation de disque virtuel échoue pour un disque physique sans tranche 2
Un interblocage de noyau provoque le blocage de la machine pendant une migration
Echec de délai d'attente de CPU virtuelles lors de la reconfiguration dynamique
Echec de la suppression d'un grand nombre de CPU d'un domaine de contrôle
SPARC T3-1 : problème lié aux disques accessibles via plusieurs chemins d'E/S directes
Une adresse MAC en cours d'utilisation peut être réaffectée
Impossible de créer une configuration de domaine sur le processeur de service pour ldmconfig
La migration non coopérative de domaines Oracle Solaris peut se bloquer si cpu0 est hors ligne
La reconfiguration dynamique de la mémoire est désactivée à la suite de l'annulation d'une migration
Echec possible de la reconfiguration dynamique des valeurs MTU de périphériques réseau virtuel
La suppression dynamique de toutes les unités cryptographiques d'un domaine entraîne l'arrêt de SSH
ldm : ces commandes mettent beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés
Panique possible du domaine d'E/S ou du domaine invité lors d'une initialisation à partir de e1000g
Les liaisons de groupe de consoles et de port explicites ne sont pas migrées
La migration n'échoue pas si un vdsdev a un moteur de traitement différent sur la cible
Impossible de se connecter à la console d'un domaine migré sauf si le service vntsd est redémarré
Logical Domains Manager met parfois plus de 15 minutes pour arrêter un domaine
ldc_close: (0xb) unregister failed, 11 Messages d'avertissement
Impossible de définir des clés de sécurité durant l'exécution de Logical Domains
Le comportement de la commande ldm stop-domain n'est pas toujours très clair
Cette section recense les problèmes d'ordre général et les bogues liés au logiciel Oracle VM Server for SPARC 3.0.
Cette section décrit les problèmes matériels et logiciels connus pour cette version du logiciel Oracle VM Server for SPARC qui ne concernent pas qu'un numéro de bogue particulier. Des solutions sont proposées, le cas échéant.
Si le domaine de contrôle est mis à niveau à partir d'une version du SE Oracle Solaris 10 antérieure au SE Oracle Solaris 10 5/08 (ou sans le patch 127127-11) et si les volumes du gestionnaire de volumes ont été exportés en tant que disques virtuels, les moteurs de traitement des disques virtuels doivent être ré-exportés avec options=slice après la mise à niveau du Logical Domains Manager. Reportez-vous à la section Exportation de volumes et rétrocompatibilité du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Pour les besoins de la documentation d'Oracle VM Server for SPARC les termes Processeur de service et Contrôleur système sont utilisés de manière interchangeable.
Si un domaine de service exécute une version du SE Oracle Solaris 10 antérieure à Oracle Solaris 10 8/11 et qu'il exporte une tranche de disque physique sous forme de disque virtuel vers un domaine invité, ce disque virtuel est présenté sur le domaine invité avec un ID de périphérique incorrect. Si ce domaine de service est ensuite mis à niveau vers Oracle Solaris 10 8/11, la tranche de disque physique exportée sous forme de disque virtuel est présentée sur le domaine invité sans ID de périphérique.
L'absence d'ID de périphérique pour le disque virtuel peut être à l'origine de problèmes au niveau des applications qui tentent de référencer l'ID de périphérique de disques virtuels. En particulier, Solaris Volume Manager risque de ne plus pouvoir détecter sa configuration ou d'accéder à ses métapériphériques.
Solution : Après avoir mis à niveau un domaine de service vers Oracle Solaris 10 8/11, si un domaine invité ne parvient pas à détecter sa configuration Solaris Volume Manager ou ses métapériphériques, suivez la procédure ci-dessous.
md_devid_destroy=1; md_keep_repl_state=1;
Après l'initialisation du domaine, la configuration de Solaris Volume Manager et les métapériphériques devraient être disponibles.
Lors de la réinitialisation, des messages semblables aux suivants s'affichent :
NOTICE: mddb: unable to get devid for 'vdc', 0x10
Il n'y a rien d'anormal à cela dans la mesure où aucun problème n'est signalé.
Le nombre de canaux LDC (Logical Domain Channel) disponibles sur un domaine logique est limité. Les limites LDC sont :
La limite LDC est 512.
La limite LDC est 768.
Cette restriction ne pose problème que lorsque le domaine de contrôle se voit allouer, en partie si ce n'est en totalité, le sous-système d'E/S. Cette restriction peut également poser problème en raison du nombre potentiellement important de LDC qui sont créés pour à la fois les communications de données d'E/S virtuelles et le contrôle Logical Domains Manager des autres domaines logiques.
Si vous essayez d'ajouter un service ou de lier un domaine, si bien que le nombre de canaux LDC dépasse la limite sur le domaine de contrôle, l'opération échoue avec un message d'erreur similaire au suivant :
13 additional LDCs are required on guest primary to meet this request, but only 9 LDCs are available
Si de nombreux périphériques réseau virtuels sont connectés au même commutateur virtuel, vous pouvez réduire le nombre de canaux LDC affectés à l'aide des commandes ldm add-vsw ou ldm set-vsw pour définir la propriété inter-vnet-link=off. Lorsque cette propriété est définie sur off, les canaux LDC ne sont pas utilisés pour les communications inter-vnet. A la place, un canal LDC est affecté uniquement aux communications entre périphériques réseau virtuels et périphériques commutateurs virtuels. Reportez-vous à la page de manuel ldm(1M).
Remarque - Bien que la désactivation de l'affectation des canaux inter-vnet réduise le nombre de LDC, elle risque d'avoir une incidence négative sur les performances réseau entre invités.
La prise en compte des directives suivantes peut vous éviter de créer une configuration susceptible de dépasser les capacités des LCD sur le domaine de contrôle :
Le domaine de contrôle alloue environ 15 canaux LDC pour divers objectifs de communication avec l'hyperviseur, l'architecture de gestion des pannes FMA (Fault Management Architecture) et le contrôleur système (SC), indépendamment du nombre de domaines logiques par ailleurs configurés. Le nombre de canaux LDC alloués par le domaine de contrôle dépend de la plate-forme et de la version du logiciel utilisées.
Le domaine de contrôle alloue un canal LDC à chaque domaine logique, y compris lui-même, pour le trafic de contrôle.
Chaque service d'E/S virtuel sur le domaine de contrôle consomme un canal LDC pour chaque client connecté à ce service.
Par exemple, considérons une configuration avec un domaine de contrôle et 8 domaines logiques supplémentaires. Chaque domaine logique nécessite au moins :
Réseau virtuel
Disque virtuel
Console virtuelle
En appliquant les directives, nous obtenons les résultats suivants (les nombres entre parenthèses correspondent au numéro de directive précédente à partir de laquelle la valeur a été dérivée) :
15(1) + 9(2) + 8 x 3(3) = 48 canaux LDC au total
Considérons maintenant un cas avec 45 domaines au lieu de 8 où chaque domaine comporte 5 disques virtuels, 5 réseaux virtuels et une console virtuelle. L'équation devient maintenant :
15 + 46 + 45 x 11 = 556 canaux LDC au total
Selon le nombre de canaux LDC pris en charge de votre plate-forme, le logiciel Logical Domains Manager accepte ou refuse les configurations.
Le logiciel Oracle VM Server for SPARC n'impose aucune limitation de taille pour la mémoire lors de la création d'un domaine. La taille de la mémoire requise est une caractéristique du système d'exploitation hôte. Certaines fonctions d'Oracle VM Server for SPARC risquent de ne pas fonctionner si la quantité de mémoire présente est inférieure à la taille recommandée. Pour le SE Oracle Solaris 10, reportez-vous à la section System Requirements and Recommendations du manuel Oracle Solaris 10 8/11 Installation Guide: Planning for Installation and Upgrade. Pour connaître la configuration système requise et les recommandations pour le SE Oracle Solaris 11, reportez-vous aux sections Oracle Solaris 11 Release Notes et Oracle Solaris 11.1 Release Notes .
La PROM OpenBoot a une contrainte de taille minimale pour un domaine. Actuellement, cette limite est de 12 méga-octets. Si vous avez un domaine dont la taille est inférieure, Logical Domains Manager étend automatiquement celui-ci à 12 méga-octets. La taille minimale d'un système Fujitsu M10 est limitée à 256 Mo. Reportez-vous aux notes de version de votre microprogramme système pour connaître la taille de la mémoire requise
La fonction de reconfiguration dynamique (DR) de la mémoire applique un alignement de 256 Mo sur l'adresse et la taille de la mémoire impliquées dans une opération donnée. Reportez-vous à la section Alignement de la mémoire du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Vous pouvez initialiser le nombre de domaines suivants en fonction de votre plate-forme :
Jusqu'à 256 sur les systèmes Fujitsu M10
Jusqu'à 128 sur les systèmes SPARC M5 par domaine physique
Jusqu'à 128 sur les systèmes SPARC T5
Jusqu'à 128 sur les serveurs SPARC T4
Jusqu'à 128 sur les serveurs SPARC T3
Jusqu'à 128 sur les serveurs UltraSPARC T2 Plus
Jusqu'à 64 sur les serveurs UltraSPARC T2
Si des CPU virtuelles non allouées sont disponibles, assignez-les au domaine de service afin de contribuer au traitement des demandes d'E/S virtuelles. Attribuez 4 à 8 CPU virtuelles au domaine de service si vous créez plus de 32 domaines. Dans les cas où les configurations de domaines maximales ne disposent que d'une CPU dans le domaine de service, ne placez pas une contrainte inutile sur cette CPU lors de la configuration et de l'utilisation du domaine. Les services de commutateur virtuel (vsw) doivent être répartis sur l'ensemble des adaptateurs réseau disponibles dans la machine. Par exemple, si vous initialisez 128 domaines sur un serveur Sun SPARC Enterprise T5240, créez quatre services vsw, chacun servant 32 instances réseau virtuelles (vnet). L'attribution de plus de 32 instances vnet par service vsw peut entraîner un blocage forcé du domaine du service.
Pour exécuter les configurations maximales, une machine nécessite une quantité de mémoire suffisante pour prendre en charge les domaines invités. La quantité de mémoire dépend de votre plate-forme et de votre SE. Reportez-vous à la documentation relative à votre plate-forme, Oracle Solaris 10 8/11 Installation Guide: Planning for Installation and Upgrade , Installing Oracle Solaris 11 Systems et Installing Oracle Solaris 11.1 Systems .
La mémoire libre et l'espace de swap utilisés dans un domaine invité augmentent lorsque les services vsw utilisés par le domaine fournissent des services à de nombreux réseaux virtuels (dans plusieurs domaines). Ceci est dû aux liaisons de poste à poste entre toutes les instances vnet connectées à vsw. Le domaine de service bénéficie d'une quantité de mémoire supplémentaire. La valeur minimale recommandée est 4 Go lorsque vous exécutez plus de 64 domaines. Démarrez les domaines par groupe de 10 ou moins et attendez qu'ils s'initialisent avant de démarrer le lot suivant. Ce conseil est également valable pour les systèmes d'exploitation des domaines. Vous pouvez réduire le nombre de liaisons en désactivant les canaux inter-vnet. Reportez-vous à la section Canaux LDC inter-Vnet du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Si vous avez effectué des changements de configuration depuis le dernier enregistrement d'une configuration sur le contrôleur système, avant d'éteindre ou d'effectuer un cycle d'alimentation d'un système Logical Domains, veillez à enregistrer la dernière configuration que vous souhaitez conserver.
Puisqu'aucun autre domaine n'est lié, le microprogramme met automatiquement le système hors tension.
Puisqu'aucun autre domaine n'est lié, le microprogramme effectue automatiquement un cycle d'alimentation du système avant de le réinitialiser. Lorsque le système redémarre, il initialise la dernière configuration Logical Domains enregistrée ou explicitement définie.
Dans certaines circonstances, Logical Domains Manager arrondit l'allocation de mémoire requise au multiple supérieur suivant de 8 kilo-octets ou 4 mégaoctets. L'exemple suivant le démontre dans le résultat de la commande ldm list-domain -l, où la valeur de contrainte est inférieure à la taille réelle allouée :
Memory: Constraints: 1965 M raddr paddr5 size 0x1000000 0x291000000 1968M
Les mises à jour de variables persistent après la réinitialisation du domaine, mais pas après un cycle d'alimentation du système, à moins qu'elles ne soient lancées à partir du microprogramme OpenBoot sur le domaine de contrôle ou suivies de l'enregistrement de la configuration sur le contrôleur système.
Dans ce contexte, il est important de noter qu'une réinitialisation du domaine de contrôle peut déclencher un cycle d'alimentation du système :
Lorsque le domaine de contrôle se réinitialise, si aucun domaine invité n'est lié, et en l'absence de reconfiguration différée, le contrôleur système effectue un cycle d'alimentation du système.
Lorsque le domaine de contrôle se réinitialise, si des domaines invités sont liés ou actifs (ou si le domaine de contrôle est en pleine reconfiguration différée), le contrôleur système n'effectue pas de cycle d'alimentation du système.
Les variables Logical Domains d'un domaine peuvent être spécifiées en suivant l'une des méthodes suivantes :
A l'invite OpenBoot
A l'aide de la commande eeprom(1M) du SE Oracle Solaris
A l'aide de la CLI Logical Domains Manager (ldm)
En modifiant, de manière limitée, à partir du contrôleur système avec la commande bootmode ; en fait, uniquement certaines variables et seulement dans la configuration factory-default
Le but est que les mises à jour de variables effectuées par l'une de ces méthodes persistent après les réinitialisations du domaine. Les mises à jour de variables se reflètent toujours dans toutes les configurations de domaine logique ultérieures enregistrées sur le contrôleur système.
Dans le logiciel Oracle VM Server for SPARC 3.0, il y a quelques cas où les mises à jour de variables ne persistent pas comme prévu :
Toutes les méthodes de mise à jour d'une variable persistent pour toutes les réinitialisations de ce domaine. Toutefois, elles ne persistent pas après un cycle d'alimentation du système, sauf si une configuration de domaine logique ultérieure est enregistrée sur le contrôleur système. Les mises à jour d'une variable se font au moyen du microprogramme OpenBoot et des commandes eeprom et ldm. De plus, sur le domaine de contrôle, les mises à jour effectuées en utilisant le microprogramme OpenBoot persistent après un cycle d'alimentation du système, et ce, même sans enregistrer par la suite une nouvelle configuration de domaine logique sur le contrôleur système.
Dans tous les cas, lors du rétablissement de la configuration usine par défaut à partir d'une configuration générée par Logical Domains Manager, toutes les variables Logical Domains reprennent au départ leurs valeurs par défaut.
Si vous craignez que les variables Logical Domains changent, procédez de l'une des manières suivantes :
Accédez à l'invite ok du système et mettez à jour les variables.
Mettez à jour les variables pendant que Logical Domains Manager est désactivé :
# svcadm disable ldmd update variables # svcadm enable ldmd
Si vous exécutez Live Upgrade, effectuez les opérations suivantes :
# svcadm disable -t ldmd # luactivate be3 # init 6
Si vous modifiez l'heure ou la date sur un domaine logique, par exemple en utilisant la commande ntpdate, le changement persiste après toutes les réinitialisations du domaine, mais pas après un cycle d'alimentation de l'hôte. Pour que les changements de date et d'heure persistent, enregistrez la configuration avec le changement en question sur le contrôleur système et initialisez à partir de cette configuration.
Les ID de bogue ont été conservées pour résoudre ces problèmes : 15375997, 15387338, 15387606 et 15415199.
Sun SNMP (Simple Network Management Protocol) Management Agent ne prend pas en charge plusieurs domaines. Seul un domaine global est pris en charge.
Lorsqu'un domaine primary est à l'état de reconfiguration retardée, l'alimentation des ressources gérées par Oracle VM Server for SPARC est gérée uniquement après la réinitialisation du domaine primary. Les ressources gérées directement par le SE, telles que les CPU gérés par le Power Aware Dispatcher Solaris ne sont pas affectées par cet état.
Les unités cryptographiques discrètes sont uniquement présentes sur les systèmes UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3.
La reconfiguration dynamique des unités cryptographiques vous permet d'ajouter ou de supprimer des unités cryptographiques d'un domaine. Logical Domains Manager détecte automatiquement si un domaine permet la reconfiguration dynamique des unités cryptographiques et active la fonctionnalité pour ce domaine uniquement. De plus, la reconfiguration dynamique des CPU n'est plus désactivée dans les domaines dont des unités cryptographiques sont liées et exécutent une version appropriée du SE Oracle Solaris.
L'exécution de Veritas Volume Manager (VxVM) 5.x sur le SE Oracle Solaris 10 est la seule version prise en charge (testée) pour l'outil Oracle VM Server for SPARC P2V. Les versions antérieures de VxVM, comme 3.x et 4.x exécutées sur les systèmes d'exploitation Solaris 8 et Solaris 9 peuvent également fonctionner. Dans ces cas, la première initialisation après avoir exécuté la commande ldmp2v convert peut engendrer des messages d'avertissement concernant les pilotes VxVM. Vous pouvez ignorer ces messages. Vous pouvez supprimer les anciens packages VRTS* après l'initialisation du domaine invité.
Boot device: disk0:a File and args: SunOS Release 5.10 Version Generic_139555-08 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: normaal Configuring devices. /kernel/drv/sparcv9/vxdmp: undefined symbol 'romp' WARNING: mod_load: cannot load module 'vxdmp' WARNING: vxdmp: unable to resolve dependency, module 'misc/ted' not found /kernel/drv/sparcv9/vxdmp: undefined symbol 'romp' WARNING: mod_load: cannot load module 'vxdmp' WARNING: vxdmp: unable to resolve dependency, module 'misc/ted' not found /kernel/drv/sparcv9/vxio: undefined symbol 'romp' WARNING: mod_load: cannot load module 'vxio' WARNING: vxio: unable to resolve dependency, module 'drv/vxdmp' not found WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER NOTICE: VxVM not started
Pour plus d'informations sur les conditions requises pour le partitionnement forcé des licences Oracle, reportez-vous à la section Partitionnement : partitionnement du serveur/matériel.
Le programme d'installation Oracle Solaris ne comporte pas l'option de mise à niveau lorsque le repère de partition de la tranche sur laquelle réside le système de fichiers root (/) n'est pas défini sur root. Cette situation se produit si le repère n'est pas défini de manière explicite lors de l'étiquetage du disque d'initialisation de l'invité. Vous pouvez utiliser la commande format pour définir le repère de partition comme suit :
AVAILABLE DISK SELECTIONS: 0. c0d0 <SUN-DiskImage-10GB cyl 282 alt 2 hd 96 sec 768> /virtual-devices@100/channel-devices@200/disk@0 1. c4t2d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> /pci@400/pci@0/pci@1/scsi@0/sd@2,0 2. c4t3d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> /pci@400/pci@0/pci@1/scsi@0/sd@3,0 Specify disk (enter its number)[0]: 0 selecting c0d0 [disk formatted, no defect list found] format> p PARTITION MENU: 0 - change `0' partition 1 - change `1' partition 2 - change `2' partition 3 - change `3' partition 4 - change `4' partition 5 - change `5' partition 6 - change `6' partition 7 - change `7' partition select - select a predefined table modify - modify a predefined partition table name - name the current table print - display the current table label - write partition map and label to the disk !<cmd> - execute <cmd>, then return quit partition> 0 Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 0 (0/0/0) 0 Enter partition id tag[unassigned]: root Enter partition permission flags[wm]: Enter new starting cyl[0]: 0 Enter partition size[0b, 0c, 0e, 0.00mb, 0.00gb]: 8g partition> label Ready to label disk, continue? y partition>
Le bloc de mémoire ajouté de manière dynamique ne peut être supprimé dynamiquement que dans sa totalité. Cela implique qu'un sous-ensemble de ce bloc de mémoire ne peut pas être supprimé dynamiquement.
Cette situation se présente si un domaine dont la taille de mémoire est petite est dynamiquement augmenté, comme indiqué dans l'exemple suivant.
# ldm list ldom1 NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldom1 active -n---- 5000 2 1G 0.4% 23h # ldm add-mem 16G ldom1 # ldm rm-mem 8G ldom1 Memory removal failed because all of the memory is in use. # ldm rm-mem 16G ldom1 # ldm list ldom1 NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldom1 active -n---- 5000 2 1G 0.4% 23h
Solution : ajoutez dynamiquement de la mémoire en petites quantités pour réduire les risques de survenance de ce problème.
Reprise : réinitialisez le domaine.
La restauration des archives ufsdump sur un disque virtuel soutenu par un fichier sur un système de fichiers UFS risque de provoquer le blocage du système. Dans ce cas, la commande ldmp2v prepare se ferme. Il est possible que vous rencontriez ce problème si vous restaurez manuellement des archives ufsdump pour préparer la commande ldmp2v prepare -R /altroot lorsque le disque virtuel est un fichier sur un système de fichiers UFS. En raison de la compatibilité avec les archives ufsdump crées précédemment, vous pouvez toujours utiliser la commande ldmp2v prepare pour restaurer des archives ufsdump sur les disques virtuels qui ne sont pas soutenus par un fichier sur un système de fichiers UFS. Toutefois, l'utilisation des archives ufsdump n'est pas recommandée.
N'essayez pas d'exécuter plusieurs opérations de configuration de CPU sur le domaine primary alors que sa reconfiguration est retardée. Si vous tentez d'effectuer plusieurs demandes de configuration de CPU, celles-ci seront rejetées.
Solution : effectuez l'une des opérations suivantes :
Annulez la reconfiguration retardée, lancez-en une autre, puis demandez les modifications de configuration perdues de la dernière reconfiguration retardée.
Réinitialisez le domaine de contrôle à l'aide du nombre erroné de CPU et effectuez les corrections d'allocation nécessaires après la réinitialisation du domaine.
Les sections suivantes décrivent les restrictions qui s'appliquent à la migration de domaine. Les versions du microprogramme du système et du logiciel Logical Domains Manager doivent être compatibles pour que les migrations soient possibles. De même, la CPU doit répondre à certaines exigences pour que la migration de domaine fonctionne.
Remarque - Un domaine invité qui exécute une application sensible au réseau peut subir un bref retard ou une courte interruption pendant le déroulement de la migration.
Si vous tentez une migration en direct à partir d'un domaine initialisé avec la version 8.4 ou une version ultérieure du microprogramme vers un système exécutant une ancienne version du microprogramme, la migration échoue. L'échec est dû à une incompatibilité entre l'API de l'hyperviseur des versions anciennes et celui des versions plus récentes du microprogramme. Dans ce cas, le message suivant apparaît :
# ldm migrate ldg1 root@target Target Password: Domain ldg1 is using features of the system firmware that are not supported in the version of the firmware running on the target machine. Domain Migration of LDom ldg1 failed
Notez que vous pouvez effectuer une migration en direct d'un domaine initialisé sur un système équipé d'une version antérieure à la version 8.4 du microprogramme vers un système qui exécute la version 8.4 ou une version ultérieure du microprogramme.
ID de bogue 15805135 : dans Oracle VM Server for SPARC 3.0, il n'est pas possible de faire migrer un domaine d'un type de plate-forme différent (tel que SPARC T2, SPARC T2 Plus, SPARC T3 ou SPARC T4) vers une plate-forme SPARC T5 ou SPARC M5. Ce type de migration est impossible même si vous définissez cpu-arch=generic.
Pour les plates-formes SPARC T5 et SPARC M5, vous pouvez uniquement effectuer des opérations de migration entre des systèmes dont le type de plate-forme est identique, comme par exemple d'une plate-forme SPARC T5-2 à une plate-forme SPARC T5-8 ou d'une plate-forme SPARC M5-32 à une autre plate-forme SPARC M5-32. Cette restriction s'applique uniquement aux plates-formes SPARC T5 et SPARC M5.
Si le domaine à migrer exécute une version SE Oracle Solaris antérieure au SE Oracle Solaris 10 8/11, le message suivant peut s'afficher au cours de la migration :
Domain domain-name is not running an operating system that is compatible with the latest migration functionality.
Les exigences et les restrictions suivantes en matière de CPU s'appliquent uniquement lorsque vous exécutez un SE antérieur au SE Oracle Solaris 10 8/11 :
Des coeurs complets doivent être alloués au domaine migré. Si le nombre de threads dans le domaine à migrer est inférieur à un coeur complet, les threads supplémentaires ne sont disponibles à aucun domaine tant que le domaine migré n'est pas réinitialisé.
Après une migration, la reconfiguration dynamique (DR) de la CPU est désactivée pour le domaine migré tant qu'il n'a pas été réinitialisé. A ce stade, vous pouvez utiliser la DR sur le domaine migré.
La machine cible doit disposer de suffisamment de coeurs complets totalement libres pour fournir le nombre de threads requis pour le domaine migré. Après la migration, si un coeur complet n'est que partiellement utilisé par le domaine migré, les threads supplémentaires ne sont disponibles à aucun domaine tant que le domaine migré n'est pas réinitialisé.
Ces restrictions s'appliquent également lorsque vous tentez de migrer un domaine exécuté dans OpenBoot ou le débogeur de noyau. Reportez-vous à la section Migration d’un domaine à partir de la PROM OpenBoot ou un domaine en cours d’exécution dans le débogueur de noyau du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Cette section récapitule les problèmes que vous risquez de rencontrer lors de l'utilisation du logiciel Oracle VM Server for SPARC Management Information Base (MIB).
ID de bogue 15376861 : des tables SNMP vides sont renvoyées lorsque vous interrogez le logiciel Oracle VM Server for SPARC MIB 2.1 à l'aide de la commande snmptable et des options -v2c ou -v3. La commande snmptable avec l'option -v1 fonctionne comme prévu.
Solution : utilisez l'option -CB pour utiliser uniquement GETNEXT, et non GETBULK, pour l'extraction des données. Reportez-vous à la section Procédure de récupération d’objets Oracle VM Server for SPARC MIB du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Cette section récapitule les bogues que vous risquez de rencontrer lors de l'utilisation de cette version du logiciel. Les bogues les plus récents sont décrits en premier. Des solutions de contournement et des procédures de récupération sont spécifiées, le cas échéant.
ID de bogue 16486383 : 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 : effectuez l'une des opérations solutions :
Assurez-vous que lorsque vous affectez des périphériques PCI à un domaine invité, la carte se trouve physiquement dans le même DCU que les coeurs.
Affectez manuellement les coeurs afin de disposer d'une certaine flexibilité pour le placement de la carte.
Par exemple, pour un périphérique PCI sur IOU0 (pci_0 à pci_15), choisissez un coeur entre 0 et 127 et allouez-le au domaine.
# ldm add-core cid=16 domain
Visualisez les coeurs du système à l'aide de la commande suivante :
# ldm ls-devices -a core
Pour un périphérique PCI sur IOU1 (pci_16 à pci_31), choisissez un coeur entre 128 et 255. Pour un périphérique PCI sur IOU2 (pci_32 à pci_47), choisissez un coeur entre 256 et 383. Pour un périphérique PCI sur IOU3 (pci_48 à pci_63), choisissez un coeur entre 384 et 511.
ID de bogue 16426940 : sur un système SPARC T5 ou SPARC M5 avec configuration SR-IOV, vous risquez de subir un blocage qui ne peut pas être arrêté à l'aide de Ctrl-C. Ce blocage se produit rarement lorsque vous utilisez la commande ldm unbind ou la commande ldm rm-io.
Solution : réinitialisez l'instance du SE Oracle Solaris qui s'exécute sur le domaine primary. Réinitialisez également les domaines invités exécutant des ressources d'E/S partagées par le domaine primary.
ID de bogue 16301304 : dans certaines circonstances, un coeur défectueux n'est pas immédiatement mis sur liste noire par Logical Domains Manager. Par conséquent, il est possible d'ajouter des strands issus du coeur défectueux à un domaine. Si de tels strands sont ajoutés à l'aide de la reconfiguration dynamique de CPU virtuelle, le domaine invité panique et un message semblable au suivant s'affiche :
panic[cpu10]/thread=2a1003e9c60: promif_start_cpu: failed to start cpu 12 (6)
Si un strand défectueux est ajouté à un domaine qui n'est pas en cours d'exécution, les messages suivants apparaissent sur la console lors du démarrage du domaine :
NOTICE: cpux is not runnable and will not be brought online NOTICE: cpux removed from system
Ces messages apparaissent également lors de toutes les réinitialisations ultérieures. Ces messages ne posent pas problème dans le domaine en cours d'exécution, mais les CPU figurant dans la liste ne sont pas disponible au domaine invité.
Solution : pour éviter ces problèmes, écartez les strands défectueux de tous les domaines. Si les strands défectueux ne sont pas utilisés, ils ne peuvent pas avoir d'impact négatif sur les autres domaines du système.
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 : si vous décidez de désactiver un emplacement PCIe sur ILOM, assurez-vous que l'emplacement PCIe n'est pas affecté à un domaine à l'aide de la fonction d'E/S directes (DIO). En d'autres termes, assurez-vous d'abord que l'emplacement PCIe est affecté au domaine root correspondant avant de désactiver l'emplacement sur ILOM.
Si vous désactivez l'emplacement PCIe sur ILOM alors que l'emplacement PCIe est affecté à un domaine avec DIO, arrêtez le domaine concerné et réaffectez le périphérique au domaine root pour que le comportement soit normal.
ID de bogue 16238762 : sur un serveur SPARC M5-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.
Logical Domains génère un nouveau GMD qui reflète les informations de latence correctes, mais le SE Oracle Solaris ne peut pas analyser les nouvelles informations et panique.
Solution : pour éviter la panique, n'effectuez pas les étapes énumérées dans la description du problème.
Toutefois, si vous avez déjà effectué ces étapes et que vous avez subi la panique, effectuez les opérations suivantes :
Effectuez une action après avoir initialisé une configuration enregistrée dans un domaine physique de taille moindre. Retirez une CPU de chaque domaine actif par exemple.
Réinitialisez le domaine.
Dissociez le domaine.
Liez à nouveau tout domaine lié.
Enregistrez une nouvelle configuration sur le processeur de service.
ID de bogue 16232834 : la plate-forme SPARC M5 comprend des disques à deux ports internes et les deux chemins associés. Un basculement du complexe root risque d'entraîner une configuration de domaine invité d'E/S directes incorrecte.
Solution : faites en sorte que les deux cartes EMS (PCIe Express Module) impaires ou les deux cartes EMS paires soient affectées au même domaine. Par exemple, si les deux cartes EMS1 et EMS3 sont affectées à un même domaine, les deux chemins d'accès au disque résident dans le domaine concerné. Il en va de même lorsque les cartes EMS0 et EMS2 sont affectées au même domaine.
Procédez comme suit :
Désactivez la fonction de basculement du complexe root à l'aide d'ILOM.
-> set /HOSTx ioreconfigure=false
x peut être remplacé par une valeur quelconque allant de 0 à 3.
A l'aide de la commande ldm add-io, affectez les deux cartes EMS impaires ou les deux cartes EMS paires de la même unité d'E/S (IOU, I/O unit) à un domaine invité.
Dans cet exemple de configuration hôte formé d'une unité de configuration (DCU, domain configuration unit) à deux domaines, les commandes suivantes affectent des cartes EMS au domaine invité ldg1.
Les complexes root pci_40 et pci_44 sont tout d'abord supprimés du domaine de contrôle.
# ldm rm-io pci_40 primary # ldm rm-io pci_44 primary
Puis les complexes root pci_40 et pci_42 sont ajoutés au domaine invité ldg1.
# ldm add-io pci_40 lgd1 # ldm add-io pci_44 lgd1
De même, vous pouvez affecter les complexes root pci_48 et pci_52 ou les quatre bus au domaine hôte.
Après avoir apporté ces modifications, affichez la configuration mise à jour à l'aide de la commande ldm ls-io.
# ldm ls-io NAME TYPE BUS DOMAIN STATUS ---- ---- --- ------ ------ pci_32 BUS pci_32 primary pci_33 BUS pci_33 primary pci_34 BUS pci_34 primary pci_35 BUS pci_35 primary pci_36 BUS pci_36 primary pci_37 BUS pci_37 primary pci_38 BUS pci_38 primary pci_39 BUS pci_39 primary pci_40 BUS pci_40 primary pci_41 BUS pci_41 primary pci_42 BUS pci_42 primary pci_43 BUS pci_43 primary pci_44 BUS pci_44 primary pci_45 BUS pci_45 primary pci_46 BUS pci_46 primary pci_47 BUS pci_47 primary pci_48 BUS pci_48 primary pci_49 BUS pci_49 primary pci_50 BUS pci_50 primary pci_51 BUS pci_51 primary pci_52 BUS pci_52 primary pci_53 BUS pci_53 primary pci_54 BUS pci_54 primary pci_55 BUS pci_55 primary pci_56 BUS pci_56 primary pci_57 BUS pci_57 primary pci_58 BUS pci_58 primary pci_59 BUS pci_59 primary /SYS/IOU2/PCIE3 PCIE pci_32 primary OCC /SYS/IOU2/EMS1/CARD/NET0 PCIE pci_32 primary OCC /SYS/IOU2/EMS1/CARD/SCSI PCIE pci_32 primary OCC /SYS/IOU2/PCIE2 PCIE pci_33 primary OCC /SYS/IOU2/PCIE5 PCIE pci_34 primary EMP /SYS/IOU2/PCIE8 PCIE pci_35 primary EMP /SYS/IOU2/PCIE11 PCIE pci_36 primary EMP /SYS/IOU2/EMS3/CARD/NET0 PCIE pci_36 primary OCC /SYS/IOU2/EMS3/CARD/SCSI PCIE pci_36 primary OCC /SYS/IOU2/PCIE10 PCIE pci_37 primary OCC /SYS/IOU2/PCIE13 PCIE pci_38 primary OCC /SYS/IOU2/PCIE16 PCIE pci_39 primary OCC /SYS/IOU2/PCIE6 PCIE pci_40 primary EMP /SYS/IOU2/EMS2/CARD/NET0 PCIE pci_40 primary OCC /SYS/IOU2/EMS2/CARD/SCSI PCIE pci_40 primary OCC /SYS/IOU2/PCIE7 PCIE pci_41 primary EMP /SYS/IOU2/PCIE4 PCIE pci_42 primary EMP /SYS/IOU2/PCIE1 PCIE pci_43 primary OCC /SYS/IOU2/PCIE14 PCIE pci_44 primary OCC /SYS/IOU2/EMS4/CARD/NET0 PCIE pci_44 primary OCC /SYS/IOU2/EMS4/CARD/SCSI PCIE pci_44 primary OCC /SYS/IOU2/PCIE15 PCIE pci_45 primary OCC /SYS/IOU2/PCIE12 PCIE pci_46 primary EMP /SYS/IOU2/PCIE9 PCIE pci_47 primary EMP /SYS/IOU3/PCIE3 PCIE pci_48 primary EMP /SYS/IOU3/EMS1/CARD/NET0 PCIE pci_48 primary OCC /SYS/IOU3/EMS1/CARD/SCSI PCIE pci_48 primary OCC /SYS/IOU3/PCIE2 PCIE pci_49 primary OCC /SYS/IOU3/PCIE5 PCIE pci_50 primary OCC /SYS/IOU3/PCIE8 PCIE pci_51 primary EMP /SYS/IOU3/PCIE11 PCIE pci_52 primary EMP /SYS/IOU3/PCIE12 PCIE pci_52 primary EMP /SYS/IOU3/EMS3/CARD/NET0 PCIE pci_52 primary OCC /SYS/IOU3/EMS3/CARD/SCSI PCIE pci_52 primary OCC /SYS/IOU3/PCIE9 PCIE pci_53 primary OCC /SYS/IOU3/PCIE10 PCIE pci_53 primary OCC /SYS/IOU3/PCIE13 PCIE pci_54 primary EMP /SYS/IOU3/PCIE14 PCIE pci_54 primary EMP /SYS/IOU3/EMS4/CARD/NET0 PCIE pci_54 primary OCC /SYS/IOU3/EMS4/CARD/SCSI PCIE pci_54 primary OCC /SYS/IOU3/PCIE15 PCIE pci_55 primary EMP /SYS/IOU3/PCIE16 PCIE pci_55 primary EMP /SYS/IOU3/PCIE6 PCIE pci_56 primary OCC /SYS/IOU3/EMS2/CARD/NET0 PCIE pci_56 primary OCC
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 : 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 :
# ldm add-config new-config-more-dcus
Arrêtez le domaine.
Arrêtez l'hôte.
-> stop /HOST
Démarrez l'hôte.
-> start /HOST
ID de bogue 16224353 : après avoir réinitialisé le domaine primary, les instances ixgbevf du domaine primary risquent de ne pas fonctionner.
Solution : aucune.
ID de bogue 16219069 : sur un domaine primary exécutant le SE Oracle Solaris 10 1/13, les interfaces de fonction virtuelle risquent de ne pas être automatiquement raccordées ou de ne pas se voir attribuer d'adresse IP sur la base du fichier /etc/hostname.vf-interface.
Ce problème se produit lorsque vous initialisez ou réinitialisez un système SPARC T3, SPARC T4 ou SPARC T5 exécutant le SE Oracle Solaris 10 1/13 sur le domaine primary. Ce problème affecte les fonctions virtuelles créées sur les fonctions physiques intégrées et sur les fonctions physiques additionnelles. Ce problème ne se produit pas lorsque vous initialisez une image de domaine invité Logical Domains.
ID de bogue 16205895 : dans chaque domaine physique SPARC M5, le plafonnement de la consommation énergétique surveille le capteur de consommation énergétique du domaine concerné, /SYS/VPS, pour déterminer à quel moment les fréquences de CPU doivent être ajustées pour respecter la limite énergétique. Ce capteur n'est mis à jour que toutes les 20 à 30 secondes. Toutefois, le capteur est interrogé et les ajustements énergétiques sont effectués en fonction de cette valeur à quelques secondes d'intervalle. Les valeurs obsolètes de consommation d'énergie peuvent entraîner des pics dans les régulations et dérégulations des fréquences de CPU tandis que le système s'ajuste inutilement.
Solution : n'utilisez pas de plafonnement de la consommation énergétique.
ID de bogue 16098592 : lorsqu'un périphérique de fonction physique ou de fonction virtuelle PCIe est prêté à un domaine invité, vous pouvez utiliser la CLI d'ILOM ou la structure de gestion des pannes pour marquer le périphérique comme désactivé dans la base de données dynamique (DDB, dynamic database). Au démarrage suivant du système (mise sous tension, réinitialisation), la configuration de l'hôte reflète l'état de la DDB à l'intention de l'hyperviseur au moyen du descripteur de la machine (lorsque des MD PRI/invités, etc. sont créés). L'hyperviseur désactive ces périphériques mais le SE Oracle Solaris ne sait pas que le périphérique est désactivé.
Lorsque le domaine invité qui contient ce périphérique est démarré, le domaine se bloque. Le domaine se bloque car l'instance d'Oracle Solaris propriétaire de la topologie Fabric PCIe ne peut pas afficher le périphérique étant donné que l'hyperviseur a désactivé le périphérique. Par conséquent, lorsque OBP tente de sonder les périphériques PCIe, l'hyperviseur bloque l'accès de sorte que l'OBP réessaye continuellement.
Solution : supprimez de ce domaine invité les périphériques qui sont passés à l'état UNK (inconnu) en procédant comme suit :
Arrêtez le domaine invité.
Supprimez du domaine invité les périphériques qui se trouvent dans l'état inconnu.
Utilisez la commande ldm rm-io.
Redémarrez le domaine invité.
ID de bogue 16080855 : lors d'une réinitialisation ou d'un arrêt du domaine primary, le domaine primary peut subir une panique du noyau avec un message semblable au suivant :
panic[cpu2]/thread=c40043b818a0: mutex_enter: bad mutex, lp=c4005fa01c88 owner=c4005f70aa80 thread=c40043b818a0 000002a1075c3630 ldc:ldc_mem_rdwr_cookie+20 (c4005fa01c80, c4004e2c2000,2a1075c37c8, 6c80000, 1, 0) %l0-3: 00000000001356a4 0000000000136800 0000000000000380 00000000000002ff %l4-7: 00000000001ad3f8 0000000000000004 00000000ffbffb9c 0000c4005fa01c88 000002a1075c3710 vldc:i_vldc_ioctl_write_cookie+a4 (c4004c400030, 380,ffbff898, 100003, 0, 70233400) %l0-3: 0000000006c80000 0000000000156dc8 0000000000000380 0000000000100003 %l4-7: 00000000702337b0 000002a1075c37c8 0000000000040000 0000000000000000 000002a1075c37f0 vldc:vldc_ioctl+1a4 (3101, c4004c400030, ffbff898,c4004c400000, c4004c438030, 0) %l0-3: 0000000000100003 0000000000000000 000000007b340400 0000c4004c438030 %l4-7: 0000c4004c400030 0000000000000000 0000000000000000 0000000000000000 000002a1075c38a0 genunix:fop_ioctl+d0 (c4004d327800, 0, ffbff898, 100003,c4004384f718, 2a1075c3acc) %l0-3: 0000000000003103 0000000000100003 000000000133ce94 0000c4002352a480 %l4-7: 0000000000000000 0000000000000002 00000000000000c0 0000000000000000 000002a1075c3970 genunix:ioctl+16c (3, 3103, ffbff898, 3, 134d50, 0) %l0-3: 0000c40040e00a50 000000000000c6d3 0000000000000003 0000030000002000 %l4-7: 0000000000000003 0000000000000004 0000000000000000 0000000000000000
Reprise : autorisez le domaine primary à se réinitialiser. Si le domaine primary est configuré pour ne pas se réinitialiser après un arrêt brutal, initialisez-le manuellement.
ID de bogue 16071170 : sur un système SPARC M5-32, 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. Cette erreur est signalée pour chaque port.
Solution : vous pouvez ignorer ces messages. Ces messages indiquent seulement que les contrôleurs SAS LSI du système sont compatibles avec SR-IOV, mais qu'aucune prise en charge de SR-IOV n'est disponible pour ce matériel.
ID de bogue 16059331 : le pilote sxge ne peut pas définir les MTU Jumbo correctement pour ses fonctions virtuelles sur le domaine primary.
Solution : modifiez manuellement le fichier /kernel/drv/sxge.conf pour configurer le MTU Jumbo sur les interfaces de fonction virtuelle sxge dans le domaine invité.
ID de bogue 16016576 : si Logical Domains Manager est redémarré, soit manuellement, soit en raison d'une réinitialisation du domaine de contrôle, toutes les ressources défectueuses qui ont été placées sur liste noire deviennent disponibles. Ces ressources sont à tort marquées comme disponibles et en attente d'évacuation, bien qu'elles aient été précédemment évacuées et ajoutées à la liste noire. Logical Domains Manager n'empêche pas l'ajout de telles ressources à un domaine.
Reprise : aucune récupération n'est nécessaire. Les ressources évacuées ne sont assignées à aucun domaine et n'affectent donc pas la configuration actuelle du système. Toutefois, étant donné que ces ressources étaient précédemment défectueuses, prenez garde de ne pas les attribuer à un domaine du système.
ID de bogue 15974640 : la commande ldm ne parvient pas à définir correctement les valeurs des propriétés mac-addr et alt-mac-addrs pour le périphérique sxge. Par conséquent, le démon ldmd signale une adresse MAC incohérente. D'autre part, tous les groupements de liaisons basés sur l'adresse MAC de la VNIC échouent également.
ID de bogue 15974547 : en cas d'exécution sur un système SPARC T5-1B comportant sxge, la sortie ldm list-io -d PF-device n'affiche pas les propriétés max-vlans ou max-vf-mtu. Ces propriétés sont présentes sur les systèmes SPARC T5-1B avec ixgbe ainsi que sur les systèmes autres que les lames.
La valeur de la propriété max-vlans est manquante. La valeur doit être égale à 0 car le périphérique sxge ne prend pas en charge le balisage VLAN du matériel. La valeur de propriété max-vf-mtu est fixée à 1500, ce qui empêche le périphérique de fonction physique de définir le MTU Jumbo pour les fonctions virtuelles.
ID de bogue 15858731 : pour les systèmes Fujitsu M10, la restriction suivante remplace les informations décrites dans la section Migration d’un domaine à partir de la PROM OpenBoot ou un domaine en cours d’exécution dans le débogueur de noyau du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Lorsqu'un domaine à migrer est en cours d'exécution dans OpenBoot ou dans le débogueur de noyau (kmdb), la tentative de migration échoue toujours si la machine source ou cible est un système Fujitsu M10. Dans le cas où le domaine à migrer ne contient qu'une seule CPU, le message d'erreur suivant est susceptible de s'afficher :
# ldm migrate ldg1 system2 Non-cooperative migration is not supported on this platform.
ID de bogue 15829698 : la commande ldmconfig ne fonctionne pas avec le logiciel Oracle VM Server for SPARC 3.0 car elle fonctionne uniquement lorsque le système exécute une configuration factory-default non modifiée. Lorsqu'un bogue se produit dans Oracle VM Server for SPARC 3.0, la configuration est toujours signalée comme modifiée.
Solution : au lieu d'effectuer une installation initiale d'Oracle VM Server for SPARC 3.0, installez d'abord Oracle VM Server for SPARC 2.2 puis exécutez ldmconfig. Une fois que les domaines sont créés, effectuez la mise à niveau du package SUNWldm vers Oracle VM Server for SPARC 3.0.
ID de bogue 15826354 : la reconfiguration dynamique 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 : attendez quelques minutes, puis réexécutez la commande ldm set-vcpu :
# ldm set-vcpu 1 ldg0 # ldm ls NAME STATE FLAGS CONS VCPU MEMORY UTIL NORM UPTIME primary active -n-cv- UART 7 20G 0.9% 0.1% 1h 50m ldg0 active -n---- 5000 1 16G 52% 0.0% 15m
Notez que 760 dépasse le maximum recommandé.
ID de bogue 15825538 : en cas d'exécution d'une migration en direct sécurisée (ldm migrate) sur un domaine logique configuré avec les fonctions d'interfaces d'E/S réseau hybrides (mode=hybrid) et de migration entre les CPU activées (cpu-arch=generic), le délai d'attente de la migration peut expirer et le domaine rester dans un état suspendu.
Reprise : redémarrez le domaine logique.
Solution : n'utilisez pas de périphériques de réseau virtuel d'E/S hybride pour une migration en direct entre les CPU.
ID de bogue 15825330 : Oracle VM Server for SPARC 3.0 se bloque au démarrage de certaines configurations SPARC T4-4 comportant une seule carte de processeur.
Solution : 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 de démarrerOracle VM Server for SPARC 3.0.
ID de bogue 15825060 : lorsque vous utilisez la migration en direct pour migrer un domaine créé sur un système SPARC T3 ou SPARC T4 vers un système UltraSPARC T2 ou UltraSPARC T2 Plus, l'opération de reconfiguration dynamique des CPU qui en découle peut entraîner une panique du système. Le message de panique affiché est similaire à ce qui suit :
panic[cpu8]/thread=2a102491c60: cpu8: dev_mondo queue configuration failed, error 6
Reprise : aucune.
Solution : lorsque vous migrez un domaine créé sur un système SPARC T3 ou SPARC T4 vers un système UltraSPARC T2 ou UltraSPARC T2 Plus, ne migrez pas de domaine actif. Arrêtez plutôt le domaine avant de démarrer le processus de migration.
ID de bogue 15824270 : il est possible qu'un domaine qui exécute le SE Oracle Solaris 11.1 et dont les cessions de mémoires sont très fragmentées ne puisse pas se réinitialiser. Dans ce cas, le message suivant s'affiche :
ERROR: Last Trap: Fast Data Access MMU Miss
Solution : essayez d'abord de varier la taille de la mémoire associée au domaine invité qui ne s'initialise pas. Si cette solution échoue ou si le domaine primary est affecté, arrêtez le système et redémarrez dans une autre configuration de processeur de service.
ID de bogue 15823255 : un domaine sur un système SPARC M5 comportant deux DCU ou plus est susceptible de subir une panique dans les conditions suivantes :
Le domaine doit être configuré avec deux DCU au moins
Un seul DCU est configuré avec des CPU
Les autres DCU ne doivent pas être configurés avec des CPU, mais avec de la mémoire
L'une des opérations suivantes entraîne la panique :
Démarrage ou arrêt des CPU
Réalisation d'une reconfiguration dynamique des CPU
Création ou suppression d'un jeu de processeurs
Ajout ou suppression de processeurs d'un jeu de processeurs
Vous pouvez voir le message d'erreur grave sur la console et dans le fichier /var/adm/messages lorsque le système se réinitialise :
panlc [cpu4]/thread=0x30012a008: : lpl_topo_verify failed: -5
Solution : effectuez les opérations suivantes :
Evitez d'effectuer les opérations susceptibles d'entraîner la panique.
Ajoutez la ligne suivante dans le fichier /etc/system :
set lgrp_topo_levels=2
Réinitialisez le système.
Après la réinitialisation du système, vous pouvez en toute sécurité effectuer les opérations qui provoquaient la panique.
ID de bogue 15823203 : les périphériques d'extrémité PCIe ou les fonctions virtuelles SR-IOV d'un domaine root propriétaire d'un bus PCIe ne peuvent pas être assignés à un autre domaine root. En revanche, un périphérique d'extrémité PCIe ou une fonction virtuelle de bus PCIe peuvent être affectés au domaine root propriétaire du bus.
ID de bogue 15822313 : sur un système qui exécute le SE Oracle Solaris 11.1, l'exécution d'opérations de reconfiguration dynamique (DR) de CPU sur un domaine qui a été migré peut entraîner une panique du domaine invité.
Solution : n'exécutez pas les opérations de DR des CPU du gestionnaire de domaine tant que le domaine migré n'a pas été réinitialisé.
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 : ne modifiez pas le statut de la propriété threading d'un domaine invité tant qu'il n'a pas été réinitialisé.
ID de bogue 15820741 : sur un système Oracle Solaris 11.1 comportant deux domaines avec des configurations d'E/S directes, le domaine de contrôle peut se bloquer lors de la réinitialisation.
Reprise : pour effectuer une reprise après un blocage de la réinitialisation, effectuez une remise à zéro du domaine de contrôle en lançant la commande suivante sur le processeur de service :
-> reset -f /HOST/domain/control
ID de bogue 15818302 : vous ne pouvez pas spécifier l'option --dry-run pour la commande ldm rm-io.
Solution : utilisez plutôt l'option -n.
ID de bogue 15816287 : dans de rares circonstances, un domaine logique risque de paniquer si son périphérique réseau virtuel ou son commutateur virtuel est soumis à une charge de travail importante.
Solution : appliquez l'une des solutions de contournement. Il est préférable de mettre en oeuvre la solution /etc/system pour limiter l'impact sur les performances du système.
Ajoutez la ligne suivante au fichier /etc/system pour tous les domaines comportant un commutateur virtuel, puis réinitialisez les domaines concernés pour que les modifications prennent effet :
set vsw:vsw_ldc_tx_serialize=1
Définissez la valeur de la propriété extended-mapin-space sur off pour tous les domaines comportant un périphérique réseau virtuel ou un commutateur virtuel.
# ldm set-domain extended-mapin-space=off ldom
ID de bogue 15815409 : la migration d'un domaine actif peut échouer si la machine source et la machine cible exécutent différentes versions de microprogramme système. Ce type d'échec se produit dans les situations suivantes :
SPARC T3 ou SPARC T4. La machine source exécute une version de microprogramme antérieure à la version 8.1.5 et la machine cible exécute au minimum la version 8.1.5.
UltraSPARC T2 ou UltraSPARC T2 Plus. La machine source exécute une version de microprogramme antérieure à la version 7.4.3 et la machine cible exécute au minimum la version 7.4.3.
Reprise : effectuez une des actions suivantes :
Installez le microprogramme système approprié sur le système qui exécute la version antérieure du microprogramme système :
SPARC T3 ou SPARC T4. Installez au minimum la version 8.1.5 du microprogramme système.
UltraSPARC T2 ou UltraSPARC T2 Plus. Installez au minimum la version 7.4.3 du microprogramme système.
Si vous ne pouvez pas mettre à niveau le système qui exécute le microprogramme antérieur, installez la version 8.2.2.b du microprogramme système sur le système qui exécute le nouveau microprogramme.
Solution : arrêtez le domaine avant d'effectuer la migration.
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 : aucune.
ID de bogue 15803617 : le domaine primary ou un domaine invité actif risque de paniquer durant une opération de migration en direct ou d'annulation de la liaison si le domaine est configuré avec des périphériques réseau virtuels d'E/S hybrides.
Reprise : redémarrez le domaine affecté.
Solution : n'utilisez pas de périphériques réseau virtuels d'E/S hybrides.
ID de bogue 15801579 : dans de rares circonstances, il est impossible d'arrêter un domaine à l'aide des commandes ldm stop ou ldm stop -f. En général, ce problème survient uniquement si un autre problème entraîne un blocage forcé du domaine ou que le domaine effectue des réinitialisations en boucle très rapides.
Solution : si vous ne pouvez pas vous connecter directement au domaine, essayez de lancer plusieurs fois la commande ldm stop -f. Il se peut que l'hyperviseur ne puisse pas arrêter le domaine pendant le délai d'exécution de cette commande.
Si cette solution ne permet pas de régler le problème, effectuez un cycle d'alimentation du système.
ID de bogue 15789903 : si le domaine de contrôle est réinitialisé lorsque des périphériques d'extrémité PCIe sont affectés à 11 domaines invités ou plus, les périphériques PCIe sont inaccessibles sur le domaine invité.
Reprise : arrêtez et redémarrez les domaines invités affectés.
Solution : configurez une relation de dépendance de domaine entre le domaine de contrôle et les domaines invités ayant des périphériques d'extrémité PCIe leur étant assignés. La relation de dépendance suivante garantit que les domaines avec des périphériques d'extrémité PCIe sont automatiquement arrêtés lorsque le domaine de contrôle est réinitialisé pour quelque raison que ce soit :
primary# ldm set-domain failure-policy=stop primary primary# ldm set-domain master=primary ldom
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 : utilisez la commande ldm list-io pour enregistrer les informations relatives aux fonctions virtuelles, puis utilisez la commande ldm rm-dom pour détruire chaque domaine affecté. Utilisez ensuite la commande ldm create-vf pour créer toutes les fonctions virtuelles requises. Vous pouvez désormais utiliser la commande ldm pour regénérer les domaines. 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 Echec de la création d'un nouveau domaine avec périphériques de fonction virtuelle correct par la commande ldm init-system.
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 : vous pouvez ignorer ce message.
ID de bogue 15783031 : lorsque vous utilisez la commande ldm list-constraints -x pour enregistrer les contraintes vers un fichier XML, les détails de la fonction virtuelle ne sont pas enregistrés. Par conséquent, lorsque la configuration est redéfinie sur factory-default et que la commande ldm init-system est exécutée pour recréer la configuration enregistrée, les fonctions virtuelles ne sont pas créées et la tentative de liaison des domaines échoue.
Solution : si une configuration existante possède des fonctions virtuelles, enregistrez toutes les informations relatives à ces fonctions virtuelles. Vous pourrez ensuite utiliser ces informations pour recréer manuellement les fonctions virtuelles avant d'exécuter la commande ldm init-system.
La procédure suivante permet d'enregistrer toutes les informations relatives aux fonctions virtuelles à utiliser ultérieurement.
Enregistrez la configuration du domaine dans un fichier, vfs.txt, en vue de la création de nouvelles fonctions virtuelles.
primary# ldm list-io -l -p | grep "type=VF" >vfs.txt
Une entrée de fonction virtuelle type apparaît dans le fichier vfs.txt comme suit :
|dev=pci@400/pci@1/pci@0/pci@4/network@0,83|alias=/SYS/MB/NET0/IOVNET.PF1.VF1| status=RDY|domain=ldg1|type=VF|class=NETWORK |proptype=class|mac-addr=00:14:4f:f9:74:d0 |proptype=class|vlan-ids=3,5,7 |proptype=class|mtu=1500 |proptype=device|unicast-slots=6
La première ligne est volontairement divisée en deux lignes pour une meilleure lisibilité. Il s'agit d'une seule et même ligne dans le fichier vfs.txt.
Redéfinissez le domaine sur la configuration factory-default.
Réinitialisez le domaine de contrôle.
Créez les fonctions virtuelles en fonction des informations du fichier vfs.txt.
Pour chacune de ces entrées utilisez la commande ldm create-vfpour recréer la fonction virtuelle avec son nom et ses propriétés d'origine. Utilisez la commande suivante pour l'exemple de fonction virtuelle :
primary# ldm create-vf mac-addr=00:14:4f:f9:74:d0 vid=3,5,7 mtu=1500 \ unicast-slots=6 /SYS/MB/NET0/IOVNET.PF1
Pour des détails relatifs aux propriétés class et device, reportez-vous à la page de manuel ldm(1M).
Remarque - Le nom de la fonction virtuelle est généré à partir du nom de sa fonction physique parent. Par conséquent, exécutez les commandes ldm create-vf en augmentant l'ordre numérique selon la partie fonction virtuelle du nom. Par exemple, la fonction physique /SYS/MB/NET0/IOVNET.PF1 contient les fonctions virtuelles enfant suivantes :
/SYS/MB/NET0/IOVNET.PF1.VF0 mac-addr=00:14:4f:f9:74:d0 /SYS/MB/NET0/IOVNET.PF1.VF1 mac-addr=00:14:4f:f9:74:d1
Les commandes suivantes créent les fonctions virtuelles :
primary# ldm create-vf mac-addr=00:14:4f:f9:74:d0 /SYS/MB/NET0/IOVNET.PF1 Created new VF: /SYS/MB/NET0/IOVNET.PF1.VF0 primary# ldm create-vf mac-addr=00:14:4f:f9:74:d1 /SYS/MB/NET0/IOVNET.PF1 Created new VF: /SYS/MB/NET0/IOVNET.PF1.VF1
La première commande ldm create-vf entraîne le passage du système en mode reconfiguration retardée.
Assurez-vous que la nouvelle configuration inclut les fonctions virtuelles que vous avez créées manuellement.
primary# ldm list-io -l -p | grep "type=VF" >vfs.after.txt
Comparez le contenu du fichier vfs.after.txt à celui du fichier vfs.txt.
Réinitialisez le domaine de contrôle.
Reconfigurez un domaine à partir d'un fichier XML.
primary# ldm init-system -i file.xml
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 lorsqu'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 : évitez de créer un trop grand nombre de périphériques de réseau virtuel connectés au même commutateur virtuel. Le cas échéant, définissez la propriété inter-vnet-link sur off dans le commutateur virtuel. N'oubliez pas que cette option risque d'avoir une incidence négative sur les performances du réseau entre les domaines invités.
ID de bogue 15780217 : lorsque vous tentez de définir plus d'emplacements unica de fonctions physiques ixgbe et de fonctions virtuelles que le maximum autorisé par la limite, la commande réussit. Tentative de dépassement de la limite maximale censée entraîner un échec mais n'en entraînant aucun.
Utilisez la commande suivante pour identifier le nombre maximal d'emplacements unicast pris en charge par le périphérique :
# ldm list-io -d pf-name
Assurez-vous ensuite que le nombre total d'emplacements unicas attribué à chaque fonction physique ne dépasse pas la valeur maximale.
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 noyau le plus bas, il ne peut pas être partagé avec un autre domaine si vous souhaitez appliquer la contrainte whole-core au domaine de contrôle.
Par exemple, si le coeur le plus bas dans le système est l'ID coeur 0, le domaine de contrôle doit ressembler à la sortie suivante :
# ldm ls -o cpu primary NAME primary VCPU VID PID CID UTIL STRAND 0 0 0 0.4% 100% 1 1 0 0.2% 100% 2 2 0 0.1% 100% 3 3 0 0.2% 100% 4 4 0 0.3% 100% 5 5 0 0.2% 100% 6 6 0 0.1% 100% 7 7 0 0.1% 100%
ID de bogue 15777490 : le service SMF (Service Management Facility) du démon ldmd n'est pas disponible en ligne lorsque le logiciel Oracle VM Server for SPARC 2.2 est installé sur un domaine de contrôle exécutant les versions du SE Oracle Solaris postérieures au SE Oracle Solaris 10 10/09. Cette situation survient car une dépendance SMF explicite a été ajoutée sur le service SMF svc:/ldoms/agents.
Solution : installez le patch 142909-17 qui prend désormais en charge le service SMF svc:/ldoms/agents, ldmad, dont dépend ldmd.
ID de bogue 15776752 : si vous annulez une migration en direct, le contenu de la mémoire de l'instance de domaine créé sur la cible doit être “nettoyé” par l'hyperviseur. Ce processus de nettoyage est effectué pour des raisons de sécurité et doit être terminé afin que la mémoire puisse être renvoyée vers le pool de mémoire libre. Durant la progression du nettoyage, les commandes ldm deviennent non réactives. Par conséquent, Logical Domains Manager semble suspendu.
Reprise : attendez la fin de la demande de nettoyage avant de tenter d'exécuter les autres commandes ldm. Ce processus peut être long. Par exemple, un domaine invité comptant 500 Go de mémoire peut mettre jusqu'à 7 minutes pour terminer le processus sur un serveur SPARC T4 ou jusqu'à 25 minutes sur un serveur SPARC T3.
ID de bogue 15776319 : sur un système qui exécute le SE Oracle Solaris sur le domaine de contrôle et le domaine d'E/S, certaines cartes Emulex affectées au domaine d'E/S ne fonctionnent pas correctement car celles-ci ne reçoivent pas les interruptions. Toutefois, lorsqu'elles sont affectées au domaine de contrôle, ces mêmes cartes fonctionnent correctement.
Ce problème survient avec les cartes Emulex suivantes :
Emulex 2-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM2)
Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE2FC-EB4-N)
Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM4)
Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-Z)
Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-N)
Solution : aucune.
ID de bogue 15776123 : si la commande cputrack est exécutée sur un domaine invité pendant la migration de ce domaine vers un système SPARC T4, le domaine invité peut paniquer sur la machine cible après avoir été migré.
Solution : n'exécutez pas la commande cputrack durant la migration d'un domaine invité vers un système SPARC T4.
ID de bogue 15775668 : un domaine doté d'une stratégie de priorité supérieure peut voler des ressources de CPU virtuelles à partir d'une stratégie de priorité inférieure. Pendant que cette action de “vol” est en cours, les messages d'avertissement suivants peuvent s'afficher dans le journal ldmd toutes les 10 secondes :
warning: Unable to unconfigure CPUs out of guest domain-name
Solution : vous pouvez ignorer ces messages qui vous induisent en erreur.
ID de bogue 15775637 : un domaine d'E/S possède un nombre limité de ressources d'interruptions disponibles par complexe root.
Sur les systèmes SPARC T3 et SPARC T4, la limite est fixée à environ 63 vecteurs MSI/X. Chaque fonction virtuelle igb utilise trois interruptions. La fonction virtuelle ixgbe utilise deux interruptions.
Si vous affectez un grand nombre de fonctions virtuelles à un domaine, le domaine manque de ressources système pour prendre en charge ces périphériques. Des messages similaires au message suivant peuvent s'afficher :
WARNING: ixgbevf32: interrupt pool too full. WARNING: ddi_intr_alloc: cannot fit into interrupt pool
ID de bogue 15775055 : après la migration d'un domaine entre deux machines possédant des fréquences de CPU différentes; le temps de disponibilité signalé par la commande ldm list peut être incorrect. Ces résultats incorrects surviennent car le temps de disponibilité est calculé par rapport à la fréquence STICK de la machine sur laquelle le domaine est exécuté. Si la fréquence STICK diffère entre les machines source et cible, le temps de disponibilité apparaît incorrect à l'échelle.
Le temps de disponibilité signalé et affiché par le domaine invité lui-même est correct. En outre, toute la comptabilisation effectuée par le SE Oracle Solaris dans le domaine invité est correcte.
ID de bogue 15773603 : lorsque l'initialisation se fait à partir d'une carte Intel dual port Ethernet Controller X540, le pilote ixgbe d'Oracle Solaris 10 peut entraîner une panique du système. Cette panique survient car le lecteur possède une horloge à haute priorité qui empêche les autres disques de se connecter.
Solution : réinitialisez le système.
ID de bogue 15772090 : la version 8.2.0 du microprogramme du système contient une nouvelle version de la base de données scvar qui rétablit les paramètres par défaut au terme de l'installation.
Solution : notez la configuration Oracle VM Server for SPARC en cours d'exécution ou toute modification apportée aux propriétés de diagnostic du système avant l'installation du microprogramme du système. Utilisez la commande showd'ILOM. Par exemple :
-> show /HOST/domain/configs
Après l'installation du microprogramme et avant la mise sous tension du système, utilisez la commande set d'ILOM. Par exemple :
-> set /HOST/bootmode config=config-name
A ce stade, les configurations Oracle VM Server for SPARC sont conservées. Vous devez néanmoins choisir entre l'initialisation d'une configuration particulière ou la configuration factory-default.
Les valeurs de la propriété reviennent aux valeurs par défaut au terme de l'installation du microprogramme :
/HOST Properties: autorunonerror ioreconfigure /HOST/bootmode Properties: config /HOST/diag Properties: error_reset_level error_reset_verbosity hw_change_level hw_change_verbosity level mode power_on_level power_on_verbosity trigger verbosity /HOST/domain/control Properties: auto-boot boot_guests /HOST/tpm Properties: enable activate forceclear /SYS Properties: keyswitch_state /SP/powermgmt Properties: policy
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 : définissez l'option iov sur off pour le bus PCIe spécifique.
primary# ldm start-reconf primary primary# ldm set-io iov=off pci_0
ID de bogue 15761509 : utilisez uniquement les cartes PCIe prenant en charge la fonction d'E/S directes (DIO) qui sont répertoriées dans ce support document.
Solution : utilisez la commande ldm add-io pour rajouter la carte au domaine primary.
ID de bogue 15759601 : si vous émettez une commande ldm stop immédiatement après une commande ldm start, la commande ldm stop risque d'échouer avec l'erreur suivante :
LDom domain stop notification failed
Solution : relancez la commande ldm stop.
ID de bogue 15758883 : la commande ldm init-system ne parvient pas à restaurer les contraintes de coeur des CPU nommés pour les domaines invités à partir d'un fichier XML enregistré.
Solution : effectuez les opérations suivantes :
Créez un fichier XML pour le domaine primary.
# ldm ls-constraints -x primary > primary.xml
Créez un fichier XML pour le ou les domaines invités.
# ldm ls-constraints -x ldom[,ldom][,...] > guest.xml
Effectuez un cycle d'alimentation du système et initialisez une configuration usine par défaut.
Appliquez la configuration XML au domaine primary.
# ldm init-system -r -i primary.xml
Réinitialisez le système.
Appliquez la configuration XML aux domaines invités.
# ldm init-system -f -i guest.xml
ID de bogue 15753523 : l'utilisation répétée de la commande ldm set-io pour modifier la valeur de la propriété pvid d'une fonction virtuelle risque d'entraîner une définition inappropriée de la valeur pvid sur le matériel de la fonction virtuelle.
Solution : patientez quelques secondes avant d'exécuter à nouveau la commande ldm set-io.
ID de bogue 15750727 : un système panique lorsque vous réinitialisez un domaine primary auquel un très grand nombre de fonctions virtuelles est assigné.
Solution : effectuez l'une des opérations solutions :
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éé pour toutes les fonctions virtuelles ixgbe sur le système.
ID de bogue 15748555 : lorsque vous tentez de créer une fonction virtuelle supplémentaire par rapport au nombre maximum de fonctions virtuelles configurables pour un périphérique de fonction physique, le message Create vf failed est émis. Ce message d'erreur n'exprime pas clairement le motif de l'échec.
ID de bogue 15748357 : votre système peut paniquer si vous utilisez des E/S directes (ldm remove-io) pour retirer plusieurs emplacements PCIe d'un système SPARC T-Series ou d'un système Fujitsu M10 multisocket. Ce problème se produit quand les chemins vers les emplacements PCIe sont similaires (sauf pour le chemin complexe de root). La panique peut se produire après le retrait des emplacements PCIe et la réinitialisation du domaine primary. Pour plus d'informations sur la fonction d'E/S directe (DIO), reportez-vous à la section Assignation des périphériques d’extrémité PCIe du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Par exemple, si vous supprimez les emplacements /SYS/MB/PCIE5 (pci@500/pci@2/pci@0/pci@0) et /SYS/MB/PCIE4 (pci@400/pci@2/pci@0/pci@0) dont les noms de chemin sont similaires, le SE Oracle Solaris 11 risque de paniquer lors de la prochaine initialisation.
La commande ldm list-io est exécutée après la suppression des emplacements PCIe /SYS/MB/PCIE4 et /SYS/MB/PCIE5.
# ldm list-io IO PSEUDONYM DOMAIN -- --------- ------ pci@400 pci_0 primary niu@480 niu_0 primary pci@500 pci_1 primary niu@580 niu_1 primary PCIE PSEUDONYM STATUS DOMAIN ---- --------- ------ ------ pci@400/pci@2/pci@0/pci@8 /SYS/MB/PCIE0 OCC primary pci@400/pci@2/pci@0/pci@4 /SYS/MB/PCIE2 OCC primary pci@400/pci@2/pci@0/pci@0 /SYS/MB/PCIE4 OCC pci@400/pci@1/pci@0/pci@8 /SYS/MB/PCIE6 OCC primary pci@400/pci@1/pci@0/pci@c /SYS/MB/PCIE8 OCC primary pci@400/pci@2/pci@0/pci@e /SYS/MB/SASHBA OCC primary pci@400/pci@1/pci@0/pci@4 /SYS/MB/NET0 OCC primary pci@500/pci@2/pci@0/pci@a /SYS/MB/PCIE1 OCC primary pci@500/pci@2/pci@0/pci@6 /SYS/MB/PCIE3 OCC primary pci@500/pci@2/pci@0/pci@0 /SYS/MB/PCIE5 OCC pci@500/pci@1/pci@0/pci@6 /SYS/MB/PCIE7 OCC primary pci@500/pci@1/pci@0/pci@0 /SYS/MB/PCIE9 OCC primary pci@500/pci@1/pci@0/pci@5 /SYS/MB/NET2 OCC primary #
Solution : ne supprimez pas tous les emplacements qui ont des noms de chemin similaires. Supprimez plutôt un seul emplacement PCIe.
Vous pouvez également insérer les cartes PCIe dans des emplacements qui n'ont pas de chemins similaires, puis les utiliser avec la fonctionnalité d'E/S directes.
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 : effectuez les opérations suivantes :
Déterminez le coeur lié le plus bas partagé par les domaines.
# ldm list -o cpu
Dissociez tous les threads de CPU du coeur le plus bas de tous les domaines autres que le domaine primary.
Par conséquent, les threads de CPU du coeur le plus bas ne sont pas partagés et sont disponibles pour être liés au domaine primary.
Définissez la contrainte whole-core en effectuant l'une des opérations suivantes :
Liez les threads de CPU au domaine primary et définissez la contrainte whole-core à l'aide de la commande ldm set-vcpu -c.
Utilisez la commande ldm set-core pour lier les threads de CPU et définissez la contrainte whole-core en une seule étape.
ID de bogue 15747047 : les périphériques de la fonction virtuelle igb et ixgbe deviennent défectueux après la réinitialisation du domaine primary. Ces fonctions virtuelles sont attribuées au domaine primary. La configuration système possède uniquement un domaine primary. Aucun domaine invité ou domaine d'E/S n'est configuré.
La commande fmadm faulty montre que chaque fonction virtuelle est défectueuse. La commande fmadm repair vous permet de récupérer à partir des erreurs mais l'état défectueux est renvoyé à chaque fois que vous réinitialisez le domaine primary.
Solution : utilisez la commande fmadm repair pour la récupération après incident à chaque fois que vous réinitialisez le domaine primary.
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 : l'état des emplacements PCIe et les fonctions virtuelles sont automatiquement mis à jour après réception des informations par l'agent Logical Domains.
ID de bogue 15731303 : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire. Utilisez la commande ldm list -o mem pour afficher la configuration de mémoire de votre domaine. Certaines configurations de mémoire comportant plusieurs blocs équivalant à un total supérieur à 500 risquent de paniquer avec une pile ressemblant à ce qui suit :
panic[cpu21]/thread=2a100a5dca0: BAD TRAP: type=30 rp=2a100a5c930 addr=6f696e740a232000 mmu_fsr=10009 sched:data access exception: MMU sfsr=10009: Data or instruction address out of range context 0x1 pid=0, pc=0x1076e2c, sp=0x2a100a5c1d1, tstate=0x4480001607, context=0x0 g1-g7: 80000001, 0, 80a5dca0, 0, 0, 0, 2a100a5dca0 000002a100a5c650 unix:die+9c (30, 2a100a5c930, 6f696e740a232000, 10009, 2a100a5c710, 10000) 000002a100a5c730 unix:trap+75c (2a100a5c930, 0, 0, 10009, 30027b44000, 2a100a5dca0) 000002a100a5c880 unix:ktl0+64 (7022d6dba40, 0, 1, 2, 2, 18a8800) 000002a100a5c9d0 unix:page_trylock+38 (6f696e740a232020, 1, 6f69639927eda164, 7022d6dba40, 13, 1913800) 000002a100a5ca80 unix:page_trylock_cons+c (6f696e740a232020, 1, 1, 5, 7000e697c00, 6f696e740a232020) 000002a100a5cb30 unix:page_get_mnode_freelist+19c (701ee696d00, 12, 1, 0, 19, 3) 000002a100a5cc80 unix:page_get_cachelist+318 (12, 1849fe0, ffffffffffffffff, 3, 0, 1) 000002a100a5cd70 unix:page_create_va+284 (192aec0, 300ddbc6000, 0, 0, 2a100a5cf00, 300ddbc6000) 000002a100a5ce50 unix:segkmem_page_create+84 (18a8400, 2000, 1, 198e0d0, 1000, 11) 000002a100a5cf60 unix:segkmem_xalloc+b0 (30000002d98, 0, 2000, 300ddbc6000, 0, 107e290) 000002a100a5d020 unix:segkmem_alloc_vn+c0 (30000002d98, 2000, 107e000, 198e0d0, 30000000000, 18a8800) 000002a100a5d0e0 genunix:vmem_xalloc+5c8 (30000004000, 2000, 0, 0, 80000, 0) 000002a100a5d260 genunix:vmem_alloc+1d4 (30000004000, 2000, 1, 2000, 30000004020, 1) 000002a100a5d320 genunix:kmem_slab_create+44 (30000056008, 1, 300ddbc4000, 18a6840, 30000056200, 30000004000) 000002a100a5d3f0 genunix:kmem_slab_alloc+30 (30000056008, 1, ffffffffffffffff, 0, 300000560e0, 30000056148) 000002a100a5d4a0 genunix:kmem_cache_alloc+2dc (30000056008, 1, 0, b9, fffffffffffffffe, 2006) 000002a100a5d550 genunix:kmem_cpucache_magazine_alloc+64 (3000245a740, 3000245a008, 7, 6028f283750, 3000245a1d8, 193a880) 000002a100a5d600 genunix:kmem_cache_free+180 (3000245a008, 6028f2901c0, 7, 7, 7, 3000245a740) 000002a100a5d6b0 ldc:vio_destroy_mblks+c0 (6028efe8988, 800, 0, 200, 19de0c0, 0) 000002a100a5d760 ldc:vio_destroy_multipools+30 (6028f1542b0, 2a100a5d8c8, 40, 0, 10, 30000282240) 000002a100a5d810 vnet:vgen_unmap_rx_dring+18 (6028f154040, 0, 6028f1a3cc0, a00, 200, 6028f1abc00) 000002a100a5d8d0 vnet:vgen_process_reset+254 (1, 6028f154048, 6028f154068, 6028f154060, 6028f154050, 6028f154058) 000002a100a5d9b0 genunix:taskq_thread+3b8 (6028ed73908, 6028ed738a0, 18a6840, 6028ed738d2, e4f746ec17d8, 6028ed738d4)
Solution : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire.
ID de bogue ID 15726205 : le message d'erreur suivant peut s'afficher lorsque vous tentez de supprimer un grand nombre de CPU d'un domaine invité.
Request to remove cpu(s) sent, but no valid response received VCPU(s) will remain allocated to the domain, but might not be available to the guest OS Resource modification failed
Solution : arrêtez le domaine invité avant de supprimer plus de 100 CPU.
ID de bogue 15721872 : vous ne pouvez pas utiliser les opérations d'enfichage à chaud 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.0.
ID de bogue 15713809 : si un disque physique est configuré avec une tranche 2 dont la taille est 0, vous risquez de rencontrer les problèmes suivants :
Si vous utilisez la commande ldm add-vdsdev pour ajouter un disque physique en tant que moteur de traitement pour un disque virtuel, la commande échoue :
# ldm add-vdsdev /dev/dsk/c3t1d0s2 vol@primary-vds0 Path /dev/dsk/c3t1d0s2 is not valid on service domain primary
Installez l'ID de patch 147708-01 sur le domaine primary et les domaines de service, puis redémarrez le service svc:/ldoms/agents.
Si vous utilisez la commande ldm bind pour lier un domaine comportant un tel disque en tant que moteur de traitement d'un disque virtuel, la commande échoue :
# ldm bind ldg3 Path /dev/dsk/c3t1d0s2 is not valid on service domain primary
Vous pouvez contourner ce problème en utilisant l'option -q de la commande ldm bind :
# ldm bind -q ldg3
Une autre solution consiste à désactiver définitivement la validation du disque effectuée par les commandes ldm add-vdsdev et ldm bind. Ainsi, vous n'avez pas besoin de spécifier l'option -q. Désactivez définitivement la validation du disque en mettant à jour la propriété device_validation du service ldmd :
# svccfg -s ldmd setprop ldmd/device_validation=value # svcadm refresh ldmd # svcadm restart ldmd
Spécifiez la valeur 0 pour désactiver la validation des périphériques de disque et réseau. Spécifiez la valeur 1 pour désactiver la validation des périphériques de disque tout en maintenant la validation des périphériques réseau.
Les valeurs possibles pour la propriété device_validation sont :
Désactive la validation de tous les périphériques
Active la validation des périphériques réseau
Active la validation des périphériques de disque
Active la validation des périphériques de disque et réseau
Active la validation pour tous les types de périphériques (valeur définie par défaut)
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 : ajoutez la ligne suivante au fichier /etc/system sur le domaine primary et sur tout domaine de service faisant partie de la configuration d'E/S hybrides pour le domaine :
set vsw:vsw_hio_max_cleanup_retries = 0x200
ID de bogue 15708982 : une migration initialisée ou en cours, ou toute commande ldm se bloque. Cette situation se produit lorsque le domaine à migrer utilise un système de fichiers partagé issu d'un autre système et que ce système de fichiers n'est plus partagé.
Solution : restaurez l'accessibilité du système de fichiers partagé.
ID de bogue 15707426 : si le service de journal système svc:/system/system-log, ne démarre pas et n'est pas en ligne, le service d'agent de Logical Domains n'est pas disponible en ligne non plus. Lorsque le service d'agent de Logical Domains n'est pas en ligne, les commandes virtinfo, ldm add-vsw, ldm add-vdsdev et ldm list-io risquent de ne pas se comporter normalement.
Solution : assurez-vous que le service svc:/ldoms/agents:default est activé et en ligne :
# svcs -l svc:/ldoms/agents:default
Si le service svc:/ldoms/agents:default est hors ligne, vérifiez qu'il est actif et que tous les services dépendants sont en ligne.
ID de bogue 15704500 : la migration d'un domaine invité actif peut se bloquer et la machine source peut ne plus répondre. Quand ce problème se produit, le message suivant est écrit dans la console et le fichier /var/adm/messages :
vcc: i_vcc_ldc_fini: cannot close channel 15 vcc: [ID 815110 kern.notice] i_vcc_ldc_fini: cannot close channel 15
Notez que le numéro de canal désigne le numéro de canal interne de Oracle Solaris, lequel peut être différent pour chaque message d'avertissement.
Solution : avant de faire migrer le domaine, déconnectez-vous de la console du domaine invité.
Reprise : arrêtez et redémarrez la machine source.
ID de bogue 15702475 : le message No response peut s'afficher dans le journal de Oracle VM Server for SPARC lorsque la stratégie DRM d'un domaine chargé expire après une réduction significative du nombre de CPU. La sortie ldm list montre qu'il y a plus de ressources CPU affectées au domaine que celles affichées dans la sortie psrinfo.
Solution : utilisez la commande ldm set-vcpu pour redéfinir le nombre de CPU du domaine sur la valeur présentée dans la sortie psrinfo.
ID de bogue 15701865 : si vous tentez une migration en direct d'un domaine dépendant d'un domaine inactif sur la machine cible, le démon ldmd échoue avec une erreur de segmentation et le domaine de la machine cible est redémarré. Vous pouvez néanmoins effectuer une migration, mais pas une migration en direct.
Solution : effectuez l'une des actions suivantes avant de tenter la migration en direct :
Supprimez la dépendance invitée du domaine à migrer.
Démarrez le domaine maître sur la machine cible.
ID de bogue 15701853 : si vous effectuez une migration de domaine alors qu'une stratégie DRM est en vigueur et que, par la suite, la stratégie DRM expire ou est supprimée du domaine migré, DRM ne parvient pas à restaurer le nombre d'origine de CPU virtuelles sur le domaine.
Solution : si un domaine est migré alors qu'une stratégie DRM est active, puis que cette dernière expire ou est supprimée, redéfinissez le nombre de CPU virtuelles. Utilisez la commande ldm set-vcpu pour définir le nombre de CPU virtuelles sur la valeur d'origine sur le domaine.
ID de bogue 15701258 : l'exécution de la commande ldm set-vcpu 1 sur un domaine invité contenant plus de 100 CPU virtuelles et quelques unités de chiffrement ne parvient pas à supprimer les CPU virtuelles. Les CPU virtuelles ne sont pas supprimées en raison d'un échec du délai d'attente de la reconfiguration dynamique. Les unités de chiffrement, par contre, sont bien supprimées
Solution : utilisez la commande ldm rm-vcpu pour supprimer l'ensemble du contenu du domaine invité à l'exception des CPU virtuelles. Ne supprimez pas plus de 100 CPU virtuelles à la fois.
ID de bogue 15699763 : un domaine ne peut pas être migré s'il contient une adresse MAC en double. En général, lorsqu'une migration échoue pour ce motif, le message d'échec affiche l'adresse MAC en double. Cependant, dans de rares circonstances, ce message d'échec ne signale pas l'adresse MAC en double.
# ldm migrate ldg2 system2 Target Password: Domain Migration of LDom ldg2 failed
Solution : assurez-vous que les adresses MAC sur la machine cible sont uniques.
ID de bogue 15696986 : si deux commandes ldm migrate sont émises simultanément dans des “directions opposées,” elles risquent de se bloquer et de ne jamais aboutir. Une situation avec des directions opposées se présente lorsque vous démarrez simultanément une migration de la machine A vers la machine B ou une migration de la machine B vers la machine A.
Le blocage se produit même si les processus de migration sont initialisés en tant que simulations à l'aide de l'option -n. Lorsque ce problème se produit, toutes les autres commandes ldm risquent de se bloquer.
Solution : aucune.
ID de bogue 15677358 : utilisez une reconfiguration retardée plutôt qu'une reconfiguration dynamique pour supprimer plus de 100 CPU du domaine de contrôle (également appelé domaine primary). Utilisez les étapes suivantes :
Utilisez la commande ldm start-reconf primary pour mettre le domaine de contrôle en mode de reconfiguration retardée.
Supprimez le nombre de ressources de CPU de votre choix.
Si vous vous trompez lors de la suppression des ressources de CPU, ne tentez pas d'exécuter une nouvelle demande de suppression de CPU tant que le domaine de contrôle est à l'état de reconfiguration retardée. Le cas échéant, les commandes échoueront (reportez-vous à la section Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée). Au lieu de cela, annulez l'opération de reconfiguration retardée à l'aide de la commande ldm cancel-reconf, et recommencez.
Réinitialisez le domaine de contrôle.
ID de bogue 15672651 et 15731467 : vous pouvez observer des blocages du SE à la connexion ou au cours de l'exécution de commandes lorsque les conditions suivantes sont réunies :
Le SE Oracle Solaris 10 8/11 est exécuté sur un système SPARC sun4v
La fonction de gestion de l'alimentation élastique est définie sur le processeur de service ILOM du système.
Solution : appliquez le patch ID 147149-01.
ID de bogue 15668881 : lorsque vous utilisez la commande pkgadd pour installer le package SUNWldm.v depuis un répertoire exporté via NFS à partir d'un produit Sun ZFS Storage Appliance, le message d'erreur suivant peut s'afficher :
cp: failed to set acl entries on /var/svc/manifest/platform/sun4v/ldmd.xml
Solution : ignorez ce message.
ID de bogue 15668368 : un système SPARC T3-1 peut être installé avec des disques double port, lesquels peuvent être accessibles via deux périphériques d'E/S directes différents. Dans ce cas, l'assignation de ces périphériques d'E/S directes à des domaines différents entraîne parfois l'utilisation des disques par les deux domaines et une incidence mutuelle sur l'utilisation réelle de ces disques.
Solution : 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 T3-1 contient des disques à deux ports, exécutez la commande suivante sur le SP :
-> show /SYS/SASBP
Si la sortie contient la valeur fru_description, le système correspondant contient des disques double port :
fru_description = BD,SAS2,16DSK,LOUISE
Lorsque des disques double port sont présents dans le système, assurez-vous que les deux périphériques d'E/S directes suivants sont toujours assignés au même domaine :
pci@400/pci@1/pci@0/pci@4 /SYS/MB/SASHBA0 pci@400/pci@2/pci@0/pci@4 /SYS/MB/SASHBA1
ID de bogue 15667770 : lorsque plusieurs instances nxge NIU sont associées sur un domaine, les commandes ldm rm-mem et ldm set-mem utilisées pour supprimer la mémoire du domaine ne s'exécutent pas entièrement. Pour déterminer si le problème est survenu durant une opération de suppression de mémoire, surveillez l'avancement de l'opération au moyen de la commande ldm list -o status. Vous rencontrerez peut-être ce problème si le pourcentage d'avancement reste constant pendant plusieurs minutes.
Reprise : annulez la commande ldm rm-mem or ldm set-mem.
Solution : 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 différée sur le domaine primary.
# ldm start-reconf primary
Assignez la quantité de mémoire souhaitée au domaine.
Réinitialisez le domaine primary.
Si le problème survient sur un autre domaine, arrêtez-le avant de modifier la quantité de mémoire assignée au domaine.
ID de bogue 15664666 : lorsqu'une relation de dépendance de réinitialisation est créée, la commande ldm stop -a peut entraîner le redémarrage au lieu de l'arrêt seul d'un domaine participant à une relation de dépendance de réinitialisation.
Solution : exécutez d'abord la commande ldm stop pour le domaine maître. Exécutez ensuite la commande ldm stop pour le domaine esclave. Si l'arrêt initial du domaine esclave échoue, exécutez la commande ldm stop -f pour le domaine esclave.
ID de bogue 15655513 : suite à la migration d'un domaine actif, l'utilisation des CPU dans le domaine migré peut considérablement augmenter pendant un intervalle de temps très court. Si une stratégie de gestion des ressources dynamique (DRM) est en vigueur pour le domaine au moment de la migration, Logical Domains Manager risque d'ajouter des CPU. En particulier, si les propriétés vcpu-max et attack n'ont pas été définies pendant l'ajout de la stratégie, la valeur par défaut unlimited a pour effet l'ajout au domaine migré de toutes les CPU non liées sur la machine cible.
Reprise : aucune reprise n'est nécessaire. Une fois que l'utilisation des CPU redescend en dessous de la limite supérieure définie par la stratégie DRM, Logical Domains Manager supprime automatiquement les CPU.
ID de bogue 15655199 : il arrive qu'une adresse MAC active ne soit pas détectée et soit réaffectée à tort.
Solution : vérifiez manuellement que les adresses MAC actives ne puissent pas être réaffectées.
ID de bogue 15654965 : le script ldmconfig ne peut pas créer correctement une configuration de domaines logique stockée sur le processeur de service.
Solution : n'effectuez pas de cycle d'alimentation du système une fois le script ldmconfig terminé et le domaine réinitialisé. Réalisez plutôt la procédure manuelle suivante :
Ajoutez la configuration au processeur de service.
# ldm add-spconfig new-config-name
Supprimez la configuration primary-with-clients du processeur de service.
# ldm rm-spconfig primary-with-clients
Arrêtez et redémarrez le système.
Si vous n'effectuez pas cette procédure avant le cycle d'alimentation du système, la présence de la configuration primary-with-client désactive les domaines. Dans ce cas, vous devez relier les domaines un à un, puis les démarrer à l'aide de la commande ldm start -a. Une fois les invités initialisés, répétez cette séquence pour initialiser les domaines invités automatiquement après le cycle d'alimentation.
ID de bogue 15653424 : la migration d'un domaine actif peut échouer s'il exécute une version antérieure au SE Oracle Solaris 10 10/09 et que la CPU portant le plus petit numéro est à l'état hors ligne. L'opération échoue lorsque Logical Domains Manager recourt à la reconfiguration dynamique des CPU jusqu'à ce qu'il ne reste qu'une seule CPU dans le domaine. Ce faisant, Logical Domains Manager tente de supprimer du domaine toutes les CPU sauf celle portant le plus petit numéro, mais puisque celle-ci est hors ligne, l'opération échoue.
Solution : avant d'effectuer la migration, assurez-vous que la CPU portant le plus petit numéro est à l'état en ligne.
ID de bogue 15646293 : suite à la suspension d'un domaine Oracle Solaris 10 9/10 dans le cadre d'une opération de migration, la reconfiguration dynamique de la mémoire est désactivée. Cette action ne survient que si la migration réussit ou si elle a été annulée, en dépit du fait que le domaine demeure sur la machine source.
ID de bogue 15631119 : si vous modifiez l'unité de transmission maximale (MTU) d'un périphérique réseau virtuel sur le domaine de contrôle, une opération de reconfiguration différée est déclenchée. Si vous annulez ensuite la reconfiguration différé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 différée que vous devez désactiver. La valeur MTU résultante est à présent la valeur MTU correcte initiale.
# ldm set-vnet mtu=orig-value vnet1 primary # ldm cancel-op reconf primary
ID de bogue 15606220 : à partir de la version Logical Domains 1.3, un domaine peut être migré même s'il est lié à plusieurs unités cryptographiques.
Dans les circonstances suivantes, la machine cible ne contient qu'une seule CPU une fois la migration effectuée :
La machine cible exécute Logical Domains 1.2
Le domaine de contrôle sur la machine cible exécute une version du SE Oracle Solaris non compatible avec la reconfiguration dynamique d'unités cryptographiques
Vous migrez un domaine contenant des unités cryptographiques
Une fois la migration terminée, le domaine cible redevient normalement opérationnel, mais se trouve à l'état d'exclusion sélective (une seule CPU).
Solution : préalablement à la migration, supprimez les unités cryptographiques de la machine source exécutant Logical Domains 1.3.
Réduction des risques : pour éviter de rencontrer ce problème, effectuez l'une des étapes suivantes, voire les deux :
Installez le logiciel Oracle VM Server for SPARC sur la machine cible.
Installez le patch ID 142245-01 sur le domaine de contrôle de la machine cible ou effectuez une mise à niveau vers, au minimum, le SE Oracle Solaris 10 10/09.
ID de bogue 15605806 : dans certaines situations, la migration échoue avec le message d'erreur, et la commande ldmd signale que la liaison de la mémoire nécessaire pour le domaine source est impossible. Cette situation peut se produire même si la quantité totale de mémoire disponible sur la machine cible est supérieure à celle utilisée par le domaine source (comme indiqué par ldm ls-devices -a mem).
Unable to bind 29952M memory region at real address 0x8000000 Domain Migration of LDom ldg0 failed
Cause : cet échec est causé par l'incapacité de satisfaire les exigences de congruence entre l'adresse réelle et l'adresse physique sur la machine cible.
Solution : arrêtez le domaine et effectuez une migration à froid. Vous pouvez également réduire la taille de la mémoire sur le domaine invité de 128 Mo, ce qui permet à la migration de s'effectuer pendant que le domaine est actif.
ID de bogue 15600969 : si toutes les unités cryptographiques matérielles sont supprimées de manière dynamique dans un domaine actif, la structure cryptographique ne peut pas recourir aux fournisseurs cryptographiques de logiciels sans erreur, et arrête l'ensemble des connexions ssh.
Reprise : rétablissez les connexions ssh après avoir supprimé les unités cryptographiques du domaine.
Solution : 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.
Après cette opération, aucune des connexions ssh ne recourt plus aux unités cryptographiques matérielles (et ne tire donc plus parti des améliorations des performances qui y sont associées) et les connexions ssh ne sont plus arrêtées lorsque des unités cryptographiques sont supprimées.
ID de bogue 15597025 : lorsque vous exécutez la commande ldm ls-io -l sur un système équipé d'une carte fibre 10 Gigabit Ethernet double, PCI Express (X1027A-Z), la sortie peut afficher les informations suivantes :
primary# ldm ls-io -l ... pci@500/pci@0/pci@c PCIE5 OCC primary network@0 network@0,1 ethernet ethernet
La sortie affiche quatre sous-périphériques même si la carte Ethernet ne possède que deux ports. Cette anomalie se présente si la carte comporte quatre fonctions PCI. Deux de ces fonctions sont désactivées en interne et s'affichent comme étant des ports ethernet dans la sortie ldm ls-io -l.
Solution : vous pouvez ignorer les entrées ethernet dans la sortie ldm ls-io -l.
ID de bogue 15572184 : une commande ldm risque de mettre beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés. Si vous exécutez une commande ldm à ce stade, elle peut sembler se bloquer. Sachez que la commande ldm revient normalement, une fois que la tâche attendue est effectuée. Lorsque la commande revient, le système doit répondre normalement aux commandes ldm.
Solution : é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 Netra T5440.
ID de bogue 15560811 : dans Oracle Solaris 11, les zones configurées à l'aide d'une interface réseau automatique (anet) risquent de ne pas démarrer dans un domaine possédant uniquement des périphériques de réseau virtuel Logical Domains.
Solution 1 : affectez un ou plusieurs périphériques réseau physique au domaine invité. Utilisez la fonctionnalité d'affectation de bus PCIe, d'E/S directes (DIO) ou la fonctionnalité SR-IOV pour affecter un NIC physique au domaine.
Solution 2 : si la configuration requise pour la configuration des zones consiste en une configuration entre les zones du domaine, créez un périphérique etherstub. Utilisez le périphérique etherstub en tant que “liaison inférieure” dans la configuration des zones afin que les cartes NIC virtuelles soient créées sur le périphérique etherstub.
Solution 3 : utilisez une affectation de lien exclusive pour attribuer un périphérique de réseau virtuel Logical Domains à une zone. Affectez des périphériques de réseau virtuel au domaine en fonction de vos besoins. Vous pouvez également choisir de désactiver les liens inter-vnet afin de créer un grand nombre de périphériques de réseau virtuel.
ID de bogue 15560201 : il arrive que la commande ifconfig indique que le périphérique n'existe pas après l'ajout d'un périphérique de réseau virtuel ou de disque virtuel à un domaine. Ce problème survient car l'entrée /devices n'a pas été créée.
Bien que ce problème ne devrait pas se produire en fonctionnement normal, l'erreur peut se présenter lorsque le numéro d'instance d'un périphérique réseau virtuel ne correspond pas à celui répertorié dans le fichier /etc/path_to_inst.
Par exemple :
# ifconfig vnet0 plumb ifconfig: plumb: vnet0: no such interface
Le numéro d'instance d'un périphérique virtuel est indiqué dans la colonne DEVICE de la sortie ldm list :
# ldm list -o network primary NAME primary MAC 00:14:4f:86:6a:64 VSW NAME MAC NET-DEV DEVICE DEFAULT-VLAN-ID PVID VID MTU MODE primary-vsw0 00:14:4f:f9:86:f3 nxge0 switch@0 1 1 1500 NETWORK NAME SERVICE DEVICE MAC MODE PVID VID MTU vnet1 primary-vsw0@primary network@0 00:14:4f:f8:76:6d 1 1500
Le numéro d'instance (0 pour les deux périphériques vnet et vsw de la sortie affichée précédemment) peut être comparé au numéro d'instance indiqué dans le fichier path_to_inst afin de s'assurer qu'ils sont identiques.
# egrep '(vnet|vsw)' /etc/path_to_inst "/virtual-devices@100/channel-devices@200/virtual-network-switch@0" 0 "vsw" "/virtual-devices@100/channel-devices@200/network@0" 0 "vnet"
Solution : 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).
 | Attention - Soyez attentif à l'avertissement donné dans la page de manuel qui indique que des changements apportés au fichier /etc/path_to_inst doivent l'être avec toutes les précautions possibles. |
ID de bogue15555509 : si le logiciel Logical Domains est configuré sur un système et que vous ajoutez une autre carte réseau XAUI, celle-ci n'est pas visible après l'arrêt et le redémarrage de la machine.
Reprise : pour que la carte XAUI récemment ajoutée soit visible dans le domaine de contrôle, suivez les étapes ci-dessous :
Définissez et effacez une variable factice dans le domaine de contrôle.
Les commandes suivantes utilisent une variable factice appelée fix-xaui> :
# ldm set-var fix-xaui=yes primary # ldm rm-var fix-xaui primary
Enregistrez la configuration modifiée sur le processeur de service (SP) en écrasant l'actuelle.
Les commandes suivantes utilisent une configuration appelée fix-config1 :
# ldm rm-spconfig config1 # ldm add-spconfig config1
Effectuez une réinitialisation de reconfiguration sur le domaine de contrôle.
# reboot -- -r
A ce stade, vous pouvez configurer les réseaux récemment disponibles pour que le logiciel Logical Domains puisse les utiliser.
ID de bogue 15543982 : vous pouvez configurer deux domaines au maximum avec des complexes root PCI-E dédiés sur des systèmes tels que le Sun Fire T5240. Ces systèmes sont dotés de deux CPU UltraSPARC T2 Plus et de deux complexes root d'E/S.
pci@500 et pci@400 sont les deux complexes root du système. Le domaine primary contient toujours au moins un complexe root. Un second domaine peut être configuré avec un complexe root non assigné ou non lié.
La structure (ou noeud terminal) pci@400 contient la carte réseau intégrée e1000g. Une panique de domaine peut survenir dans les circonstances suivantes :
Si le système est configuré avec un domaine primary contenant pci@500 et un second domaine contenant pci@400
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.
ID de bogue 15527921 : au cours d'une migration, le groupe de consoles et le port explicitement assignés sont ignorés, et une console avec les propriétés par défaut est créée pour le domaine cible. Cette console est créée en utilisant le nom du domaine cible comme groupe de consoles et un port disponible sur le premier concentrateur de console virtuelle (vcc) du domaine de contrôle. S'il y a un conflit avec le nom de groupe par défaut, la migration échoue.
Reprise : pour restaurer les propriétés de la console explicite à la suite d'une migration, dissociez le domaine cible et définissez manuellement les propriétés souhaitées à l'aide de la commande ldm set-vcons.
ID de bogue 15523133 : si le disque virtuel sur la machine cible ne pointe pas vers le même moteur de traitement de disque que celui utilisé sur la machine source, le domaine migré ne peut pas accéder au disque virtuel à l'aide du moteur de traitement de disque. L'accès au disque virtuel sur le domaine risque de se bloquer.
Actuellement, Logical Domains Manager vérifie uniquement que les noms des volumes de disque virtuel correspondent entre machines source et cible. Dans ce cas de figure, aucun message d'erreur n'est affiché si les moteurs de traitement de disque ne correspondent pas.
Solution : assurez-vous, lors de la configuration du domaine cible, de recevoir un domaine migré que le volume de disque (vdsdev) fait correspondre au moteur de traitement de disque utilisé sur le domaine source.
Reprise : effectuez l'une des procédures suivantes si vous déterminez que le périphérique de disque virtuel sur la machine cible pointe vers un moteur de traitement de disque incorrect :
Migrez le domaine et corrigez le vdsdev.
Remigrez le domaine vers la machine source.
Corrigez le volume vdsdev sur la cible de sorte qu'il pointe vers le bon moteur de traitement de disque.
Remigrez le domaine vers la machine cible.
Arrêtez et dissociez le domaine sur la cible, puis corrigez le volume vdsdev. Si le système d'exploitation prend en charge la reconfiguration dynamique des E/S et que le disque virtuel incorrect n'est pas utilisé sur le domaine (c.-à-d. qu'il ne s'agit pas du disque d'initialisation et qu'il est démonté), procédez comme suit :
Exécutez la commande ldm rm-vdisk pour supprimer le disque.
Corrigez le volume vdsdev.
Exécutez la commande ldm add-vdisk pour rajouter le disque virtuel.
ID de bogue 15523120 : dans certaines situations, la migration échoue et la commande ldmd signale que la liaison de la mémoire nécessaire pour le domaine source est impossible. Cela peut se produire même si la quantité totale de mémoire disponible sur la machine cible est supérieure à celle utilisée par le domaine source.
Cet échec se produit car la migration de plages de mémoire spécifiques utilisées par le domaine source nécessite que des plages de mémoire compatibles soient également disponibles sur la cible. Si aucune plage de mémoire compatible n'est trouvée pour une plage de mémoire donnée dans la source, la migration échoue.
Reprise : si vous rencontrez ce problème, essayez de migrer le domaine en modifiant l'utilisation de la mémoire sur la machine cible. Pour ce faire, dissociez n'importe quel domaine logique actif sur la cible.
Exécutez la commande ldm list-devices -a mem pour déterminer la quantité de mémoire disponible et son utilisation. Envisagez également de réduire la quantité de mémoire assignée à un autre domaine.
ID de bogue 15518409 : si vous ne disposez pas d'un réseau configuré sur votre machine et qu'un client NIS (Network Information Services, services d'information réseau) est actif, Logical Domains Manager ne démarre pas sur votre système.
Solution : désactivez le client NIS sur la machine non mise en réseau :
# svcadm disable nis/client
ID de bogue 15516245 : il peut arriver qu'un domaine logique actif semble être à l'état de transition au lieu de normal longtemps après avoir été initialisé ou à la suite de la migration de domaines. Ce problème mineur est anodin, et le domaine est entièrement fonctionnel. Pour déterminer quel indicateur est défini, consultez le champ flags dans la sortie de la commande ldm list -l -p ou le champ FLAGS de la commande ldm list, qui affiche -n---- pour normal ou -t---- pour transition.
Reprise : après la réinitialisation suivante, le domaine affiche l'état correct.
ID de bogue 15513998 : il arrive qu'il soit impossible de se connecter à la console d'un domaine qui vient d'être migré.
Solution : 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.
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 : exécutez la commande suivante à la place :
uadmin 2 0
Ou, exécutez la commande avec la variable auto-reboot? toujours définie sur false.
ID de bogue 15505014 : l'arrêt d'un domaine ou le nettoyage de la mémoire peut prendre plus de 15 minutes avec une seule CPU et une configuration de mémoire très importante. Durant l'arrêt, les CPU d'un domaine sont utilisées pour nettoyer l'ensemble de la mémoire détenue par le domaine. Le temps mis pour effectuer le nettoyage peut être assez long si une configuration donnée est déséquilibrée, par exemple, si un domaine à une seule CPU comporte 512 giga-octets de mémoire. Ce délai de nettoyage prolongé vient augmenter le temps nécessaire pour arrêter un domaine.
Solution : assurez-vous que les configurations de mémoire importante (>100 giga-octets) comportent au moins un coeur.
ID de bogue 15482406 : si vous tentez une initialisation réseau du SE Oracle Solaris 10 8/07 sur un domaine invité servi par un domaine de service exécutant le SE Oracle Solaris 10 5/08, il arrive que l'installation se bloque sur le domaine invité.
Solution : patchez le miniroot de l'image d'installation réseau du SE Oracle Solaris 10 8/07 à l'aide du patch ID 127111-05.
ID de bogue 15469227 : la commande scadm d'un domaine de contrôle exécutant le système d'exploitation Solaris 10 11/06 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.
Solution : réinitialisez l'hôte pour rétablir la connexion avec le contrôleur système.
Reprise : réinitialisez l'hôte pour rétablir la connexion avec le contrôleur système.
ID de bogue 15453968 : une installation réseau simultanée de plusieurs domaines invités échoue sur les systèmes ayant un groupe de consoles commun.
Solution : procédez à une installation réseau uniquement sur des domaines invités ayant chacun leur propre groupe de consoles. Cette panne se rencontre uniquement sur les domaines ayant un groupe de consoles commun partagé entre plusieurs domaines à installation réseau.
ID de bogue 15426914 : le message d'avertissement suivant peut s'afficher sur la console du système ou être consigné dans le journal système :
ldc_close: (0xb) unregister failed, 11
Notez que le chiffre entre parenthèses désigne le numéro de canal interne d'Oracle Solaris, lequel peut être différent pour chaque message d'avertissement.
Solution : vous pouvez ignorer ces messages.
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 : définissez ip_ire_min_bucket_cnt et ip_ire_max_bucket_cnt sur des valeurs plus grandes comme 32, si vous disposez de huit interfaces.
Reprise : Exécutez une commande ldm stop-domain ldom suivie d'une commande ldm start-domain ldom sur le domaine invité (ldom) en question.
ID de bogue 15387338 : ce problème est sommairement décrit dans la section Persistance des variables Logical Domains et concerne uniquement le domaine de contrôle.
ID de bogue 15370442 : l'environnement Logical Domains ne prend pas en charge la définition ou la suppression de clés d'initialisation de connexion WAN à partir du SE Oracle Solaris à l'aide de la commande ickey(1M). Toutes les opérations ickey échouent avec le message d'erreur suivant :
ickey: setkey: ioctl: I/O error
De plus, les clés d'initialisation via connexion WAN qui sont définies en utilisant le microprogramme OpenBoot sur des domaines logiques autres que le domaine de contrôle ne sont pas mémorisées après la réinitialisation du domaine. Sur ces domaines, les clés définies à partir du microprogramme OpenBoot sont valides uniquement pour un seul usage.
ID de bogue 15368170 : dans certains cas, le comportement de la commande ldm stop-domain est déroutant.
# ldm stop-domain -f ldom
Si le domaine est dans le débogueur du module noyau, avec l'invite kmdb(1), la commande ldm stop-domain échoue avec le message d'erreur suivant :
LDom <domain-name> stop notification failed
Cette section contient les erreurs de documentation qui n'ont pas été identifiées à temps pour être modifiées dans cette version d'Oracle VM Server for SPARC 3.0.
De nombreuses sections dans la page de manuel ldm(1M) indiquent que les commandes de virtualisation d'E/S permettent de lancer automatiquement une reconfiguration retardée. Cette information est erronée. Si nécessaire, lancez manuellement une reconfiguration retardée.
La section relative à la création de fonctions virtuelles de la page de manuel ldm(1M) indique que pour créer des fonctions virtuelles de façon dynamique, vous devez impérativement définir la propriété iov pour le complexe root parent.” Cette fonction n'est pas prise en charge dans la version 3.0 d'Oracle VM Server for SPARC.
La description de l'option -r dans la page de manuel ldm(1M) indique actuellement que les sous-commandes add-spconfig, list-spconfig et remove-spconfig utilisent cette option pour effectuer une reprise manuelle. Cette information est erronée. Seule la commande ldm add-spconfig -r peut être utilisée à cette fin.
Pour les systèmes Fujitsu M10, la restriction suivante remplace les informations décrites dans la section Migration d’un domaine à partir de la PROM OpenBoot ou un domaine en cours d’exécution dans le débogueur de noyau du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.
Lorsqu'un domaine à migrer est en cours d'exécution dans OpenBoot ou dans le débogueur de noyau (kmdb), la tentative de migration échoue toujours si la machine source ou cible est un système Fujitsu M10. Dans le cas où le domaine à migrer ne contient qu'une seule CPU, le message d'erreur suivant est susceptible de s'afficher :
# ldm migrate ldg1 system2 Non-cooperative migration is not supported on this platform.
|