ID de bogue 21554591 : au cours d'une migration en direct, il se peut que le service ldmd sur la machine cible effectue un dump noyau et redémarre.
Ce problème peut se produire si la mémoire du domaine à migrer est fortement fragmentée en plusieurs segments et que la disposition de la mémoire libre sur la machine cible n'est pas compatible. Le problème est plus fréquent si la reconfiguration dynamique est utilisée pour supprimer de la mémoire au domaine avant la migration en direct.
La trace de pile du dump noyau est identique à ce qui suit :
restore_lgpg_mblk+0x398(17bbc88, 16c39c8, 80000000, 80000000, 0, 40000000) rgrp_restore_lgpg+0x39c(0, 0, 1733948, 1711598, 0, 20000000) mem_allocate_real+0x92c(0, 20000000, ffbff868, 13aec88, 80808080, 373cd8) affinity_bind_resources+0x9f4(17bbc88, ffbff948, 13aec88, 3a10c000, 3a10c000, 1010101) mem_bind_real+0x468(17bbc88, ffbff9d4, 13aec88, 3a10c000, 3a10c000, 1010101) mem_bind_real_check+0xf4(17bbc88, 12ee338, 13aec88, 0, 376468, ff29fd80) mig_tgt_bound_feasibility_check+0x168(164be08, ff000000, ff, 1, 0, 0) i_tgt_do_feasibility_check+0x168(164be08, 0, 12390, 1, f960d244, ffffff) sequence+0x4a4(0, ff000000, ff322a40, 1, f960d244, ffffff) main+0xb54(5, ffbffc64, ffbffc7c, f960a900, 0, ff320200) _start+0x108(0, 0, 0, 0, 0, 370b60)
Lorsque ce problème se produit, le domaine invité continue de s'exécuter. Si les services ldmd redémarrent correctement, aucune autre récupération n'est nécessaire.
Si le service ldmd ne parvient pas à redémarrer et passe en mode de maintenance en raison du bogue 21569507, vous devez arrêter puis redémarrer l'hôte ou le domaine physique applicable avant de réexécuter la commande ldmd.
Solution : arrêtez et dissociez le domaine invité, puis effectuez une migration à froid. N'utilisez pas la reconfiguration dynamique pour supprimer de la mémoire aux domaines invités à migrer.
ID de bogue 21289174 : sur un système SPARC, une zone de noyau en cours d'exécution dans un domaine Oracle VM Server for SPARC bloquera la migration en direct du domaine invité. Le message d'erreur suivant s'affiche :
Guest suspension failed because Kernel Zones are active. Stop Kernel Zones and retry.
Solution de contournement : choisissez l'une des solutions suivantes :
Arrêter l'exécution de la zone de noyau.
# zoneadm -z zonename shutdown
Suspendre la zone de noyau.
# zoneadm -z zonename suspend
Effectuez une migration en direct vers un autre système avant de migrer le domaine invité.
Reportez-vous au Chapitre 3, Migrating an Oracle Solaris Kernel Zone du manuel Creating and Using Oracle Solaris Kernel Zones .
ID de bogue 20606773 : les migrations en direct de CPU à CPU entre un serveur de la série SPARC T7 ou SPARC M7 et une ancienne plate-forme nécessitent d'exécuter au moins le logiciel Oracle VM Server for SPARC 3.2 sur les machines source et cible.
Par exemple, la migration en direct entre un système SPARC T5 et un serveur de la série SPARC T7 requiert au moins que le logiciel Oracle VM Server for SPARC 3.2 soit installé sur le système SPARC T5.
ID de bogue 20453206 : la migration peut échouer même en cas de mémoire suffisante dans une configuration valide du système cible. Les opérations de reconfiguration dynamique de la mémoire peuvent rendre plus compliquée la migration d'un domaine invité.
Solution de contournement : aucune.
ID de bogue 17285751 : la migration d'un domaine invité Oracle Solaris 10 auquel une seule CPU virtuelle a été assignée peut provoquer une erreur grave sur le domaine invité dans la fonction pg_cmt_cpu_fini().
Solution de contournement : assignez au moins deux CPU virtuelles au domaine invité avant de procéder à la migration en direct. Par exemple, utilisez la commandeldm add-vcpu number-of-virtual-CPUs domain-name pour augmenter le nombre de CPU virtuelles assignées au domaine invité.
ID de bogue 17027275 : les migrations de domaine à partir de systèmes SPARC T4 qui exécutent le microprogramme système 8.3 vers des systèmes SPARC T5, SPARC M5 ou SPARC M6 ne sont pas autorisées. Bien que la migration soit réussie, une opération de reconfiguration dynamique ultérieure entraîne une panique.
Solution de contournement : mettez à jour le microprogramme vers la version 8.4 sur le système SPARC T4. Voir la solution de contournement pour les Panique de domaine invité à lgrp_lineage_add(mutex_enter: bad mutex, lp=10351178).
ID de bogue 16864417 : la commande ldm migrate -n ne signale pas d'échec lors d'une tentative de migration entre une machine SPARC T5, SPARC M5 ou SPARC M6 et une machine UltraSPARC T2 ou SPARC T3.
Solution de contournement : aucune.
ID de bogue 15819714 : dans de rares circonstances, la commande ldm list -o status, indique un pourcentage d'avancement faux lorsqu'elle est utilisée pour observer l'état d'une migration sur un domaine de contrôle.
Ce problème n'a aucune incidence sur le domaine en cours de migration ou sur les démons ldmd des domaines de contrôle source ou cible.
Solution de contournement : exécutez la commande ldm list -o status de l'autre domaine de contrôle qui est impliqué dans la migration afin d'observer la progression.
ID de bogue 15776123 : si la commande cputrack est exécutée sur un domaine invité pendant la migration de ce domaine vers un système SPARC T4, le domaine invité peut paniquer sur la machine cible après avoir été migré.
Solution de contournement : n'exécutez pas la commande cputrack durant la migration d'un domaine invité vers un système SPARC T4.
ID de bogue 15775055 : après la migration d'un domaine entre deux machines possédant des fréquences de CPU différentes; le temps de disponibilité signalé par la commande ldm list peut être incorrect. Ces résultats incorrects surviennent car le temps de disponibilité est calculé par rapport à la fréquence STICK de la machine sur laquelle le domaine est exécuté. Si la fréquence STICK diffère entre les machines source et cible, le temps de disponibilité apparaît incorrect à l'échelle.
Ce problème ne concerne que les systèmes UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3.
Le temps de disponibilité signalé et affiché par le domaine invité lui-même est correct. En outre, toute la comptabilisation effectuée par le SE Oracle Solaris dans le domaine invité est correcte.
ID de bogue 15710957 : 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 de contournement : 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 15701865 : si vous tentez une migration en direct d'un domaine dépendant d'un domaine inactif sur la machine cible, le démon ldmd échoue avec une erreur de segmentation et le domaine de la machine cible est redémarré. Vous pouvez néanmoins effectuer une migration, mais pas une migration en direct.
Solution de contournement : effectuez l'une des actions suivantes avant de tenter la migration en direct :
Supprimez la dépendance invitée du domaine à migrer.
Démarrez le domaine maître sur la machine cible.
ID de bogue 15701853 : si vous effectuez une migration de domaine alors qu'une stratégie DRM est en vigueur et que, par la suite, la stratégie DRM expire ou est supprimée du domaine migré, DRM ne parvient pas à restaurer le nombre d'origine de CPU virtuelles sur le domaine.
Solution de contournement : 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 15699763 : 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 de contournement : assurez-vous que les adresses MAC sur la machine cible sont uniques.
ID de bogue 15696986 : si deux commandes ldm migrate sont émises simultanément entre deux systèmes identiques dans des "directions opposées," elles risquent de se bloquer et de ne jamais aboutir. 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.
Le blocage se produit même si les processus de migration sont initialisés en tant que simulations à l'aide de l'option –n. Lorsque ce problème se produit, toutes les autres commandes ldm risquent de se bloquer.
Solution de contournement : aucune.
ID de bogue 15655513 : 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 peut 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, Logical Domains Manager supprime automatiquement les CPU.
ID de bogue 15527921 : 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 15523120 : 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. Voir la section Configuration requise pour la mémoire du manuel Guide d’administration d’Oracle VM Server for SPARC 3.3 .
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 15513998 : il arrive qu'il soit impossible de se connecter à la console d'un domaine qui vient d'être migré.
Solution de contournement : redémarrez le service SMF vntsd pour activer les connexions à la console :
# svcadm restart vntsd
Les versions 8.4, 9.1 et XCP2230 du microprogramme système ont inclus pour la première fois la prise en charge des étiquettes de disque GPT EFI. Par défaut, les disques virtuels qui sont installés sur des systèmes exécutant le SE Oracle Solaris 11.1 ou une version ultérieure possèdent une étiquette de disque GPT EFI. Cette étiquette de disque n'est pas lisible sur les versions plus anciennes du microprogramme (telles que 9.0.x, 8.3, 7.x ou XCP2221). Cette situation vous empêche d'effectuer une migration en direct ou une migration à froid vers un système exécutant une version du microprogramme système ne prenant pas en charge GPT EFI. Notez que la migration à froid échoue également dans cette situation, qui est différente des restrictions précédentes.
Pour déterminer si votre disque virtuel dispose d'une étiquette de disque GPT EFI, exécutez la commande devinfo -i sur le périphérique brut. Les exemples suivants indiquent si le disque virtuel possède une étiquette de disque VTOC SMI ou GPT EFI .
Etiquette de disque VTOC SMI. Si votre disque virtuel possède une étiquette VTOC SMI, vous pouvez effectuer une migration vers le microprogramme, que celui-ci prenne en charge EFI ou non.
Cet exemple indique que le périphérique a une étiquette VTOC car la commande devinfo -i affiche des informations propres au périphérique .
# devinfo -i /dev/rdsk/c2d0s2 /dev/rdsk/c2d0s2 0 0 73728 512 2
Etiquette de disque GPT EFI. Si votre disque virtuel possède une étiquette de disque GTP EFI, vous pouvez uniquement effectuer une migration vers un microprogramme prenant en charge EFI.
Cet exemple indique que le périphérique a une étiquette GPT EFI car la commande devinfo -i signale une erreur .
# devinfo -i /dev/rdsk/c1d0s0 devinfo: /dev/rdsk/c1d0s0: This operation is not supported on EFI labeled devices