ID de bogue 20612716 :la migration en direct d'un domaine invité exécutant la SRU 8 de Oracle Solaris 11.2 à partir d'une machine équipée d'un microprogramme utilisant l'Hyperviseur 1.14.x vers une machine équipée de l'Hyperviseur 1.13.2 peut entraîner l'altération de la mémoire ou des vidages sur incident par panique (noyaux perdus) après la réinitialisation de l'invité.
Ce problème affecte les migrations en direct suivantes :
Pour les systèmes SPARC T4, la panne se produit lors de la migration d'un système fonctionnant avec la version de microprogramme 8.7.x vers un système fonctionnant avec la version 8.6.x.
Pour les systèmes SPARC T5 et d'autres systèmes utilisant le microprogramme 9.x, la panne se produit lors de la migration d'un système fonctionnant avec la version de microprogramme 9.4.x vers un système fonctionnant avec la version 9.3.x.
A partir d'un système utilisant la version 8.7.x du microprogramme vers un système fonctionnant avec la version 8.6.x
A partir d'un système utilisant la version 9.4.x du microprogramme vers un système fonctionnant avec la version 9.3.x
Solution de contournement : pour éviter le problème, ajoutez la ligne suivante au fichier /etc/system du domaine en cours de migration :
set retained_mem_already_checked=1
Pour plus d'informations sur la création ou la mise à jour des valeurs de propriété /etc/system, reportez-vous à la section Mise à jour des valeurs de propriété dans le fichier /etc/system du manuel Guide d’administration d’Oracle VM Server for SPARC 3.2 .
Réinitialisez ensuite le domaine avant de tenter de migrer depuis la version 1.14.x de l'Hyperviseur vers la version 1.13.2.
Si le domaine invité a été déjà été migré depuis le microprogramme 8.7.x vers 8.6.x ou depuis 9.4.x vers 9.3.x, arrêtez et redémarrez le domaine invité. Par exemple :
primary# ldm stop-domain domainname primary# ldm start-domain domainname
ID de bogue 20594568 :la migration en direct d'un domaine invité exécutant la SRU 8 de Oracle Solaris 11.2 à partir d'une machine équipée d'un microprogramme utilisant l'Hyperviseur 1.14.x vers une machine équipée de l'Hyperviseur 1.13.1 est bloquée.
primary# ldm migrate ldg0 target-host Target Password: API group 0x11d v1.0 is not supported in the version of the firmware running on the target machine. Domain ldg0 is using features of the system firmware that are not supported in the version of the firmware running on the target machine.
Ce problème affecte les migrations en direct suivantes :
Pour les systèmes SPARC T4, la panne se produit lors de la migration d'un système fonctionnant avec la version de microprogramme 8.7.x vers un système fonctionnant avec la version 8.5.x.
Pour les systèmes SPARC T5 et d'autres systèmes utilisant le microprogramme 9.x, la panne se produit lors de la migration d'un système fonctionnant avec la version de microprogramme 9.4.x vers un système fonctionnant avec la version 9.2.1.c.
A partir d'un système utilisant la version 8.7.x du microprogramme vers un système fonctionnant avec la version 8.6.x
A partir d'un système utilisant la version 9.4.x du microprogramme vers un système fonctionnant avec la version 9.3.x
Solution de contournement : pour éviter le problème, ajoutez la ligne suivante au fichier /etc/system du domaine en cours de migration :
set retained_mem_already_checked=1
Pour plus d'informations sur la création ou la mise à jour des valeurs de propriété /etc/system, reportez-vous à la section Mise à jour des valeurs de propriété dans le fichier /etc/system du manuel Guide d’administration d’Oracle VM Server for SPARC 3.2 .
Réinitialisez ensuite le domaine et retentez la migration.
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 19163498 et 16585085 : un domaine logique utilisant les périphériques iSCSI ne peut pas utiliser de migration en direct.
ID de bogue 18289196 : sur un système SPARC, une zone de kernel en cours d'exécution dans un domaine Oracle VM Server for SPARC bloque la migration en direct du domaine invité s'il exécute un ou plusieurs composants d'une révision antérieure. Le message d'erreur suivant s'affiche :
Live migration 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
ID de bogue 17285751 : dans le SE Oracle Solaris 10, la migration d'un domaine auquel une seule CPU virtuelle a été assignée peut paniquer 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 17191488 : lors de la tentative de migration d'un domaine à partir d'un système SPARC T5-8 vers un système SPARC T4-4, l'erreur suivante se produit :
primary# ldm migrate ldg1 system2 Target Password: Timeout waiting for domain ldg1 to suspend Domain Migration of LDom ldg1 failed
Solution de contournement : pour éviter ce problème, définissez extended-mapin-space=on.
primary# ldm set-domain extended-mapin-space=on domain-name
ID de bogue 17027275 : les migrations de domaines entre des systèmes SPARC T4 exécutant le microprogramme système 8.3 et des systèmes SPARC T5, SPARC M5 ou SPARC M6 ne devraient pas être 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 15825538 : en cas d'exécution d'une migration en direct sécurisée (ldm migrate) sur un domaine logique configuré avec les fonctions d'interfaces d'E/S réseau hybrides (mode=hybrid) et de migration entre les CPU activées (cpu-arch=generic), le délai d'attente de la migration peut expirer et le domaine rester dans un état suspendu.
Reprise : redémarrez le domaine logique.
Solution de contournement : n'utilisez pas de périphériques de réseau virtuel d'E/S hybride pour une migration en direct entre les CPU.
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 15803617 : le domaine primary ou un domaine invité actif risque de paniquer durant une opération de migration en direct ou d'annulation de la liaison si le domaine est configuré avec des périphériques réseau virtuels d'E/S hybrides.
Reprise : redémarrez le domaine affecté.
Solution de contournement : n'utilisez pas de périphériques réseau virtuels d'E/S hybrides.
ID de bogue 15776752 : si vous annulez une migration en direct, le contenu de la mémoire de l'instance de domaine créé sur la 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.
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 15731303 : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire. Utilisez la commande ldm list -o mem pour afficher la configuration de mémoire de votre domaine. Certaines configurations de mémoire comportant plusieurs blocs équivalant à un total supérieur à 500 risquent de paniquer avec une pile ressemblant à 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 de contournement : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire.
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 15708982 : 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 de contournement : restaurez l'accessibilité du système de fichiers partagé.
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 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, 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, Logical Domains Manager supprime automatiquement les CPU.
ID de bogue 15646293 : suite à la suspension d'un domaine Oracle Solaris 10 9/10 dans le cadre d'une opération de migration, la reconfiguration dynamique de la mémoire est désactivée. Cette action 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 15606220 : à 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 SE Oracle Solaris 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 de contournement : 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 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 15523133 : 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, 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 de contournement : lors de la configuration du domaine cible pour recevoir un domaine migré, assurez-vous que le volume de disque (vdsdev) correspond 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 :
Migrez le domaine et corrigez le vdsdev.
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 virtuelles 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 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.2 .
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