| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Notes de version d'Oracle VM Server for SPARC 2.1 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.1 Oracle VM Server for SPARC (Français) |
1. Notes de version d'Oracle VM Server for SPARC 2.1
Plates-formes prises en charge
Oracle Solaris OS requis et recommandé
Logiciels requis pour activer les fonctionnalités d'Oracle VM Server for SPARC 2.1.
Patches de microprogramme système requis et recommandés
Version logicielle minimale requise
Configuration matérielle et logicielle requise pour les E/S directes
Conditions préalables à la migration de domaine en direct
Emplacement du logiciel Oracle VM Server for SPARC 2.1
Emplacement de la documentation
Logiciels compatibles avec le Logical Domains Manager
Logiciels de contrôleur système utilisés avec le logiciel Logical Domains
Assignation de ressources physiques à des domaines
Gestion des ressources physiques sur le domaine de contrôle
Restrictions de gestion des ressources physiques sur les domaines
Mise à niveau du logiciel Oracle VM Server for SPARC 2.1
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
Fault Management (Gestion des pannes)
ldmp2v convert : des messages d'avertissement VxVM durant une initialisation avec cette commande
Suppression de l'outil Assistant de configuration graphique
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
Restrictions de la migration de domaine
Restrictions de version pour la migration
Restrictions de la CPU pour la migration
Problèmes liés à la MIB Oracle VM Server for SPARC
Valeur de propriété ldomCryptoRpReserved incorrecte
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.1
Les noyaux nommés peuvent désactiver toutes les CPU en mode de liaison
Un domaine principal à noyau partiel pour permettre des transitions DR à noyau complet
Prise en charge de ldmconfig uniquement sur les systèmes Oracle Solaris 10
MIB Oracle VM Server for SPARC est pris en charge uniquement sur les systèmes Oracle Solaris 10.
Suppression d'un grand nombre de CPU du domaine invité
Le mode de threading de la CPU n'est pas restauré après l'annulation de la migration d'un domaine.
Opération d'arrêt d'un domaine à mémoire volumineuse très longue en mode élastique
install-ldm se bloque lors de son exécution avec un chemin absolu à partir d'un autre répertoire.
La validation de disque virtuel échoue pour un disque physique sans tranche 2
Lorsque la situation incoming_migration_enabled=false se présente, les migrations sortantes échouent
Une configuration SP incorrecte est utilisée comme configuration par défaut
La commande ldmd ne supprime pas les noyaux d'un domaine ayant des noyaux partiels
Un interblocage de noyau provoque le blocage de la machine pendant une migration
Échec de délai d'attente de CPU virtuelles lors de la reconfiguration dynamique
Suppression d'un grand nombre de CPU du domaine de contrôle
SPARC T3 : Oracle VM Server for SPARC se bloque lors de l'exécution d'opérations de mémoire
SPARC T3-1 : Détection et gestion des disques accessibles via plusieurs voies d'E/S directes
ldmd signale à tort une utilisation à 100 % de la CPU sur un domaine
Les domaines invités ne peuvent pas s'initialiser à partir d'un périphérique DVD exporté
Impossible de supprimer des unités cryptographiques du domaine principal
Une adresse MAC en cours d'utilisation peut être réaffectée
ldmconfig ne peut pas créer une configuration de domaine sur le processeur de service
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
Échec possible de la reconfiguration dynamique des valeurs MTU de périphériques réseau virtuel
La DR de la mémoire n'est pas prise en charge avec certaines configurations de mémoire physique
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
Les périphériques réseau virtuels ne sont pas créés correctement sur le domaine de contrôle
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
Blocage possible du SE invité en cas d'opérations simultanées
Il arrive que la reconfiguration dynamique ne parvienne pas à supprimer toutes les CPU demandées
Erreurs identifiées dans la documentation
Référence croisée incorrecte pour les informations de logiciels requis
Description erronée de la commande ldm stop
Nom du package Logical Domains Manager incorrect dans la procédure de mise à niveau
Cette section recense les problèmes d’ordre général et les bogues liés au logiciel Oracle VM Server for SPARC 2.1.
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.
Depuis la version 2.0 d’Oracle VM Server for SPARC, 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 9/10 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 9/10, 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 Solaris Volume Manager risque de ne plus pouvoir détecter sa configuration ou d’accéder à ses métapériphériques.
Solution : Après avoir mis à niveau un domaine de service vers Oracle Solaris 10 9/10, si un domaine invité ne parvient pas à détecter sa configuration Solaris Volume Manager ou ses métapériphériques, suivez la procédure ci-dessous.
md_devid_destroy=1; md_keep_repl_state=1;
Une fois le domaine redémarré, la configuration de Solaris Volume Manager et les métapériphériques devrait à nouveau ê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 fixée à 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 logiques.
Si vous essayez d’ajouter un service ou de lier un domaine, si bien que le nombre de canaux LDC dépasse la limite 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é définie sur off, les canaux LDC ne sont pas utilisés pour les communications inter-vnet. À 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 au ldm(1M) man page.
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 :
Un réseau virtuel
Un disque virtuel
Une 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 32 domaines au lieu de 8, où chaque domaine comporte 3 disques virtuels, 3 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 la taille de mémoire requise et recommandée pour le SE Oracle Solaris 10, reportez-vous à la section Configuration système requise et recommandations du Guide d’installation Oracle Solaris 10 9/10 : planification d’installations et de mises à niveau .
OpenBoot PROM 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 250 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 Guide d’administration d’Oracle VM Server for SPARC 2.1.
Vous pouvez initialiser les nombres suivants de domaines en fonction de la plate-forme que vous utilisez :
128 au maximum sur des serveurs SPARC T4 ;
128 au maximum sur des serveurs SPARC T3 ;
128 au maximum sur des serveurs UltraSPARC T2 Plus ;
64 au maximum sur des 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 a besoin d'une quantité de mémoire adéquate 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, Oracle Solaris 10 8/11 Installation Guide: Planning for Installation and Upgrade et Installing Oracle Solaris 11 Systems .
L’utilisation de la mémoire et de l’espace de swap augmente dans un domaine invité lorsque les services vsw utilisés par le domaine fournissent un nombre trop important de 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 Guide d’administration d’Oracle VM Server for SPARC 2.1.
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 :
À l’invite OpenBoot :
En utilisant la commande eeprom(1M) du Oracle Solaris OS
En utilisant la CLI du 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.1, 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 suivants ont été conservés pour résoudre ces problèmes : 6520041, 6540368, 6540937 et 6590259.
Sun SNMP (Simple Management Network 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é Oracle Solaris OS 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 alors qu’elle tourne 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 principal 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 Oracle Solaris OS .
Aucune opération de désactivation principale n’est effectuée sur les domaines dont des unités cryptographiques sont liées lorsque le processeur de service fonctionne en mode élastique. Pour activer les opérations de désactivation principales à effectuer lorsque le système fonctionne en mode élastique, 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
La fonctionnalité Extended Mapin Space est uniquement disponible 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 qui exécute le SE Oracle Solaris 10 8/11 ou le SE Oracle Solaris 11. Reportez-vous à la page de manuel ldm(1M).
À 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.
Le programme d'installation 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.
Reprise : Redémarrez le domaine concerné.
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.
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 2.1 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 des 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 Oracle Solaris OS antérieure au SE Oracle Solaris 10 9/10, 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 :
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é.
Suite à la migration, la reconfiguration dynamique (DR, dynamic reconfiguration) de la CPU est désactivée pour le domaine cible tant qu'il n'est pas réinitialisé. À 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 en cours d’exécution dans OpenBoot ou dans le débogueur de noyau du Guide d’administration d’Oracle VM Server for SPARC 2.1.
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 MIB Oracle VM Server for SPARC est disponible uniquement sur les systèmes Oracle Solaris 10.
ID du bogue 7042966 : la valeur de la propriété ldomCryptoRpReserved dans le pool de ressources de l'unité de chiffrement (ldomCryptoResourcePool) inclut à tort le nombre de périphériques d'unité de chiffrement qui ont été affectés aux domaines inactifs.
ID du bogue 6521530 : vous recevez des tables SNMP vides si vous interrogez le logiciel MIB Oracle VM Server for SPARC 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 des requêtes GETNEXT, et non GETBULK, pour l'extraction des données. Reportez-vous à la section Récupération des objets MIB Oracle VM Server for SPARC du Guide d’administration d’Oracle VM Server for SPARC 2.1.
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 7117766 : la commande ldm init-system ne parvient pas à restaurer les contraintes de noyau de CPU nommé pour les domaines invités depuis un fichier XML enregistré.
Solution : effectuez les opérations suivantes :
Créez un fichier XML pour le domaine principal.
# ldm ls-constraints -x primary > primary.xml
Créez un fichier XML pour le ou les domaines invités.
# ldm ls-constraints -x ldom[,ldom][,...] > guest.xml
Mettez le système sous tension progressivement et initialisez une configuration par défaut d'usine.
Appliquez la configuration XML au domaine principal.
# ldm init-system -r -i primary.xml
Redémarrez
Appliquez la configuration XML aux domaines invités.
# ldm init-system -f -i guest.xml
ID de bogue 7111119 : vous ne pouvez pas utiliser les commandes ldm add-core, ldm set-core et ldm remove-core quand la stratégie élastique est activée pour le domaine.
Solution : assurez-vous que la stratégie de performance est activée pour le domaine.
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 principal. 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 Guide d’administration d’Oracle VM Server for SPARC 2.1.
Par exemple, si vous retirez 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), qui ont des noms de chemin similaires, la prochaine initialisation du SE Oracle Solaris 11 peut paniquer.
La commande ldm list-io est exécutée une fois que les emplacements PCIe /SYS/MB/PCIE4 et /SYS/MB/PCIE5 sont retirés.
# 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 retirez pas tous les emplacements qui ont des noms de chemin similaires. Au lieu de cela, ne retirez qu'un seul de ces emplacements 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 : quand le domaine principal partage le noyau physique le plus bas (généralement 0) avec un autre domaine, les tentatives de définition de la contrainte de noyau complet pour le domaine principal échouent.
Solution : effectuez les opérations 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 principal.
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 principal.
Définissez la contrainte de noyau complet en effectuant l'une des opérations suivantes :
Liez les threads de CPU au domaine principal 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 7093344 : vous pouvez uniquement utiliser la commande ldmconfig sur les systèmes Oracle Solaris 10.
ID de bogue 7082776 : vous pouvez utiliser MIB Oracle VM Server for SPARC uniquement sur les systèmes Oracle Solaris 10.
ID de bogue 7071426 : une panique peut survenir au cours d'une migration lorsque le domaine concerné contient plusieurs blocs de mémoire équivalant à un total supérieur à 500 Go. Utilisez la commande ldm list -o mem pour déterminer la quantité de mémoire du domaine.
La pile de panique ressemble à 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 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 7061265 : si vous annulez la migration d'un domaine dont la propriété threading est définie sur max-ipc, la propriété threading est automatiquement rétablie sur la valeur max-throughput sur le domaine concerné, ce qui n'est pas correct.
Solution : rétablissez manuellement la propriété threading sur la valeur max-ipc sur le domaine concerné par la migration à partir de la machine source.
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 de connexion à chaud de Solaris pour retirer à chaud un périphérique d'extrémité PCIe après l'avoir supprimé du domaine principal 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 Guide d’administration d’Oracle VM Server for SPARC 2.1.
ID de bogue 7050588 : si vous spécifiez le chemin absolu dans la commande install-ldm à partir d'un autre répertoire, la commande se bloque.
Solution : accédez au répertoire dans lequel est installée la commande install-ldm avant de l'exécuter.
# cd dirname/OVM_Server_SPARC-2_1/Install # ./install-ldm
ID de bogue 7044329 : si un domaine invité comporte un périphérique virtuel dont le nom contient plus de 31 caractères, OpenBoot envoie un message d'erreur au démarrage du domaine. L'alias de périphérique qui correspond au nom du périphérique virtuel n'est pas créé.
Le message d’erreur ressemble au suivant :
Error: device alias name 'mynet1234567890123456789012345678901234567890' length is greater than 31 chars, device alias not created
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 utilisant l'option -q de la commande ldm add-vdsdev :
# ldm add-vdsdev -q /dev/dsk/c3t1d0s2 vol@primary-vds0
Si vous utilisez la commande lmd 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 7039793 : lorsque incoming_migration_enabled=false et outgoing_migration_enabled=true, les migrations sortantes échouent en renvoyant le message suivant :
The source machine is running an older version of the System Firmware that is not compatible with the version running on the target machine.
Lorsque outgoing_migration_enabled=false, les migrations sortantes sont censées échouer.
Solution : Procédez comme suit :
Définissez incoming_migration_enabled=true.
# svccfg -s ldmd setprop ldmd/incoming_migration_enabled=true
Actualisez ldmd.
# svcadm refresh ldmd
Redémarrez ldmd.
# svcadm restart ldmd
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 7037495 : l'utilisation de la console de gestion Sun Management Console pour demander l'état des CPU d'un système Oracle VM Server for SPARC est susceptible d'entraîner la corruption des données. Cette corruption se limite aux structures de données utilisées par l'hyperviseur pour procéder au suivi des domaines en exécution et empêche le démarrage du Logical Domains Manager. Ainsi, n'utilisez pas le logiciel Sun Management Console pour contrôler les systèmes Oracle VM Server for SPARC.
Solution : mettez progressivement sous tension une configuration reconnue comme valide.
ID de bogue 7037295 : si le Logical Domains Manager est redémarré ou si le domaine primary est réinitialisé après l'exécution de la commande ldm add-spconfig -r spconfig, le Logical Domains Manager utilise la configuration par défaut à la place de celle spécifiée, spconfig. Cela signifie que toutes les modifications de configuration postérieures sont effectuées dans la configuration par défaut, et non dans celle spécifiée, spconfig.
Solution : définissez la configuration actuelle du Logical Domains Manager en effectuant une mise sous tension progressive ou en exécutant la commande ldm add-spconfig spconfig.
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 :
Lancer une reconfiguration différée sur l'élément de contrôle domaine.
# 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 7034498 : en mode monoutilisateur, la tentative d'ajout d'un CPU virtuel sur un domaine renvoie la valeur d'état 0. La valeur d'état pour cet échec devrait être 1.
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 actif 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 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 et ce, 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 7024499 : si vous utilisez un fichier XML pour lier un domaine avec la commande ldm bind -i xml-file, la liaison est susceptible d'échouer. L'échec est dû à un chemin de moteur de traitement de disque ou de périphérique réseau non valide et ce, même si vous utilisez l'option -f ou -q. La liaison échoue lorsque les deux situations suivantes se vérifient :
Le fichier XML référence un chemin de moteur de traitement de disque ou de périphérique réseau non valide.
Le domaine de service qui prend en charge le chemin non valide est actif et prend en charge ldmad.
Bien que les deux options -f et -q puissent être spécifiées avec la commande bind -i xml-file, ces options sont ignorées.
Solution : Procédez comme suit :
Désactivez temporairement ldmad sur les domaines de service présentant un périphérique ou un moteur de traitement non valide.
# svcadm disable ldoms/agents
Réactivez ldmad sur chaque domaine de service sur lequel vous avez désactivez ldmad après la liaison.
# svcadm enable ldoms/agents
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 : aucune.
ID de bogue 6994984 : utilisez une reconfiguration différée plutôt qu'une reconfiguration dynamique pour supprimer plus de 100 CPU du domaine primary. Utilisez les étapes suivantes :
Utilisez la mld start-reconf principal pour placer l'objet domaine dans retardée mode de reconfiguration.
Le système hôte Partition ses ressources appartenant au domaine contrôle, le cas échéant.
Utilisez la mld annuler-reconf pour annuler la commande opérations à l'étape 2, si nécessaire, et recommencer.
Redémarrez le domaine de contrôle pour appliquer les modifications.
ID de bogue 6994300 : le Logical Domains Manager peut se bloquer sur un système SPARC T3 lors d'opérations de mémoire et parfois d'opérations de migration. Ces opérations échouent.
Ce blocage peut se produire sur toutes les plates-formes T3 qui utilisent un adaptateur NIU (Network Interface Unit, unité d'interface réseau), mais il est confirmé sur les systèmes qui possèdent des cartes d'extension XAUI.
Solution : Appliquez le patch ID 144500-19.
ID de bogues 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 ou 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 principal, 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 principal.
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 6982280 : dans de rares cas en mode élastique, ldmd peut signaler à tort que quelques CPU effectuant des opérations d'E/S sur un domaine invité sont utilisées à 100 %. Ce rapport ldmd contredit l'état actuel du processeur, obtenu en exécutant la commande prsinfo sur le domaine invité.
Solution : définissez le nombre de CPU sur le domaine invité sur 2. Ensuite, rétablissez le nombre d'origine de CPU.
ID de bogue 6981081 : Lorsqu’un CD ou un DVD physique amorçable est exporté en tant que disque virtuel, le CD ou DVD virtuel risque de ne pas être amorçable depuis le domaine invité qui l’utilise. De plus, l’initialisation risque d’échouer avec un message d’erreur similaire au suivant :
{0} ok boot /virtual-devices@100/channel-devices@200/disk@1:f
Boot device: /virtual-devices@100/channel-devices@200/disk@1:f File and args:
Bad magic number in disk label
ERROR: /virtual-devices@100/channel-devices@200/disk@1: Can't open disk label package
ERROR: boot-read fail
Can't open boot device
La survenance de ce problème dépend du type de lecteur CD ou DVD physique installé sur le système.
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 6978843 : Lorsque vous essayez de supprimer dynamiquement des unités cryptographiques, il se peut que le message suivant soit généré :
# ldm set-crypto 0 primary Aug 20 13:02:27 guest1 ncp: WARNING: ncp0: ncp_mau_unconfig: unable to find MAU for cpu 112 Aug 20 13:02:27 guest1 ncp: WARNING: ncp0: ncp_mau_unconfig: unable to find MAU for cpu 104
Solution : Déterminez si des CPU sont défectueuses, et si vous en trouvez, marquez les comme étant en ligne.
# psrinfo # psradm -n 0-127
Utilisez la reconfiguration différée pour supprimer les unités cryptographiques.
# ldm start-reconf primary # ldm set-crypto 0 primary # reboot
ID de bogue 6972633 : Le domaine de service panique si vous effectuez une migration à chaud d’un domaine invité. La machine source concernée par la migration est un serveur SPARC T3-1 doté de la fonctionnalité d’E/S hybrides NIU.
Le problème peut se poser si toutes les conditions suivantes sont réunies :
La machine source est un serveur SPARC T3-1.
Le mode d’E/S hybrides est activé sur le domaine invité.
Une ressource d’E/S hybrides est assignée au domaine invité.
Si le mode d’E/S hybrides est activé sur le domaine invité pour une interface de réseau virtuel, celui-ci indique hybrid dans la colonne MODE, comme suit :
# ldm list -o network ldg1 ... NAME SERVICE ID DEVICE MAC MODE PVID MTU vnet2 niu-vsw@primary 1 network@1 00:14:4f:fa:9e:89 hybrid 1 1500
Toutefois, la ressource d’E/S hybrides est uniquement assignée si la commande suivante présente une sortie sur le domaine invité :
# kstat -p nxge
Solution : effectuez les opérations suivantes :
Procurez-vous la configuration actuelle du périphérique réseau virtuel.
Cette étape permet de garantir que la réassociation de l’interface s’effectue sans erreur.
# ifconfig vnet1
Dissociez l’interface réseau virtuel sur le domaine invité avant de procéder à la migration.
# ifconfig vnet1 unplumb
Effectuez la migration.
Associez l’interface.
# ifconfig vnet1 plumb
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 domaine actif peut échouer s’il exécute une version antérieure au SE Oracle Solaris 10 10/09 et que la CPU portant le plus petit numéro est à l’état hors ligne. L’opération échoue lorsque 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 6912155 : dans certaines configurations prises en charge, lorsque tous les emplacements DIMM ne sont pas renseignés dans une machine, la configuration d'adresse de la mémoire physique est discontinue et peut présenter des ''trous'' d'adresse entre des blocs de mémoire successifs. Pour une telle configuration, la DR de la mémoire n'est pas prise en charge.
Solution : pour reconfigurer la mémoire lorsque la DR de la mémoire n'est pas prise en charge, effectuez la procédure suivante ;
Domaine principal. Utilisez la reconfiguration différée.
Autres domaines. Arrêtez le domaine, effectuez la reconfiguration de la mémoire, puis redémarrez le domaine.
Pour en savoir plus sur la configuration de la mémoire, reportez-vous à la documentation matérielle de votre plate-forme.
ID de bogue 6904849 : À 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 Oracle Solaris OS 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 suivant, 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 Atlas (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 : Évitez d’initialiser plusieurs domaines à la fois. Toutefois, si vous y êtes contraint, évitez d’exécuter d’autres commandes ldm tant que le système ne retourne pas à son état de fonctionnement normal. Par exemple, patientez environ deux minutes sur des serveurs Sun SPARC Enterprise T5140 et T5240 et environ quatre minutes sur le serveur Sun SPARC Enterprise T5440 Server ou Netra T5440.
ID de bogue 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 œuvre 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 nom_domaine, puis une commande ldm start nom_domaine.
Redéfinissez le mode de gestion de l’alimentation sur le mode de performance, arrêtez et redémarrez le domaine invité concerné, puis repassez en mode élastique.
ID de bogue 6846889 : Lorsque vous redémarrez le domaine de contrôle ou un domaine invité, le message d’avertissement suivant peut être consigné dans l’un ou l’autre des domaines redémarrés :
WARNING: ds@0: ds_ldc_cb: LDC READ event while port not up
Solution : Vous pouvez ignorer ce message.
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 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.
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
À 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 nœud 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
Évitez 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.
Évitez 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 :
Procédez comme suit :
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 elle 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 10 8/07 sur un domaine invité servi par un domaine de service exécutant le SE Oracle Solaris 10 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 10 8/07 à l’aide du patch ID 127111-05.
ID de bogue 6697096 : Dans certaines circonstances, lorsque plusieurs opérations ldm set-vcpu sont effectuées sur le domaine de contrôle alors qu’il est en mode de reconfiguration différée, l’exécution de la commande ldmd est abandonnée et redémarrée par SMF (Service Management Facility).
Lorsque le domaine de contrôle est en mode de reconfiguration différée, soyez très attentif à toute opération ldm set-vcpu. Une seule opération ldm set-vcpu sera réussie, mais suite à une seconde opération ldm set-vcpu, le démon ldmd effectuera un core dump.
Solution : Redémarrez le domaine de contrôle après la seconde opération ldm set-vcpu.
ID de bogue 6687634 : Si le volume Solaris Volume Manager est construit sur une tranche de disque contenant le bloc 0 du disque, le gestionnaire empêche l’écriture dans le bloc 0 du volume pour éviter le remplacement de l’étiquette du disque.
Si un volume Solaris Volume Manager, construit sur une tranche de disque contenant le bloc 0 du disque, est exporté en tant que disque virtuel plein, un domaine invité ne parvient pas à écrire une étiquette de disque pour ce disque virtuel. Ainsi, ceci empêche l’installation du Oracle Solaris OS sur ce disque.
Solution : Les volumes Solaris Volume Manager exportés en tant que disque virtuel ne doivent pas être construits sur une tranche de disque contenant le bloc 0 du disque.
À titre de consigne plus générale, les tranches qui commencent par le premier bloc (bloc 0) d’un disque physique ne doivent pas être exportées (soit directement soit indirectement) en tant que disque virtuel. Reportez-vous à la section Exportation directe ou indirecte d’une tranche de disque du Guide d’administration d’Oracle VM Server for SPARC 2.1.
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 6629230 : La commande scadm d’un domaine de contrôle exécutant le système d’exploitation Solaris 10 11/06 ou ultérieur peut se bloquer à la suite d’une réinitialisation de contrôleur système. Le système ne parvient pas à rétablir correctement une connexion après une réinitialisation de contrôleur système.
Solution : Réinitialisez l’hôte pour rétablir la connexion avec le contrôleur système.
Reprise : Réinitialisez l’hôte pour rétablir la connexion avec le contrôleur système.
ID de bogue 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 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 etip_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 panne de CPU ou de mémoire se produit, le domaine concerné risque de paniquer et de redémarrer. 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 présente la ressource comme étant à l’état d’exclusion sélective.
Reprise : Attendez que le domaine redémarre, puis forcez FMA à réexécuter l’événement de panne en relançant le démon du gestionnaire de pannes (fmd) sur le domaine de contrôle à l’aide de la commande suivante :
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 Oracle Solaris OS à l’aide de la commande ickey(1M) ne sont pas prises en charge. Toutes les opérations ickey échoue 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
ID de bogue 6497796 : Dans de rares cas, lorsqu’une variable Logical Domains telle que boot-device est mise à jour à partir d’un domaine invité au moyen de la commande eeprom(1M) en même temps que des CPU virtuelles sont ajoutées ou supprimées sur le même domaine à l’aide du Logical Domains Manager, le SE invité peut se bloquer.
Solution : Assurez-vous que ces deux opérations ne sont pas effectuées simultanément.
Reprise : Exécutez les commandes ldm stop-domain et ldm start-domain pour arrêter et démarrer le SE invité.
ID de bogue 6493140 : Il se peut que Oracle Solaris OS soit incapable d’utiliser la reconfiguration dynamique pour supprimer toutes les CPU demandées. Dans ce cas, des messages d’erreur similaires aux suivants s’affichent :
Removal of cpu 10 failed
Reprise : Exécutez une nouvelle demande pour supprimer le nombre de CPU qui n’ont pas pu être supprimées la première fois. En principe, cette nouvelle demande réussit.
Cette section décrit les erreurs de documentation détectées trop tard pour pouvoir être corrigées dans cette version d’Oracle VM Server for SPARC 2.1.
La section Compatibilité logicielle du manuel Oracle VM Server for SPARC 2.1 Administration Guide fait une référence erronée aux informations concernant la configuration requise pour les fonctionnalités les plus récentes. A la place, reportez-vous à Conditions préalables à la migration de domaine en direct.
La description indique que la commande ldm stop envoie une demande d'arrêt alors qu'elle émet en réalité un appel système uadmin().
Pour procéder à un arrêt en douceur, réalisez une opération shutdown ou init dans le domaine concerné. Reportez-vous à la page de manuel shutdown(1M) ou init(1M).
Le nom du package Logical Domains Manager à installer est SUNWldm.v. Toute commande pkgadd figurant dans la documentation de Oracle VM Server for SPARC 2.1 doit faire référence au package nommé SUNWldm.v.
La commande de synopsis ILOM load figurant à la section Mise à niveau du microprogramme du système du Guide d’administration d’Oracle VM Server for SPARC 2.1 contient un backslash (\) pour indiquer que la commande entière doit figurer sur une seule et même ligne.
Lorsque vous spécifiez cette commande, n'insérez pas de backslash, et vérifiez que la commande entière tient sur une seule ligne.
|