| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Notes de version d'Oracle VM Server for SPARC 2.2 Oracle VM Server for SPARC (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Notes de version d'Oracle VM Server for SPARC 2.2 Oracle VM Server for SPARC (Français) |
1. Notes de version d'Oracle VM Server for SPARC .2.2
Plates-formes prises en charge
SE Oracle Solaris requis et recommandé
Logiciels requis pour activer les fonctionnalités d'Oracle VM Server for SPARC .2.2.
Patches 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
Configuration requise pour la migration en direct
Emplacement du logiciel Oracle VM Server for SPARC .2.2
Emplacement de la documentation
Logiciels compatibles avec le 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 .2.2
Mise à niveau à partir d'un SE Oracle Solaris 10 antérieur au SE Oracle Solaris 10 5/08
Le mode évitement MMU E/S n'est plus nécessaire
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 mise sous tension progressive 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
Suppression de l'outil Assistant de configuration graphique
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
Restrictions de la CPU pour la migration
La commande snmptable ne fonctionne pas avec l'option Version 2 ou Version 3
Bogues liés au logiciel Oracle VM Server for SPARC .2.2
Interruption anormale de ldmd sur les opérations après l'annulation de la reconfiguration retardée
Domaine non lié avec CPU désactivées signalant un nombre incorrect de ressources de CPU
Echec de la recréation d'un domaine avec des fonctions virtuelles PCIe à partir d'un fichier XML
Signalement par ldm init-system d'une erreur disk server not found
Domaine de contrôle nécessitant le noyau 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
Impossible pour ldm init-system -r -i XML-file de réinitialiser le domaine primary
La version 8.2.0 du microprogramme système contient une nouvelle version de la base de données scvar
panic: BAD TRAP: occurred in module "pcie" due to an illegal access to a user address
Un backend vdsdev est considéré comme un chemin correct
Renvoi erroné de 0 au lieu de 1 de ldm start en cas d'échec du démarrage d'un domaine invité
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 de noyau complet par le noyau partiel primary
Prise en charge d'ldmconfig uniquement sur les systèmes Oracle Solaris 10
Affichage de l'état UNK ou INV par la commande ldm list-io après l'initialisation
Impossible de retirer le périphérique de la carte NIC (Network Interface Card)
Prise en charge d'Oracle VM Server for SPARC MIB sur systèmes Oracle Solaris 10 uniquement
Suppression d'un grand nombre de CPU d'un domaine invité
Opération d'arrêt d'un domaine à mémoire volumineuse très longue en mode élastique
La validation de disque virtuel échoue pour un disque physique sans tranche 2
Echec de la suppression de noyaux d'un domaine ayant des noyaux partiels par la commande ldmd
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
Suppression d'un grand nombre de CPU d'un domaine de contrôle
SPARC T3-1 : Détection et gestion des disques accessibles via plusieurs voies 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 base de données de contraintes n'est pas synchronisée avec la configuration enregistrée
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é
Le Logical Domains Manager met parfois plus de 15 minutes pour éteindre 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 .2.2.
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 2.2.
Depuis la version Oracle VM Server for SPARC 2.0, le mode évitement de l'unité de gestion de la mémoire des E/S (MMU) n'est plus nécessaire. Par conséquent, la propriété bypass=on n'est plus disponible avec la commande ldm add-io.
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. Notamment, le Productbase; 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 Productbase; Volume Manager ou ses métapériphériques, suivez la procédure ci-dessous.
md_devid_destroy=1; md_keep_repl_state=1;
Une fois le domaine redémarré, la configuration de Productbase; Volume Manager et les métapériphériques devraient être disponibles.
Au redémarrage, vous obtiendrez des messages similaires aux suivants :
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é. Sur les serveurs UltraSPARC T2, SPARC T3-1, SPARC T3-1B, SPARC T4-1 et SPARC T4-1B, la limite est 512. Sur les serveurs UltraSPARC T2 Plus, les autres serveurs SPARC T3 et les autres serveurs SPARC T4, la limite est fixée à 768. Ce problème ne concerne que le domaine de contrôle car ce dernier se voit allouer, en partie si ce n'est en totalité, le sous-système d'E/S. Ce problème survient également en raison du nombre potentiellement important de LDC qui sont créés pour à la fois les communications de données d'E/S et le contrôle Logical Domains Manager des autres domaines.
Si vous essayez d'ajouter un service ou de lier un domaine, si bien que le nombre de canaux LDC dépasse la limite de 256 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 exact 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 ci-dessus, 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 Configuration système requise et recommandations du manuel Guide d’installation Oracle Solaris 10 8/11 : planification d’installations et de mises à niveau. Pour connaître la configuration système requise et les recommandations pour le SE Oracle Solaris 11, reportez-vous à la section Notes de version Oracle Solaris 11 .
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, le Logical Domains Manager étend automatiquement celui-ci à 12 méga-octets. 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 2.2.
Vous pouvez initialiser le nombre de domaines suivants en fonction de votre plate-forme :
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). Ne dépassez pas 32 instances vnet par service vsw car un nombre supérieur associé à un seul vsw peut entraîner des blocages au niveau du domaine de 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 de votre plate-forme, Guide d’installation Oracle Solaris 10 8/11 : planification d’installations et de mises à niveau et Installation des systèmes Oracle Solaris 11.
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 aux services vsw. Le domaine de service bénéficie d’une quantité de mémoire supplémentaire. Quatre giga-octets minimum sont recommandés pour l'exécution de 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 2.2.
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 de rallumer 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 met progressivement le système sous tension avant le redémarrage. Lorsque le système redémarre, il amorce la dernière configuration Logical Domains enregistrée ou explicitement définie.
Dans certaines circonstances, le 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 le redémarrage du domaine, mais pas après une mise sous tension progressive du système, à moins qu'elles ne soient lancées partir du microprogramme OpenBoot sur le domaine de contrôle ou suivies par l'enregistrement de la configuration sur le contrôleur système.
Dans ce contexte, il est important de noter qu’un redémarrage du domaine de contrôle peut déclencher une mise sous tension progressive du système :
Lorsque le domaine de contrôle redémarre,si aucun domaine invité n’est lié, et en l’absence de reconfiguration différée, le contrôleur système met progressivement sous tension le système.
Lorsque le domaine de contrôle redémarre, 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 ne met pas progressivement sous tension le 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 redémarrages 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 .2.2, 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 tous les redémarrages de ce domaine. Toutefois, elles ne persistent pas pendant une mise sous tension progressive 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 la mise sous tension progressive 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 le 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 le 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 tous les redémarrages du domaine, mais pas après une mise sous tension progressive 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 : 6520041, 6540368, 6540937 et 6590259.
Sun SNMP (Simple Network Management Protocol) Management Agent ne prend pas en charge plusieurs domaines. Seul un domaine global est pris en charge.
L’utilisation de la reconfiguration dynamique des CPU pour éteindre des CPU virtuelles ne fonctionnent pas avec des ensembles de processeurs, pools de ressources ou avec la fonctionnalité de CPU dédiées de la zone.
Lorsque vous utilisez la gestion de l’alimentation de CPU en mode élastique, l’invité SE Oracle Solaris ne voit que les CPU qui sont allouées aux domaines allumés. Cela signifie que la sortie de la commande psrinfo(1M) change dynamiquement selon le nombre de CPU dont l'alimentation est actuellement gérée. Cela entraîne un problème avec les ensembles de processeurs et les pools qui nécessitent que les ID de CPU réelles soient statiques pour permettre l’allocation à leurs ensembles. Cela peut également avoir une incidence sur la fonctionnalité de CPU dédiées de la zone.
Solution : Définissez le mode de performance pour la stratégie de gestion de l’alimentation.
Plusieurs problèmes liés à l’architecture FMA et à la gestion de l’alimentation des CPU ont été recensés. Si une panne survient dans une CPU définie en mode élastique, passez en mode de performance jusqu'à la reprise de la CPU. Si toutes les CPU en panne sont réparées, vous pouvez de nouveau utiliser le mode élastique.
Lorsqu'un domaine principal est à l'état de reconfiguration dynamique différée, l'alimentation ces CPU est gérée seulement après le redémarrage du domaine principal. Cela implique que la gestion de l’alimentation des CPU ne mette pas d’autres CPU en ligne pendant que le domaine subit une utilisation élevée, jusqu’à ce que le domaine primary redémarre, supprimant ainsi l’état de reconfiguration différée.
Le SE Oracle Solaris 10 10/09 introduit une nouvelle fonctionnalité appelée reconfiguration dynamique d’unités cryptographiques qui permet d’ajouter et de supprimer, de manière dynamique, des unités dans un domaine. Le 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 unités cryptographiques 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.
Aucune opération de désactivation principale n’est effectuée sur les domaines dont des unités cryptographiques sont liées lorsque la fonction de gestion de l'alimentation élastique est définie sur le processeur de service. Pour activer les opérations de désactivation principales à effectuer lorsque la fonction de gestion de l'alimentation élastique est définie sur le système, supprimez les unités cryptographiques qui sont liées au domaine.
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
Fonctionnalité Extended Mapin Space disponible uniquement dans le SE Oracle Solaris 10 8/11 et le SE Oracle Solaris 11. Par défaut, cette fonctionnalité est désactivée.
Vous pouvez utiliser la commande ldm add-domain ou ldm set-domain pour activer ce mode en définissant le paramètre extended-mapin-space=on sur un domaine exécutant le SE Oracle Solaris 10 8/11 ou le SE Oracle Solaris 11. Reportez-vous à la page de manuel ldm(1M).
A partir de Oracle VM Server for SPARC 2.1, seul l'outil Assistant de configuration terminal ldmconfig est disponible. L'outil d'interface graphique n'est plus disponible.
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 racine (/) 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.
Récupération : 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 requêtes de configuration de CPU, celles-ci seront rejetées.
Solution : effectuez l'une des opérations suivantes :
Si vous annulez ensuite la reconfiguration différée, lancez-en une autre, puis redemandez les modifications de configuration qui étaient perdues dans la dernière reconfiguration retardée.
Redémarrez 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.
Les machines source et cible doivent exécuter au moins la version du Logical Domains Manager.
Les exemples suivants illustrent les messages qui s'affichent lorsque vous exécutez des versions antérieures du Logical Domains Manager, du microprogramme du système ou les deux :
La machine cible exécute une version antérieure du Logical Domains Manager.
Par exemple, supposons que les machines source et cible exécutent les versions suivantes :
Machine source. Exécute la version 2.1 du Logical Domains Manager et la version 7.4 du microprogramme du système
Machine cible. Exécute la version 2.0 du Logical Domains Manager et la version 7.4 du microprogramme du système
# ldm migrate ldg1 system2 The target machine is running an older version of the domain manager that does not support the latest migration functionality.
La machine source exécute une version antérieure du Logical Domains Manager.
Par exemple, supposons que les machines source et cible exécutent les versions suivantes :
Machine source. Exécute la version 2.0 du Logical Domains Manager et la version 7.4 du microprogramme du système
Machine cible. Exécute la version 2.1 du Logical Domains Manager et la version 7.4 du microprogramme du système
# ldm migrate ldg1 system2 The source machine is running an older version of the domain manager that is not compatible with the version running on the target machine.
Les machines source et cible exécutent une version antérieure du Logical Domains Manager.
Par exemple, supposons que les machines source et cible exécutent les versions suivantes :
Machine source. Exécute la version 2.0 du Logical Domains Manager et la version 7.3 du microprogramme du système
Machine cible. Exécute la version 2.0 du Logical Domains Manager et la version 7.4 du microprogramme du système
# ldm migrate ldg1 system2 Unable to migrate guest resource state Domain Migration of LDom ldg1 failed
La machine cible exécute une version antérieure du microprogramme du système qui n'est pas compatible avec la version du microprogramme du système exécutée sur la machine source.
Par exemple, supposons que les machines source et cible exécutent les versions suivantes :
Machine source. Exécute la version 2.1 du Logical Domains Manager et la version 7.4 du microprogramme du système
Machine cible. Exécute la version 2.1 du Logical Domains Manager et la version 7.3 du microprogramme du système
# ldm migrate ldg1 system2 The target machine is running an older version of the System Firmware that is not compatible with the version running on the source machine.
La machine source exécute une version antérieure du microprogramme du système qui n'est pas compatible avec la version du microprogramme du système exécutée sur la machine cible.
Par exemple, supposons que les machines source et cible exécutent les versions suivantes :
Machine source. Exécute la version 2.1 du Logical Domains Manager et la version 7.3 du microprogramme du système
Machine cible. Exécute la version 2.1 du Logical Domains Manager et la version 7.4 du microprogramme du système
# ldm migrate ldg1 system2 The source machine is running an older version of the System Firmware that does not support the latest migration functionality.
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 noyaux complets doivent être alloués au domaine migré. Si le nombre de threads dans le domaine à migrer est inférieur à un noyau 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é redémarré. A ce stade, vous pouvez utiliser la DR sur le domaine migré.
La machine cible doit disposer de suffisamment de noyaux complets totalement libres pour fournir le nombre de threads requis pour le domaine migré. Après la migration, si un noyau 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 2.2.
Cette section récapitule les problèmes que vous risquez de rencontrer lors de l'utilisation du logiciel Base d'informations de gestion (MIB) Oracle VM Server for SPARC.
Remarque - Le logiciel Oracle VM Server for SPARC MIB est uniquement disponible sur les systèmes Oracle Solaris 10.
ID du bogue 6521530 : Vous recevez des tables SNMP si 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 de Oracle VM Server for SPARC MIB du manuel Guide d’administration d’Oracle VM Server for SPARC 2.2.
Cette section récapitule les bogues que vous risquez de rencontrer lors de l'utilisation de cette version du logiciel. Les descriptions des bogues sont indiquées dans l'ordre numérique, par ID de bogue. Si une procédure de reprise et une solution sont disponibles, elles sont spécifiées.
ID de bogue 7166620 : 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é.
Récupération : 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 7165095 et 7165101 : sur un système avec des domaines d'E/S directes ou SR-IOV, l'annulation d'une reconfiguration retardée et l'exécution de toute opération de reconfiguration successive entraîne l'interruption anormale du démon ldmd et la création d'un fichier core. Le service SMF ldmd peut également passer en mode de maintenance.
Solution : évitez d'utiliser la commande ldm cancel-reconf. Si vous devez annuler la reconfiguration retardée, ou si celle-ci a déjà été annulée, redémarrez le service SMF ldmd pour pouvoir effectuer des opérations ldm.
# scvadm restart ldmd
Récupération : si le service SMF ldmd passe en mode de maintenance, vous devez mettre progressivement sous tension le système avant de pouvoir restaurer le service ldmd.
Ci-après, une description de la procédure de mise sous tension progressive du système à partir du domaine de contrôle et du processeur de service (SP) :
Domaine de contrôle. Exécutez les commandes ci-dessous :
# halt
SP. Exécutez les commandes ci-dessous :
-> stop /SYS
Are you sure you want to stop /SYS (y/n)? y
-> show /HOST status
/HOST
Properties:
status = Powered Off
-> start /SYS
Are you sure you want to start /SYS (y/n)? y
Starting /SYS
-> start /HOST/console
Are you sure you want to start /HOST/console (y/n)? y
->ID de bogue 7160502 : Les CPU désactivées peuvent faire en sorte que le Logical Domains Manager signale un nombre incorrect de ressources de CPU. L'exemple suivant montre que la dissociation erronée d'un domaine modifie le nombre de ressources de CPU pour le domaine :
# ldm list NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME primary active -n-cv- UART 9 4G 0.2% 1h 5m ldg1 bound ------ 5000 116 2G # ldm unbind ldg1 # ldm list NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME primary active -n-cv- UART 9 4G 1.1% 1h 5m ldg1 inactive ------ 120 2G
A ce stade, le nombre de ressources de CPU est incorrect. Le nombre pour le domaine ldg1 doit être 116 et non 120 comme indiqué après la dissociation.
Remarque - Il s'agit d'un simple exemple et il peut exister d'autres cas où le nombre de CPU peut être incorrect en raison de la désactivation des CPU. Dans de tels cas, utilisez l'approche présentée dans la solution.
Solution : si possible, évitez d'utiliser des noyaux où les CPU sont désactivées. Sinon, lorsque vous dissociez un domaine contenant des noyaux désactivés, veillez à redéfinir le nombre de CPU sur le nombre correct de sorte que le domaine puisse être réinitialisé ultérieurement.
Pour associer à nouveau le domaine, redéfinissez le nombre de ressources de CPU. Par exemple :
# ldm set-vcpu 116 ldg1 # ldm bind ldg1
ID de bogue 7159359 : 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 7159114 : Lorsque vous faites basculer le domaine de contrôle d'une utilisation de noyaux 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 7158496 : 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 virtuellles 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 7158454: 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, si un grand nombre de périphériques réseau virtuels est situé sur le même commutateur virtuel dans plusieurs domaines. En règle générale, ce problème survient lorsque 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 7155386: Lorsqu'un fichier XML contient à la fois les configurations de domaine de contrôle et de domaine invité, la commande ldm init-system configure d'abord les domaines invités, puis le domaine de contrôle. Dans une configuration usine par défaut où aucun serveur de disque virtuel n'est configuré, la tentative d'ajout d'un périphérique de serveur de disque virtuel vers les domaines invités risque d'échouer avec l'erreur suivante :
Disk Server xxx not found
Cette erreur survient si le serveur de disque virtuel spécifié est censé être fourni par le domaine de contrôle.
ID de bogue 7155349 : la définition d'emplacements unicast sur un nombre dépassant la limite maximale entraîne un échec accompagné d'un message d'erreur approprié. La valeur du nombre d'emplacements unicast est toutefois redéfinie sur 0 de façon incorrecte et silencieuse.
Solution : spécifiez une valeur pour le nombre d'emplacements unicast située dans les valeurs prises en charge.
ID de bogue 7155282 : 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 7153060 : le domaine de contrôle requiert le noyau 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 de noyau complet au domaine de contrôle.
Par exemple, si le noyau 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 7151847 : 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 versionsOracle Solaris 10 ou ultérieures du SE Oracle Solaris. 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 7150793 : 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.
Récupération : 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 7150209 : Sur un système qui exécute le SE Oracle Solaris sur le domaine de contrôle et le domaine d'E/S, certaines cartes Emulex affectées au domaine d'E/S ne fonctionnent pas correctement car celles-ci ne reçoivent pas les interruptions. Toutefois, lorsqu' elles sont affectées au domaine de contrôle, ces mêmes cartes fonctionnent correctement.
Ce problème survient avec les cartes Emulex suivantes :
Emulex 2-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM2)
Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE2FC-EB4-N)
Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM4)
Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-Z)
Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-N)
Solution de contournement : aucune.
ID de bogue 7149951 : si la commande cputrack est exécutée sur un domaine invité pendant la migration 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 7149365: 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 7149323 : un domaine d'E/S possède un nombre limité de ressources d'interruptions disponibles par complexe racine.
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 7148394 : 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 7146725 : lorsque vous utilisez la commande ldm init-system pour installer un domaine à partir d'une configuration XML, le domaine primary ne parvient pas à se réinitialiser bien que l'option -r soit spécifiée.
Solution : réinitialisez manuellement le domaine primary.
ID de bogue 7146423 : 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 7144314 : 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 7142913 : Après avoir lié et démarré 15 domaines invités, le domaine primary panique et le message d'erreur suivant est émis :
panic: BAD TRAP: occurred in module "pcie" due to an illegal access to a user address
Les domaines sont configurés comme suit :
Domaine invité. Possède les périphériques de fonction virtuelle igb et ixgbe. Possède également la propriété master définie sur primary.
Domaine primary. Possède la propriété failure-policy définie sur stop.
ID de bogue 7134203 : les périphériques d'E/S existants ne sont pas correctement supprimés à partir du domaine de contrôle lorsque celui-ci est reconfiguré à partir d'un fichier XML à l'aide de la commande ldm init-system. Cette situation peut entraîner un échec de la liaison sur le domaine invité si le domaine de contrôle possède toujours des périphériques du noeud du terminal PCIe liés au domaine de contrôle.
ID de bogue 7131596> : si vous spécifiez un backend vdsdev incorrect à la commande ldm add-vdsdev, le message d'erreur qui en découle identifie le backend en tant que chemin valide :
# ldm add-vdsdev /wrong/path/file disk1@primary-vds0 Path /wrong/path/file is valid but not accessible on service domain primary
Solution : vérifiez et, le cas échéant, corrigez le chemin spécifié.
ID de bogue 7130693 : après avoir désactivé la contrainte wole-core, la contrainte réapparaît au terme de la réinitialisation d'un domaine primary.
Ce problème survient dans les cas suivants :
Le domaine primary est en mode de reconfiguration différée.
Le nombre de CPU virtuelles que vous spécifiez avec la commande ldm set-vcpu (sans l'option -c) correspond au nombre de CPU virtuelles utilisé pour définir la contrainte whole-core avant le début de la reconfiguration différée.
solution : désactivez la contrainte whole-core en spécifiant un nombre différent de CPU virtuelles.
ID de bogue 7129252 : les ressources situées sur le complexe racine ne sont pas restaurées après la destruction de l'ensemble des fonctions virtuelles et le renvoi des emplacements vers le domaine racine.
Solution : effectuez les étapes suivantes :
Supprimez le bus PCIe du domaine racine.
primary# ldm rm-io pci_0 primary Initiating a delayed reconfiguration operation on the primary domain. All configuration changes for other domains are disabled until the primary domain reboots, at which time the new configuration for the primary domain will also take effect.
Réaffectez le bus PCIe au domaine racine.
primary# ldm add-io pci_0 primary ------------------------------------------------------------------------------ Notice: The primary domain is in the process of a delayed reconfiguration. Any changes made to the primary domain will only take effect after it reboots. ------------------------------------------------------------------------------
Réinitialisez le bus PCIe sur le domaine racine.
primary# reboot
ID de bogue 7125579 : un domaine invité risque de ne pas démarrer en raison d'une erreur inattendue de l'hyperviseur. Même si le domaine ne parvient pas à démarrer, la commande existe avec 0 au lieu de 1 et émet le message d'erreur suivant :
LDom domain start failed, retry the operation
Solution : ne comptez pas uniquement sur le code d'abandon pour déterminer si un domaine a correctement démarré. A la place, effectuez l'une des vérifications suivantes :
Vérifiez que la commande ldm émet un message d'erreur.
Vérifiez l'état du domaine après l'exécution de la commande de démarrage.
ID de bogue 7121963 : 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 7118936 : 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 7109458 : utilisez la commande ldm set-io pour modifier la valeur de la propriété pvid d'une fonction virtuelle à plusieurs reprises 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 7104911 : 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 7101229 : 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 7100859 : 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 multisocket. Cela se produit quand les chemins vers les emplacements PCIe sont similaires (sauf pour le chemin complexe de racine). 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 2.2.
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 7100841 : lorsque le domaine primary partage le noyau physique le plus bas (généralement 0) avec un autre domaine, il tente de définir la contrainte de noyau complet pour l'échec du domaine primary.
Solution : effectuez les étapes suivantes :
Déterminez le noyau lié le plus bas étant partagé par les domaines.
# ldm list -o cpu
Dissociez tous les threads de CPU du noyau le plus bas de tous les domaines autres que le domaine primary.
Par conséquent, les threads de CPU du noyau le plus bas ne sont pas partagés et sont libres pour être liés au domaine primary.
Définissez la contrainte de noyau complet en effectuant l'une des opérations suivantes :
Liez les threads de CPU au domaine primary et définissez la contrainte de noyau complet à 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 de noyau complet en une simple étape.
ID de bogue 7098941 : 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 du 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 7093344 : vous pouvez uniquement utiliser la commande ldmconfig sur les systèmes Oracle Solaris 10.
ID de bogue 7084728 : 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 7083321 : le démon nwam conserve un compteur de références sur le noeud de périphérique de la carte NIC qui empêche au périphérique NIC d'être retiré.
Solution : n'utilisez pas le profil de configuration réseau Automatic. A la place, utilisez le profil de configuration réseau DefaultFixed.
ID de bogue 7082776 : vous pouvez uniquement utiliser l'Oracle VM Server for SPARC MIB sur les systèmes Oracle Solaris 10.
ID de bogue 7071426 : é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 7062298 : 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 7058261 : lorsque vous utilisez la commande ldm stop pour arrêter un domaine à mémoire volumineuse alors que le système est en mode de gestion de l'alimentation élastique, l'opération peut prendre beaucoup de temps. Si le domaine est suffisamment inactif, la plupart des threads de CPU attribués au domaine seront désactivés. En désactivant les CPU, le traitement requis pour arrêter un domaine est laissé aux threads actifs restants.
Par exemple, il faut environ 7 minutes pour arrêter un domaine invité comptant 252 Go de mémoire et seulement 2 CPU activées.
Solution : désactivez la gestion de l'alimentation (PM) en passant du mode élastique au mode performance avant d'arrêter le domaine.
ID de bogue 7054326 : Vous ne pouvez pas utiliser les opérations d'enfichage à chaud d'Oracle Solaris pour retirer à chaud un périphérique d'extrémité PCIe après l'avoir supprimé du domaine primary en utilisant 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 2.2.
ID de bogue 7042353 : 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
Vous pouvez contourner ce problème en installant le patch 147708-01 sur le domaine primary et tout service de domaine, 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 7038650 : 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 7036137 : 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 7035438 : ldmd vous permet d'activer la contrainte de noyau complet sur un domaine comportant des noyaux partiels, mais ne parvient cependant pas à supprimer ou définir des noyaux de ce domaine.
Solution : procédez comme suit à partir de la configuration usine par défaut du domaine de contrôle :
Démarrez une reconfiguration retardée sur le domaine de contrôle.
# ldm start-reconf primary
Procédez d'abord aux opérations de reconfiguration de mémoire.
Effectuez les opérations de reconfiguration de CPU.
# ldm set-vcpu 16 primary # ldm set-vcpu -c 2 primary
Cet exemple utilise deux noyaux, mais le nombre de noyaux peut aller de 1 jusqu'à la limite du système.
ID de bogue 7034191 : 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 7030045 : 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é.
Récupération : mettez la machine source sous tension progressivement.
ID de bogue 7027105 : 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 7026177 : 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 7026160 : vous procédez à une migration de domaine alors qu'une stratégie DRM est active. Plus tard, si la stratégie DRM expire ou est supprimée du domaine migré, elle ne parviendra pas à rétablir le nombre de CPU virtuelles d'origine 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 7025445 : 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 7023216 : 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 7019493 : Si deux commandes ldm migrate sont émises simultanément dans des “directions opposées,” elles risquent de se bloquer et de ne jamais aboutir. Par exemple, 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.
Il en résulte le blocage des processus de migration, même s'ils sont initialisés en tant que simulations en utilisant -n. Lorsque ce problème se produit, toutes les autres commandes ldm risquent de se bloquer.
Solution de contournement : aucune.
ID de bogue 6994984 : 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 6989192 et 7071760 : 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 6984681 : 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 6984008 : 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 à différents domaines 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. Voici les étapes à suivre pour déterminer si le système T3-1 comporte des disques double port :
Déterminez si le système comporte des disques double port en exécutant la commande suivante sur le processeur de service :
-> 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 6983279 : 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 principal.
# ldm start-reconf primary
Assignez la quantité de mémoire souhaitée au domaine.
Redémarrez 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 6979574 : 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 6968507 : 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, le 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, le Logical Domains Manager supprime automatiquement les CPU.
ID de bogue 6968100 : 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 6967799 : le script ldmconfig ne peut pas créer correctement une configuration de domaines logique stockée sur le processeur de service.
Solution : ne mettez pas le système sous tension 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
Remettez progressivement sous tension le système.
Si vous effectuez cette procédure avant la mise sous tension progressive 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 la mise sous tension progressive.
ID de bogue 6965758 : La migration d'un domain 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 le Logical Domains Manager recourt à la reconfiguration dynamique des CPU jusqu'à ce qu'il ne reste qu'une seule CPU dans le domaine. Ce faisant, le Logical Domains Manager tente de supprimer du domaine toutes les CPU sauf celle portant le plus petit numéro, mais puisqu'elle 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 6956431 : suite à la suspension d'un domaine Oracle Solaris 10 10/09 dans le cadre d'une opération de migration, la reconfiguration dynamique de la mémoire est désactivée. Ce problème 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 6936833 : 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 6904849 : A 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 6904240 : 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 6897743 : 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.
Par la suite, aucune des connexions ssh ne recourra aux unités cryptographiques matérielles (et ne tirera donc pas parti des améliorations des performances qui y sont associées), et les connexions ssh ne seront plus arrêtées lorsque des unités cryptographiques seront supprimées.
ID de bogue 6892229 : 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 6855079 : 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 : Evitez 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 6853273 : lorsqu'un système fonctionne en mode élastique de gestion de l'alimentation, le redémarrage d'un domaine invité risque de générer les messages d'avertissement suivants et d'aboutir à un échec :
WARNING: /virtual-devices@100/channel-devices@200/disk@0: Sending packet to LDC, status: -1 WARNING: /virtual-devices@100/channel-devices@200/disk@0: Can't send vdisk read request! WARNING: /virtual-devices@100/channel-devices@200/disk@0: Timeout receiving packet from LDC ... retrying
Solution : En présence de ces avertissements, mettez en oeuvre l'une des solutions suivantes dans l'ordre indiqué :
Si le domaine invité affiche une invite ok> et accepte une saisie, tapez reset-all
Depuis le domaine de contrôle, exécutez une commande ldm stop domain-name, puis une commande ldm start domain-name
Modifiez la stratégie de gestion de l'alimentation sur la stratégie de performance, arrêtez et redémarrez le domaine invité affecté, puis revenez à la gestion élastique.
ID de bogue 6839787 : parfois, un domaine invité qui exécute au minimum le SE Oracle Solaris 10 10/08 ne parvient pas à établir correctement une connexion des services de domaine exécutant le SE Oracle Solaris 10 5/09.
Les connexions de services de domaine permettent d'activer certaines fonctionnalités, comme la reconfiguration dynamique (DR), l'architecture FMA et la gestion de l'alimentation (PM). Dans la mesure où l'échec de la connexion se produit lorsque le domaine invité est initialisé, il suffit de redémarrer le domaine pour résoudre le problème.
Solution : redémarrez le domaine invité.
ID de bogue 6837615 : 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.
Les solutions sont les suivantes :
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 6836587 : 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 durant un 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 bogue 6829016 : 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 que la machine est mise progressivement sous tension.
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 un redémarrage 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 6808832 : vous pouvez configurer un maximum de deux domaines avec des racines complexes PCI-E sur des systèmes tels que le Sun Fire T5240. Ces systèmes sont dotés de deux CPU UltraSPARC T2+ et de deux racines complexes d'E/S.
pci@500 et pci@400 sont les deux racines complexes du système. Le domaine principal contient toujours au moins une racine complexe. Un second domaine peut être configuré avec une racine complexe non assignée ou non liée.
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 principal contenant pci@500 et un second domaine contenant pci@400
Remarque - Sur certaines lames, le domaine principal (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 principal :
/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 6781589 : 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 6773569 : après avoir changé de configuration (à l'aide de la commande ldm set-config suivie d'une mise sous tension progressive), il arrive que les domaines définis dans la configuration précédente soient encore présents dans la configuration en cours, à l'état inactif.
Cela se produit si la base de données de contraintes du Logical Domains Manager n'est pas synchronisée avec le changement de configuration. Ces domaines inactifs n'ont pas d'incidence sur la configuration active et peuvent être détruits en toute sécurité.
ID de bogue 6772120 : 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, le 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 :
Effectuez les opérations suivantes :
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 6772089 : 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 6764613 : 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, le 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 6760933 : dans certains cas, les domaines logiques actifs semblent être à l'état de transition au lieu de normal longtemps après avoir été initialisés 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.
Récupération : après le redémarrage suivant, le domaine affiche l'état correct.
ID de bogue 6757486 : 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 6753683 : parfois, l'exécution de la commande uadmin 1 0 à partir de la ligne de commande d'un système Logical Domains ne laisse pas le système à l'invite ok après la réinitialisation suivante. 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 6742805 : L'arrêt d'un domaine ou l'effacement de 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 effacer l'ensemble de la mémoire détenue par le domaine. Le temps mis pour effectuer l'effacement 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 d'effacement 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 noyau. Le temps nécessaire à l'arrêt s'en trouvera réduit.
ID de bogue 6705823 : 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 la miniracine de l'image d'installation réseau du SE Oracle Solaris 10 8/07 à l'aide du patch ID 127111-05.
ID de bogue 6656033 : 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 : 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.
Reprise : 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 6610702 : 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 de Oracle Solaris, lequel peut être différent pour chaque message d'avertissement.
Solution : vous pouvez ignorer ces messages.
ID de bogue ID 6603974 : 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 6591844 : si une erreur de CPU ou de mémoire a lieu, le domaine affecté risque de paniquer et de se réinitialiser. Si FMA (Fault Management Architecture) essaie de retirer le composant défaillant pendant le redémarrage du domaine, le Logical Domains Manager est incapable de communiquer avec le domaine, et l'opération de retrait échoue. Dans ce cas, la commande fmadm faulty répertorie la ressource en tant que degraded.
Récupération : patientez jusqu'à la réinitialisation du domaine, puis forcez FMA à rejouer l'événement défectueux en redémarrant le démon du gestionnaire défectueux (fmd) sur le domaine de contrôle à l'aide de cette commande :
primary# svcadm restart fmd
ID de bogue 6540368 : 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 6510214 : Dans un environnement Logical Domains, la définition et la suppression de clés d'initialisation via connexion WAN à partir du SE Oracle Solaris à l'aide de la commande ickey(1M) ne sont pas prises en charge. 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 le redémarrage du domaine. Sur ces domaines, les clés définies à partir du microprogramme OpenBoot sont valides uniquement pour un seul usage.
ID de bogue 6506494 : 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
|