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.
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.2.
Solution de contournement : effectuez les opérations suivantes :
Réactivez temporairement cette possibilité sur votre système Oracle VM Server for SPARC 3.2 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.2.
# 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.
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é.
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 Serveurs 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
Serveurs 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 Serveur 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 Serveur 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.
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.