Cette section décrit les problèmes matériels et logiciels connus pour cette version du logiciel Oracle VM Server for SPARC qui ne concernent pas qu'un numéro de bogue particulier. Des solutions sont proposées, le cas échéant.
Si vous annulez une migration en direct, le contenu de la mémoire de l'instance de domaine créé sur la machine cible doit être "nettoyé" par l'hyperviseur. Ce processus de nettoyage est effectué pour des raisons de sécurité et doit être terminé afin que la mémoire puisse être renvoyée vers le pool de mémoire libre. Durant la progression du nettoyage, les commandes ldm deviennent non réactives. Par conséquent, Logical Domains Manager semble suspendu.
Reprise : attendez la fin de la demande de nettoyage avant de tenter d'exécuter les autres commandes ldm. Ce processus peut être long. Par exemple, un domaine invité comptant 500 Go de mémoire peut mettre jusqu'à 7 minutes pour terminer le processus sur un serveur SPARC T4 ou jusqu'à 25 minutes sur un serveur SPARC T3.
Lorsque vous utilisez la commande ldm add-vcpu pour assigner des CPU à un domaine, une grave erreur risque de se produire au niveau du SE Oracle Solaris et le message suivant peut s'afficher :
panic[cpu16]/thread=c4012102c860: mpo_cpu_add: Cannot read MD
Cette panique se produit dans les cas suivants :
Des DCU supplémentaires ont été attribués à un hôte
L'hôte est démarré à l'aide d'une configuration SP précédemment enregistrée qui ne contient pas tout le matériel attribué à l'hôte.
Le domaine cible de l'opération ldm add-vcpu est le domaine qui panique. Le domaine est récupéré avec les CPU supplémentaires lors de la réinitialisation.
Solution de contournement : n'utilisez pas des configurations générées avec un nombre de ressources matérielles moindre que celui affecté à l'hôte.
Afin d'éviter ce problème, n'ajoutez pas de CPU selon la procédure détaillée dans la description du problème. Ou effectuez les opérations suivantes :
Générez une nouvelle configuration de processeur de service après l'ajout des DCU.
Par exemple, la commande suivante crée une configuration nommée new-config-more-dcus :
primary# ldm add-config new-config-more-dcus
Arrêtez le domaine.
Arrêtez l'hôte.
-> stop /HOST
Démarrez l'hôte.
-> start /HOST
Les ressources situées sur le complexe root ne sont pas restaurées après la destruction de l'ensemble des fonctions virtuelles et le renvoi des emplacements vers le domaine root.
Récupération : renvoyez l'ensemble des ressources d'E/S virtuelles associées au complexe root à leur domaine root.
Placez d'abord le domaine de contrôle en mode de reconfiguration retardée.
primary# ldm start-reconf primary
Renvoyez l'ensemble des emplacements PCIe enfants au domaine root propriétaire du bus pci_0. Supprimez ensuite l'ensemble des fonctions virtuelles enfants sur le bus pci_0 et détruisez-les.
Enfin, définissez iov=off pour le bus pci_0 et réinitialisez le domaine root.
primary# ldm set-io iov=off pci_0 primary# shutdown -y -g 10
Solution de contournement : définissez l'option iov sur off pour le bus PCIe spécifique.
primary# ldm start-reconf primary primary# ldm set-io iov=off pci_0
La commande ldm init-system ne parvient pas à restaurer les contraintes de coeur des CPU nommés pour les domaines invités à partir d'un fichier XML enregistré.
Solution de contournement : effectuez les opérations suivantes :
Créez un fichier XML pour le domaine primary.
# ldm ls-constraints -x primary > primary.xml
Créez un fichier XML pour le ou les domaines invités.
# ldm ls-constraints -x domain-name[,domain-name][,...] > guest.xml
Effectuez un cycle d'alimentation du système et initialisez une configuration usine par défaut.
Appliquez la configuration XML au domaine primary.
# ldm init-system -r -i primary.xml
Appliquez la configuration XML aux domaines invités.
# ldm init-system -f -i guest.xml
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 de contournement : arrêtez le domaine invité avant de supprimer plus de 100 CPU.
Si le logiciel Logical Domains est configuré sur un système et que vous ajoutez une autre carte réseau XAUI, celle-ci n'est pas visible après l'arrêt et le redémarrage de la machine.
Reprise : pour que la carte XAUI récemment ajoutée soit visible dans le domaine de contrôle, suivez les étapes ci-dessous :
Définissez et effacez une variable factice dans le domaine de contrôle.
Les commandes suivantes utilisent une variable factice appelée fix-xaui :
# ldm set-var fix-xaui=yes primary # ldm rm-var fix-xaui primary
Enregistrez la configuration modifiée sur le processeur de service (SP) en écrasant l'actuelle.
Les commandes suivantes utilisent une configuration appelée fix-config1 :
# ldm rm-spconfig config1 # ldm add-spconfig config1
Effectuez une réinitialisation de reconfiguration sur le domaine de contrôle.
# reboot -- -r
A ce stade, vous pouvez configurer les réseaux récemment disponibles pour que le logiciel Logical Domains puisse les utiliser.
Si vous tentez de supprimer un bus PCIe qui héberge des périphériques HBA LSI SAS, il sera impossible de les ajouter ultérieurement au moyen d'opérations d'enfichage à chaud sur carte PCI ou bus dynamique.
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.