Ignorer les liens de navigation | |
Quitter la vue de l'impression | |
Notes de produit d'Oracle® VM Server for SPARC 3.1.1.2, 3.1.1.1, 3.1.1 et 3.1 |
Utilisation de cette documentation
Chapitre 1 Notes de version d'Oracle VM Server for SPARC 3.1.1.2, 3.1.1.1, 3.1.1 et 3.1
Mise à jour de maintenance d'Oracle VM Server for SPARC 3.1.1.2
Mise à jour de maintenance d'Oracle VM Server for SPARC 3.1.1.1
Nouveautés de la mise à jour de maintenance d'Oracle VM Server for SPARC 3.1.1.1
Nouveautés d'Oracle VM Server for SPARC 3.1.1
Nouveautés d'Oracle VM Server for SPARC 3.1
Plates-formes prises en charge
Versions du SE Oracle Solaris requises
Versions du SE Oracle Solaris requises pour Oracle VM Server for SPARC 3.1.1
Versions du SE Oracle Solaris requises pour Oracle VM Server for SPARC 3.1
Logiciels requis pour activer les dernières fonctionnalités d'Oracle VM Server for SPARC
Patchs du microprogramme système requis
Version logicielle minimale requise
Configuration matérielle et logicielle requise pour les E/S directes
Configuration matérielle et logicielle SR-IOV PCIe
Configuration logicielle et matérielle requise pour les domaines root non primary
Configuration matérielle et logicielle requise pour le mode de récupération
Emplacement du logiciel Oracle VM Server for SPARC
Emplacement de la documentation
Logiciels compatibles avec le logiciel Oracle VM Server for SPARC
Logiciels de contrôleur système utilisés avec Oracle VM Server for SPARC
Mise à niveau vers le logiciel Oracle VM Server for SPARC actuel
Mise à niveau vers le logiciel Oracle VM Server for SPARC 3.1.1.1
Mise à niveau vers le logiciel Oracle VM Server for SPARC 3.1.1
Mise à niveau vers le logiciel Oracle VM Server for SPARC 3.1
Fonctionnalités Oracle VM Server for SPARC en phase d'abandon
Impossible de dissocier des domaines lorsqu'ils se fournissent mutuellement des services
Impossible pour un domaine d'exécuter le SE Oracle Solaris 10 si plus de 1 024 CPU sont associés
Eviter la création d'une configuration où deux domaines se fournissent mutuellement des services
Mise à niveau à partir d'un SE Oracle Solaris 10 antérieur au SE Oracle Solaris 10 5/08
Les termes Processeur de service et Contrôleur système sont utilisés de manière interchangeable
Détection de la configuration ou des métapériphériques Solaris Volume Manager d'un domaine invité
Initialisation d'un grand nombre de domaines
Arrêt correct et cycle d'alimentation d'un système Oracle VM Server for SPARC
Mise hors tension d'un système comportant plusieurs domaines actifs
Arrêt et redémarrage du système
Taille de la mémoire requise différente de la mémoire allouée
Persistance des variables Logical Domains
Sun SNMP Management Agent d'Oracle ne prend pas en charge plusieurs domaines
Commande ldmp2v convert : des messages d'avertissement VxVM durant une initialisation
Configuration requise pour le partitionnement forcé Oracle des licences logicielles
Option de mise à niveau absente lors de l'utilisation de ldmp2v prepare -R
ldmp2v : la méthode d'archivage ufsdump n'est plus utilisée avec cette commande
Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée
Restrictions de la migration de domaine
Restrictions de version pour la migration
Restrictions de la CPU pour la migration
Restrictions applicables aux versions pour la migration entre CPU
Problèmes liés à Oracle VM Server for SPARC MIB
La commande snmptable ne fonctionne pas avec l'option Version 2 ou Version 3
Blocage du domaine de contrôle lors de l'arrêt ou du démarrage de domaines d'E/S
Affichage d'avertissements sur la console lors de la création de fonctions virtuelles Fibre Channel
La modification de la configuration des fonctions physiques de Fibre Channel prend quelques minutes
Les restrictions de la fonction SR-IOV du Système Fujitsu M10 sont différentes
Problèmes liés à SR-IOV InfiniBand
Affichage de messages induisant en erreur pour les opérations SR-IOV InfiniBand
Bogues liés au logiciel Oracle VM Server for SPARC
Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1.2
Panne système lors de l'application de la contrainte whole-core à un domaine primary à coeur partiel
Les zones de noyau bloquent la migration en direct des domaines hôtes
Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1.1
Le Logical Domains Manager n'empêche pas la création de dépendances circulaires
Bogues liés au logiciel Oracle VM Server for SPARC 3.1.1
La fonction physique Fibre Channel est défaillante et désactivée par FMA
Chemin de périphérique incorrect pour les fonctions virtuelles Fibre Channel dans un domaine root
Bogues liés au logiciel Oracle VM Server for SPARC 3.1
Des problèmes peuvent survenir lorsque l'architecture FMA détecte de la mémoire défectueuse
La taille du tampon de description de la machine préallouée est utilisée lors de la migration
Un blocage du réseau virtuel empêche la migration de domaine
La sortie ldmpower n'inclut pas toujours les horodatages
mac_do_softlso abandonne les paquets LSO
Echec de la migration : Invalid Shutdown-group: 0
L'échec de la commande ldmp2v convert provoque une mise à niveau en boucle
Panique de domaine invité à lgrp_lineage_add(mutex_enter: bad mutex, lp=10351178)
Domaines invités en état de transition après la réinitialisation du domaine primary
ldm list n'affiche pas la propriété evacuated pour les périphériques d'E/S physiques
Une adresse physique non valide est reçue pendant la migration d'un domaine
Des sous-périphériques subordonnés à un périphérique PCIe retournent à l'état
SPARC M5-32 et SPARC M6-32 : panic: mpo_cpu_add: Cannot read MD
SPARC M5-32 et SPARC M6-32 : le contrôleur LSI-SAS est exporté de façon incorrecte avec SR-IOV
Deux propriétés sont manquantes dans la sortie ldm list-io -d d'un périphérique sxge sur SPARC T5-1B
ldm ne parvient pas à évacuer un coeur défectueux d'un domaine invité
La reconfiguration dynamique de CPU d'un très grand nombre de CPU virtuelles peut échouer
SPARCT4-4 : impossible d'associer un domaine invité
Panique du domaine invité lorsque la propriété threading est modifiée de max-throughput à max-ipc
Le domaine de contrôle se bloque lors d'une réinitialisation avec deux domaines d'E/S directs actifs
Echec de la recréation d'un domaine avec des fonctions virtuelles PCIe à partir d'un fichier XML
La commande ldm list -o n'accepte plus les abréviations pour format
Domaine de contrôle nécessitant le coeur le plus bas du système
Non-réactivité des commandes ldm exécutées sur le système cible après annulation d'une migration
Non-fonctionnement de certaines cartes Emulex lorsqu'elles sont assignées à un domaine d'E/S
Oracle Solaris 11 : signalement d'usurpation et d'échec RD Oracle Solaris par les DRM
Limitation du nombre maximum de fonctions virtuelles qu'il est possible d'affecter à un domaine
La console de domaine invité se bloque de manière aléatoire sur les systèmes SPARC T4
Désactivation conseillée de l'option ldm remove-io des cartes PCIe possédant des ponts PCIe vers PCI
Echec probable de la commande ldm stop en cas d'émission immédiatement après une commande ldm start
Echec de l'autorisation des transitions DR whole-core par le coeur partiel primary
Affichage de l'état UNK ou INV par la commande ldm list-io après l'initialisation
Echec de la suppression d'un grand nombre de CPU d'un domaine invité
Un interblocage de noyau provoque le blocage de la machine pendant une migration
Echec de délai d'attente de CPU virtuelles lors de la reconfiguration dynamique
Des opérations de migration simultanées dans des
Echec de la suppression d'un grand nombre de CPU d'un domaine de contrôle
SPARC T3-1 : problème lié aux disques accessibles via plusieurs chemins d'E/S directes
Une adresse MAC en cours d'utilisation peut être réaffectée
Impossible de créer une configuration de domaine sur le processeur de service pour ldmconfig
La migration non coopérative de domaines Oracle Solaris peut se bloquer si cpu0 est hors ligne
La reconfiguration dynamique de la mémoire est désactivée à la suite de l'annulation d'une migration
Echec possible de la reconfiguration dynamique des valeurs MTU de périphériques réseau virtuel
La suppression dynamique de toutes les unités cryptographiques d'un domaine entraîne l'arrêt de SSH
ldm : ces commandes mettent beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés
Panique possible du domaine d'E/S ou du domaine invité lors d'une initialisation à partir de e1000g
Les liaisons de groupe de consoles et de port explicites ne sont pas migrées
La migration n'échoue pas si un vdsdev a un moteur de traitement différent sur la cible
Impossible de se connecter à la console d'un domaine migré sauf si le service vntsd est redémarré
Logical Domains Manager met parfois plus de 15 minutes pour arrêter un domaine
Impossible de définir des clés de sécurité durant l'exécution de Logical Domains
Le comportement de la commande ldm stop-domain n'est pas toujours très clair
Problèmes identifiés dans la documentation
ldm1M Page de manuel : Décrire les restrictions d'utilisation de la propriété mblock
ldm1M Page de manuel : Améliorer la description de la commande ldm list -o status
Page de manuel ldm1M : seule la commande ldm add-spconfig -r permet d'effectuer une reprise manuelle
Problèmes résolus dans la version 3.1.1.2 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1.1.1 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1.1 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1.0.1 d'Oracle VM Server for SPARC
Problèmes résolus dans la version 3.1 d'Oracle VM Server for SPARC
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.
Ne créez pas de dépendance circulaire entre deux domaines où chaque domaine fournit des services à l'autre. Une telle configuration crée une condition de point de panne unique où une interruption de service dans un domaine entraîne l'indisponibilité de l'autre domaine. Les configurations de dépendance circulaire vous empêchent également de dissocier les domaines suite à leur association initiale.
Le Logical Domains Manager n'empêche pas la création de dépendances de domaines circulaires.
S'il est impossible de dissocier les domaines en raison d'une dépendance circulaire, retirez les périphériques causant la dépendance puis tentez de dissocier les domaines.
Un domaine invité associé à plus de 1 024 CPU ne peut pas exécuter le SE Oracle Solaris 10. De plus, vous ne pouvez pas utiliser la reconfiguration dynamique de CPU pour définir un nombre de CPU inférieur à 1 024 pour exécuter le SE Oracle Solaris 10.
Pour contourner ce problème, dissociez le domaine invité, retirez les CPU jusqu'à ce que vous n'en ayez plus que 1 024, pour associez à nouveau le domaine invité. Vous pourrez ensuite exécuter le SE Oracle Solaris 10 sur ce domaine invité.
Evitez de créer une configuration où deux domaines se fournissent mutuellement des services. Si tel est le cas, une interruption de service dans un domaine met hors service l'autre domaine. De plus, de tels domaines ne peuvent pas être dissociés s'ils sont associés avec une configuration de ce type. Actuellement, Logical Domains Manager ne bloque pas de telles dépendances circulaires.
Si vous ne pouvez pas dissocier un domaine à cause de ce type de dépendance, supprimez les périphériques qui provoquent des dépendances circulaires puis tentez une nouvelle opération de dissociation.
Si le domaine de contrôle est mis à niveau à partir d'une version du SE Oracle Solaris 10 antérieure au SE Oracle Solaris 10 5/08 (ou sans le patch 127127-11) et si les volumes du gestionnaire de volumes ont été exportés en tant que disques virtuels, les moteurs de traitement des disques virtuels doivent être ré-exportés avec options=slice après la mise à niveau du Logical Domains Manager. Reportez-vous à la section Exportation de volumes et rétrocompatibilité du Guide d'administration d'Oracle VM Server for SPARC 3.1 .
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 à SE Oracle Solaris 10 1/13 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 SE Oracle Solaris 10 1/13, la tranche de disque physique exportée sous forme de disque virtuel est présentée sur le domaine invité sans ID de périphérique.
L'absence d'ID de périphérique pour le disque virtuel peut être à l'origine de problèmes au niveau des applications qui tentent de référencer l'ID de périphérique de disques virtuels. En particulier, Solaris Volume Manager risque de ne plus pouvoir détecter sa configuration ou d'accéder à ses métapériphériques.
Solution de contournement : après avoir mis à niveau un domaine de service vers SE Oracle Solaris 10 1/13, si un domaine invité ne parvient pas à détecter sa configuration ou ses métapériphériques Solaris Volume Manager, effectuez la procédure suivante.
md_devid_destroy=1; md_keep_repl_state=1;
Après l'initialisation du domaine, la configuration et les métapériphériques de Solaris Volume Manager devraient être disponibles.
Lors de la réinitialisation, des messages semblables aux suivants s'affichent
NOTICE: mddb: unable to get devid for 'vdc', 0x10
Il n'y a rien d'anormal à cela dans la mesure où aucun problème n'est signalé.
Le logiciel Oracle VM Server for SPARC n'impose aucune limitation de taille pour la mémoire lors de la création d'un domaine. La taille de la mémoire requise est une caractéristique du système d'exploitation hôte. Certaines fonctions d'Oracle VM Server for SPARC risquent de ne pas fonctionner si la quantité de mémoire présente est inférieure à la taille recommandée. Pour le SE Oracle Solaris 10, reportez-vous à la section Configuration système requise et recommandations du Guide d'installation d'Oracle Solaris 10 8/11 : Planification d'installation et de mise à niveau . Pour connaître la configuration système requise et les recommandations pour le SE Oracle Solaris 11, reportez-vous aux sections Oracle Solaris 11 Release Notes et Oracle Solaris 11.1 Release Notes .
La PROM OpenBoot a une contrainte de taille minimale pour un domaine. Actuellement, cette limite est de 12 méga-octets. Si vous avez un domaine dont la taille est inférieure, Logical Domains Manager étend automatiquement celui-ci à 12 Mo. La taille minimale d'un Système Fujitsu M10 est limitée à 256 Mo. Reportez-vous aux notes de version de votre microprogramme système pour connaître la taille de la mémoire requise
La fonction de reconfiguration dynamique (DR) de la mémoire applique un alignement de 256 Mo sur l'adresse et la taille de la mémoire impliquées dans une opération donnée. Reportez-vous à la section Alignement de la mémoire du Guide d'administration d'Oracle VM Server for SPARC 3.1 .
Vous pouvez initialiser le nombre de domaines suivants en fonction de votre plate-forme
Jusqu'à 256 sur les Systèmes Fujitsu M10 par partition physique
Jusqu'à 128 sur les systèmes SPARC M6 par domaine physique
Jusqu'à 128 sur les systèmes SPARC M5 par domaine physique
Jusqu'à 128 sur les systèmes SPARC T5
Jusqu'à 128 sur les serveurs SPARC T4
Jusqu'à 128 sur les serveurs SPARC T3
Jusqu'à 128 sur les serveurs UltraSPARC T2 Plus
Jusqu'à 64 sur les serveurs UltraSPARC T2
Si des CPU virtuelles non allouées sont disponibles, assignez-les au domaine de service afin de contribuer au traitement des demandes d'E/S virtuelles. Attribuez 4 à 8 CPU virtuelles au domaine de service si vous créez plus de 32 domaines. Dans les cas où les configurations de domaines maximales ne disposent que d'une CPU dans le domaine de service, ne placez pas une contrainte inutile sur cette CPU lors de la configuration et de l'utilisation du domaine. Les services de commutateur virtuel (vsw) doivent être répartis sur l'ensemble des adaptateurs réseau disponibles dans la machine. Par exemple, si vous initialisez 128 domaines sur un serveur Sun SPARC Enterprise T5240, créez quatre services vsw, chacun servant 32 instances réseau virtuelles (vnet). L'attribution de plus de 32 instances vnet par service vsw peut entraîner un blocage forcé du domaine du service.
Pour exécuter les configurations maximales, une machine nécessite une quantité de mémoire suffisante pour prendre en charge les domaines invités. La quantité de mémoire dépend de votre plate-forme et de votre SE. Reportez-vous à la documentation relative à votre plate-forme, Oracle Solaris 10 8/11 Installation Guide: Planning for Installation and Upgrade , Installing Oracle Solaris 11 Systems et Installing Oracle Solaris 11.1 Systems .
La mémoire libre et l'espace de swap utilisés dans un domaine invité augmentent lorsque les services vsw utilisés par le domaine fournissent des services à de nombreux réseaux virtuels (dans plusieurs domaines). Ceci est dû aux liaisons de poste à poste entre toutes les instances vnet connectées à vsw. Le domaine de service bénéficie d'une quantité de mémoire supplémentaire. La valeur minimale recommandée est 4 Go lorsque vous exécutez plus de 64 domaines. Démarrez les domaines par groupe de 10 ou moins et attendez qu'ils s'initialisent avant de démarrer le lot suivant. Ce conseil est également valable pour les systèmes d'exploitation des domaines. Vous pouvez réduire le nombre de liaisons en désactivant les liens inter-vnet. Reportez-vous à la section Canaux LDC Inter-Vnet du Guide d'administration d'Oracle VM Server for SPARC 3.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 d'effectuer un cycle d'alimentation d'un système Oracle VM Server for SPARC, veillez à enregistrer la dernière configuration que vous souhaitez conserver.
Puisqu'aucun autre domaine n'est lié, le microprogramme met automatiquement le système hors tension.
Puisqu'aucun autre domaine n'est lié, le microprogramme effectue automatiquement un cycle d'alimentation du système avant de le réinitialiser. Lorsque le système redémarre, il initialise la dernière configuration de domaine enregistrée ou explicitement définie.
Dans certaines circonstances, Logical Domains Manager arrondit l'allocation de mémoire requise au multiple supérieur suivant de 8 kilo-octets ou 4 mégaoctets. L'exemple suivant présente une sortie de la commande ldm list-domain -l, où la valeur de contrainte est inférieure à la taille réelle allouée :
Memory: Constraints: 1965 M raddr paddr5 size 0x1000000 0x291000000 1968M
Les mises à jour de variables persistent après la réinitialisation du domaine, mais pas après un cycle d'alimentation du système, à moins qu'elles ne soient lancées à partir du microprogramme OpenBoot sur le domaine de contrôle ou suivies de l'enregistrement de la configuration sur le contrôleur système.
Prenez note des conditions suivantes :
Lorsque le domaine de contrôle se réinitialise, si aucun domaine invité n'est lié et qu'aucune reconfiguration retardée n'est en cours, le contrôleur système effectue un cycle d'alimentation du système.
Lorsque le domaine de contrôle se réinitialise, si des domaines invités sont liés ou actifs (ou si le domaine de contrôle est en pleine reconfiguration retardée), le contrôleur système n'effectue pas de cycle d'alimentation du système.
Les variables Logical Domains d'un domaine peuvent être spécifiées en suivant l'une des méthodes suivantes :
A l'invite OpenBoot.
A l'aide de la commande SE Oracle Solaris eeprom(1M).
A l'aide de la CLI Logical Domains Manager (ldm).
De manière limitée, à partir du contrôleur système (SC) à l'aide de la commande bootmode. Cette méthode ne peut être utilisée que pour certaines variables et uniquement dans la configuration factory-default.
Les mises à jour de variables effectuées à l'aide de l'une de ces méthodes doivent toujours persister après les réinitialisations du domaine. Les mises à jour de variables s'appliquent toujours dans toutes les configurations de domaine ultérieures enregistrées sur le contrôleur système.
Dans le logiciel Oracle VM Server for SPARC 3.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 toutes les réinitialisations de ce domaine. Toutefois, elles ne persistent pas après un cycle d'alimentation du système, sauf si une configuration de domaine logique ultérieure est enregistrée sur le contrôleur système.
Toutefois, sur le domaine de contrôle, les mises à jour effectuées en utilisant les commandes du microprogramme OpenBoot ou la commande eeprom persistent après un cycle d'alimentation du système, et ce, même sans enregistrer par la suite une nouvelle configuration de domaine logique sur le SC. La commande eeprom prend en charge ce comportement sur les systèmes SPARC T5, SPARC M5 et SPARC M6, ainsi que sur les systèmes SPARC T3 et SPARC T4 exécutant au moins la version 8.2.1 du microprogramme système.
Dans tous les cas, lors du rétablissement de la configuration usine par défaut à partir d'une configuration générée par Logical Domains Manager, toutes les variables Logical Domains reprennent au départ leurs valeurs par défaut.
Si vous craignez que les variables Logical Domains changent, procédez de l'une des manières suivantes :
Accédez à l'invite ok du système et mettez à jour les variables.
Mettez à jour les variables pendant que Logical Domains Manager est désactivé :
# svcadm disable ldmd update variables # svcadm enable ldmd
Si vous exécutez Live Upgrade, effectuez les opérations suivantes :
# svcadm disable -t ldmd # luactivate be3 # init 6
Si vous modifiez l'heure ou la date sur un domaine logique, par exemple en utilisant la commande ntpdate, le changement persiste après toutes les réinitialisations du domaine, mais pas après un cycle d'alimentation de l'hôte. Pour que les changements de date et d'heure persistent, enregistrez la configuration avec le changement en question sur le contrôleur système et initialisez à partir de cette configuration.
Les ID de bogue suivants ont été créés pour résoudre ces problèmes : 15375997, 15387338, 15387606 et 15415199.
Sun SNMP (Simple Network Management Protocol) Management Agent ne prend pas en charge plusieurs domaines. Seul un domaine global est pris en charge.
Lorsqu'un domaine primary est en état de reconfiguration retardée, l'alimentation des ressources gérées par Oracle VM Server for SPARC est uniquement gérée après la réinitialisation du domaine primary. Les ressources gérées directement par le SE, telles que les CPU gérés par le Power Aware Dispatcher Solaris ne sont pas affectées par cet état.
Les unités cryptographiques discrètes sont uniquement présentes sur les systèmes UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3.
La reconfiguration dynamique des unités cryptographiques vous permet d'ajouter ou de supprimer des unités cryptographiques d'un domaine. Logical Domains Manager détecte automatiquement si un domaine permet la reconfiguration dynamique des unités cryptographiques et active la fonctionnalité pour ce domaine uniquement. De plus, la reconfiguration dynamique des CPU n'est plus désactivée dans les domaines dont des unités cryptographiques sont liées et exécutent une version appropriée du SE Oracle Solaris.
L'exécution de Veritas Volume Manager (VxVM) 5.x sur le SE Oracle Solaris 10 est la seule version prise en charge (testée) pour l'outil Oracle VM Server for SPARC P2V. Les versions antérieures de VxVM, comme 3.x et 4.x exécutées sur les systèmes d'exploitation Solaris 8 et Solaris 9 peuvent également fonctionner. Dans ces cas, la première initialisation après avoir exécuté la commande ldmp2v convert peut engendrer des messages d'avertissement concernant les pilotes VxVM. Vous pouvez ignorer ces messages. Vous pouvez supprimer les anciens packages VRTS* après l'initialisation du domaine invité.
Boot device: disk0:a File and args: SunOS Release 5.10 Version Generic_139555-08 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: normaal Configuring devices. /kernel/drv/sparcv9/vxdmp: undefined symbol 'romp' WARNING: mod_load: cannot load module 'vxdmp' WARNING: vxdmp: unable to resolve dependency, module 'misc/ted' not found /kernel/drv/sparcv9/vxdmp: undefined symbol 'romp' WARNING: mod_load: cannot load module 'vxdmp' WARNING: vxdmp: unable to resolve dependency, module 'misc/ted' not found /kernel/drv/sparcv9/vxio: undefined symbol 'romp' WARNING: mod_load: cannot load module 'vxio' WARNING: vxio: unable to resolve dependency, module 'drv/vxdmp' not found WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER NOTICE: VxVM not started
Pour plus d'informations sur les conditions requises pour le partitionnement forcé des licences Oracle, reportez-vous à la section Partitionnement : partitionnement du serveur/matériel.
Le programme d'installation Oracle Solaris ne comporte pas l'option de mise à niveau lorsque le repère de partition de la tranche sur laquelle réside le système de fichiers root (/) n'est pas défini sur root. Cette situation se produit si le repère n'est pas défini de manière explicite lors de l'étiquetage du disque d'initialisation de l'invité. Vous pouvez utiliser la commande format pour définir le repère de partition comme suit
AVAILABLE DISK SELECTIONS: 0. c0d0 <SUN-DiskImage-10GB cyl 282 alt 2 hd 96 sec 768> /virtual-devices@100/channel-devices@200/disk@0 1. c4t2d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> /pci@400/pci@0/pci@1/scsi@0/sd@2,0 2. c4t3d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> /pci@400/pci@0/pci@1/scsi@0/sd@3,0 Specify disk (enter its number)[0]: 0 selecting c0d0 [disk formatted, no defect list found] format> p PARTITION MENU: 0 - change `0' partition 1 - change `1' partition 2 - change `2' partition 3 - change `3' partition 4 - change `4' partition 5 - change `5' partition 6 - change `6' partition 7 - change `7' partition select - select a predefined table modify - modify a predefined partition table name - name the current table print - display the current table label - write partition map and label to the disk !<cmd> - execute <cmd>, then return quit partition> 0 Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 0 (0/0/0) 0 Enter partition id tag[unassigned]: root Enter partition permission flags[wm]: Enter new starting cyl[0]: 0 Enter partition size[0b, 0c, 0e, 0.00mb, 0.00gb]: 8g partition> label Ready to label disk, continue? y partition>
En raison de la manière dont le SE Oracle Solaris traite les métadonnées pour la gestion de la mémoire ajoutée de manière dynamique, vous pourrez peut-être uniquement supprimer le bloc de mémoire entier qui a été précédemment ajouté de manière dynamique plutôt qu'un sous-ensemble correct de cette mémoire.
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.
primary# ldm list ldom1 NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldom1 active -n-- 5000 2 2G 0.4% 23h primary# ldm add-mem 16G ldom1 primary# ldm rm-mem 8G ldom1 Memory removal failed because all of the memory is in use. primary# ldm rm-mem 16G ldom1 primary# ldm list ldom1 NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldom1 active -n-- 5000 2 2G 0.4% 23h
Solution de contournement : utilisez la commande ldm add-mem pour ajouter de la mémoire de manière séquentielle par blocs de petite taille plutôt que par blocs de plus grande taille que vous pourriez souhaiter supprimer à l'avenir.
Récupération : effectuez l'une des actions suivantes :
Arrêtez le domaine, supprimez la mémoire, puis redémarrez le domaine.
Réinitialisez le domaine, ce qui provoque la réallocation des métadonnées de gestion de la mémoire du SE Oracle Solaris de telle sorte que la mémoire ajoutée précédemment peut maintenant être supprimée de manière dynamique par blocs de plus petite taille.
La restauration des archives ufsdump sur un disque virtuel soutenu par un fichier sur un système de fichiers UFS risque de provoquer le blocage du système. Dans ce cas, la commande ldmp2v prepare se ferme. Il est possible que vous rencontriez ce problème si vous restaurez manuellement des archives ufsdump pour préparer la commande ldmp2v prepare -R /altroot lorsque le disque virtuel est un fichier sur un système de fichiers UFS. En raison de la compatibilité avec les archives ufsdump crées précédemment, vous pouvez toujours utiliser la commande ldmp2v prepare pour restaurer des archives ufsdump sur les disques virtuels qui ne sont pas soutenus par un fichier sur un système de fichiers UFS. Toutefois, l'utilisation des archives ufsdump n'est pas recommandée.
N'essayez pas d'exécuter plusieurs opérations de configuration de CPU sur le domaine primary alors que sa reconfiguration est retardée. Si vous tentez d'effectuer plusieurs demandes de configuration de CPU, celles-ci seront rejetées.
Solution de contournement : effectuez l'une des opérations suivantes
Annulez la reconfiguration retardée, lancez-en une autre, puis demandez les modifications de configuration perdues de la dernière reconfiguration retardée.
Réinitialisez le domaine de contrôle à l'aide du nombre erroné de CPU et effectuez les corrections d'allocation nécessaires après la réinitialisation du domaine.
Le logiciel Oracle VM Server for SPARC 3.0 offre par inadvertance la possibilité d'assigner plusieurs commutateurs virtuels à un même adaptateur réseau. Cette possibilité n'est destinée qu'à être utilisée sous certaines conditions par le logiciel Oracle VM Manager.
Le logiciel Oracle VM Server for SPARC 3.1 a rétabli le comportement d'origine, qui n'autorise pas l'assignation de plusieurs commutateurs virtuels à un seul adaptateur réseau. Toutefois, si vous avez configuré votre système Oracle VM Server for SPARC 3.0 de manière à ce qu'il assigne plusieurs commutateurs virtuels à un seul adaptateur réseau, le démon ldmd ne démarre pas lorsque vous effectuez la mise à niveau vers Oracle VM Server for SPARC 3.1.
Solution de contournement : effectuez les opérations suivantes :
Réactivez temporairement cette possibilité sur votre système Oracle VM Server for SPARC 3.1 pour permettre au démon ldmd de démarrer.
# svccfg -s ldoms/ldmd setprop ldmd/ovm_manager=true # svcadm refresh ldmd # svcadm disable ldmd # svcadm enable ldmd
Mettez à jour la configuration de votre système de manière à ce qu'elle n'autorise l'affectation que d'un seul commutateur virtuel à un périphérique réseau.
Désactivez cette possibilité sur votre système Oracle VM Server for SPARC 3.1.
# svccfg -s ldoms/ldmd setprop ldmd/ovm_manager=false # svcadm refresh ldmd # svcadm disable ldmd # svcadm enable ldmd
Il est primordial que vous affectiez la valeur false à la propriété ovm_manager, car cette propriété pourrait avoir d'autres effets secondaires dans les prochaines versions d'Oracle VM Server for SPARC.
Par le passé, le SE Oracle Solaris était installé sur un disque d'initialisation configuré avec une étiquette de disque VTOC SMI. A partir du SE Oracle Solaris 11.1, le SE est installé sur un disque d'initialisation configuré par défaut avec une étiquette GPT (GUID partition table, table de partition GUID) de type EFI (Extensible Firmware Interface). Si le microprogramme ne prend pas en charge EFI, le disque est configuré avec une étiquette de disque VTOC SMI. Cette situation concerne uniquement les serveurs SPARC T4 exécutant au moins le microprogramme système 8.4.0, les serveurs SPARC T5, SPARC M5 ou SPARC M6 exécutant au moins la version 9.1.0 du microprogramme système et les Systèmes Fujitsu M10 exécutant au moins XCP2230.
Les serveurs suivants ne peuvent pas s'initialiser à partir d'un disque possédant une étiquette de disque GPT EFI :
Serveurs UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3, quelle que soit la version du microprogramme système utilisée
Serveurs SPARC T4 exécutant des versions du microprogramme système antérieures à la version 8.4.0
Serveurs SPARC T5, SPARC M5 et SPARC M6 exécutant des versions du microprogramme système antérieures à la version 9.1.0
Systèmes Fujitsu M10 exécutant des versions XCP antérieures à 2230
Ainsi, un disque d'initialisation Oracle Solaris 11.1 créé sur un système SPARC T4, SPARC T5, SPARC M5, SPARC M6 ou un Système Fujitsu M10 ne peut pas être utilisé sur un serveur plus ancien ou sur un serveur exécutant un microprogramme plus ancien.
Cette restriction réduit les possibilités d'effectuer des migrations à froid ou des migrations directes pour déplacer un domaine d'un serveur récent vers un serveur plus ancien. Cette restriction vous empêche également d'utiliser une image de disque d'initialisation GPT EFI sur un ancien serveur.
Pour déterminer si un disque d'initialisation Oracle Solaris 11.1 est compatible avec votre serveur et le microprogramme dont celui-ci est équipé, assurez-vous que le SE Oracle Solaris 11.1 est installé sur un disque configuré avec une étiquette de disque VTOC SMI.
Pour assurer la rétrocompatibilité avec les systèmes exécutant des microprogrammes plus anciens, effectuez l'une des procédures ci-après. Sinon, le disque d'initialisation utilise par défaut l'étiquette de disque GPT EFI. Ces procédures indiquent comment s'assurer que le SE Oracle Solaris 11.1 est installé sur un disque d'initialisation avec étiquette de disque VTOC SMI sur un serveur SPARC T4 équipé au minimum de la version 8.4.0 du microprogramme système, sur un serveur SPARC T5, SPARC M5 ou SPARC M6 équipé au minimum de la version 9.1.0 du microprogramme système et sur un Système Fujitsu M10 équipé au minimum de la version 2230 de XCP.
Solution 1 : retirez la propriété gpt de manière à ce que le microprogramme ne signale pas qu'il prend en charge EFI.
A partir de l'invite d'OpenBoot PROM, désactivez l'initialisation automatique et réinitialisez le système à installer.
ok setenv auto-boot? false ok reset-all
Après la réinitialisation du système, il revient à l'invite ok.
Accédez au répertoire /packages/disk-label et supprimez la propriété gpt.
ok cd /packages/disk-label ok " gpt" delete-property
Débutez l'installation du SE Oracle Solaris 11.1.
Effectuez par exemple une initialisation réseau :
ok boot net - install
Solution 2 : servez-vous de la commande format -e pour écrire une étiquette VTOC SMI sur le disque sur lequel installer le SE Oracle Solaris 11.1.
Ecrivez une étiquette VTOC SMI sur le disque.
Sélectionnez par exemple l'option label et spécifiez l'étiquette SMI :
# format -e c1d0 format> label [0] SMI Label [1] EFI Label Specify Label type[1]: 0
Configurez le disque avec une tranche 0 et une tranche 2 couvrant la totalité du disque.
Le disque ne doit pas comporter d'autres partitions. Par exemple :
format> partition partition> print Current partition table (unnamed): Total disk cylinders available: 14087 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 14086 136.71GB (14087/0/0) 286698624 1 unassigned wu 0 0 (0/0/0) 0 2 backup wu 0 - 14086 136.71GB (14087/0/0) 286698624 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0
Réécrivez l'étiquette de disque VTOC SMI.
partition> label [0] SMI Label [1] EFI Label Specify Label type[0]: 0 Ready to label disk, continue? y
Configurez le programme d'installation automatisée (AI) Oracle Solaris de manière à ce qu'il installe le SE Oracle Solaris sur la tranche 0 du disque d'initialisation.
Modifiez comme indiqué ci-dessous la section <disk> du manifeste AI :
<target> <disk whole_disk="true"> <disk_keyword key="boot_disk"/> <slice name="0" in_zpool="rpool"/> </disk> [...] </target>
Procédez à l'installation du SE Oracle Solaris 11.1.