Migration d'un domaine actif

Certaines exigences et restrictions sont imposées au domaine à migrer, à la machine source et à la machine cible lorsque vous tentez de migrer un domaine actif. Pour plus d'informations, reportez-vous à la section Restrictions liées aux migrations de domaines.

Un domaine "perd du temps" au cours du processus de migration. Pour limiter ce problème, synchronisez le domaine à migrer avec une source temporelle externe, un serveur NTP (Network Time Protocol, protocole d'heure réseau) par exemple. Lorsque vous configurez un domaine en tant que client NTP, la date et l'heure du domaine sont corrigés peu après la fin de la migration.

Pour configurer un domaine en tant que client NTP Oracle Solaris 10, reportez-vous à la section Managing Network Time Protocol (Tasks) du manuel System Administration Guide: Network Services . Pour configurer un domaine en tant que client NTP Oracle Solaris 11, reportez-vous à la section Managing Network Time Protocol (Tasks) du manuel Introduction to Oracle Solaris 11 Network Services .

Configuration requise des CPU pour la migration de domaines

Vous trouverez ci-dessous les contraintes et les limitations concernant les CPU lorsque vous effectuez une migration :

• La machine cible doit avoir suffisamment de CPU virtuelles libres pour accueillir le nombre de CPU virtuelles utilisées par le domaine à migrer.

• La définition de la propriété cpu-arch sur le domaine invité permet d'effectuer la migration de domaine entre des systèmes possédant des processeurs de type différent. Notez que le domaine invité doit se trouver dans un état lié ou inactif pour pouvoir modifier la valeur cpu-arch.

  Les valeurs suivantes sont prises en charge pour la propriété cpu-arch :

  • native utilise des fonctions matérielles spécifiques à la CPU pour permettre à un domaine invité de migrer uniquement entre des plates-formes de type de CPU identique. native est la valeur par défaut.

  • migration-class1 est une famille de migration entre les CPU pour les plates-formes SPARC à partir de SPARC T4. Ces plates-formes prennent en charge la cryptographie matérielle pendant et après ces migrations afin de réduire la dépendance aux CPU prises en charge.

    Cette valeur n'est pas compatible avec les plates-formes UltraSPARC T2, UltraSPARC T2 Plus ou SPARC T3, ni les Plates-formes Fujitsu M10.

  • sparc64-class1 est une famille de migration entre les CPU pour les plates-formes SPARC64. Etant donné que la valeur sparc64-class1 est basée sur les instructions SPARC64, son nombre d'instructions est plus important que pour la valeur generic. Par conséquent, il n'y a aucun impact sur les performances par rapport à la valeur generic.

    Cette valeur est uniquement compatible avec les Serveurs Fujitsu M10.

  • generic utilise les fonctions matérielles de CPU constituant le plus petit dénominateur commun et utilisées par toutes les plates-formes pour permettre à un domaine invité d'exécuter une migration indépendante du type de CPU.

  Les commandes isainfo -v suivantes indiquent les instructions disponibles sur un système lorsque cpu-arch=generic et lorsque cpu-arch=migration-class1.

  • cpu-arch=generic

    # isainfo -v
    64-bit sparcv9 applications
            asi_blk_init vis2 vis popc
    32-bit sparc applications
            asi_blk_init vis2 vis popc v8plus div32 mul32

  • cpu-arch=migration-class1

    # isainfo -v
    64-bit sparcv9 applications
            crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5
            camellia des aes ima hpc vis3 fmaf asi_blk_init vis2
            vis popc
    32-bit sparc applications
            crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5
            camellia des aes ima hpc vis3 fmaf asi_blk_init vis2
            vis popc v8plus div32 mul32

  L'utilisation de la valeur generic peut entraîner une détérioration des performances du domaine invité par rapport à l'utilisation de la valeur native. Cette détérioration éventuelle des performances est due au fait que le domaine invité utilise uniquement les fonctionnalités CPU disponibles sur tous les types de CPU, et non les fonctions matérielles natives d'une CPU particulière. En évitant d'utiliser ces fonctions, la valeur generic vous offre la possibilité de migrer le domaine entre des systèmes dont les CPU prennent en charge des fonctions différentes.

  Pour la migration d'un domaine entre des systèmes SPARC T4 minimum, vous pouvez définir cpu-arch=migration-class1 pour améliorer les performances du domaine invité. Les performances sont améliorées par l'utilisation de la valeur generic et la valeur native fournit encore une performance maximale pour le domaine invité.

  Utilisez la commande psrinfo -pv lorsque la propriété cpu-arch est définie sur native pour déterminer le type de processeur, comme suit :

  # psrinfo -pv
  The physical processor has 2 virtual processors (0 1)
    SPARC-T5 (chipid 0, clock 3600 MHz)

  Notez que lorsque la propriété cpu-arch est définie sur une valeur autre que native, la sortie psrinfo -pv n'affiche pas le type de plate-forme. Au lieu de cela, la commande montre que le module de CPU sun4v-cpu est chargé.

  # psrinfo -pv
  The physical processor has 2 cores and 13 virtual processors (0-12)
    The core has 8 virtual processors (0-7)
    The core has 5 virtual processors (8-12)
      sun4v-cpu (chipid 0, clock 3600 MHz)

Configuration requise pour la mémoire

Les exigences de mémoire pour la machine cible sont les suivantes :

• La machine cible doit avoir suffisamment de mémoire libre pour permettre la migration d'un domaine.

• La mémoire libre doit être disponible dans une disposition compatible.

Les exigences de compatibilité diffèrent selon la plate-forme SPARC. Toutefois, au minimum l'alignement de l'adresse réel et de l'adresse physique relatif à la taille de page maximale prise en charge doit être préservé pour chaque bloc mémoire dans le domaine migré.

Utilisez la commande pagesize pour déterminer la taille de page maximale prise en charge sur la machine cible.

Pour un domaine invité qui exécute au moins le SE Oracle Solaris 11.3, les blocs mémoire du domaine migré doivent être automatiquement fractionnés lors de la migration de sorte que le domaine migré peut s'adapter aux plus petits blocs de mémoire disponibles. Les blocs mémoire ne peuvent être fractionnés qu'en fonction des limites alignées sur la taille de page maximale.

D'autres exigences de disposition de mémoire pour les systèmes d'exploitation, microprogrammes ou plates-formes peuvent empêcher le fractionnement des blocs mémoire lors d'une migration donnée. Cette situation pourrait provoquer l'échec de la migration même si l'espace total de mémoire disponible est suffisant pour le domaine.

Configuration requise des périphériques d'E/S physiques pour la migration

Les domaines disposant d'un accès direct aux périphériques physiques ne peuvent pas être migrés. Par exemple, vous ne pouvez pas migrer des domaines d'E/S. Cependant, les périphériques virtuels associés à des périphériques physiques peuvent être migrés.

Pour plus d'informations, reportez-vous aux sections Configuration requise des périphériques d'extrémité PCIe pour la migration et Configuration requise pour la migration des fonctions virtuelles SR-IOV PCIe.

Configuration requise des périphériques d'E/S virtuels physiques pour la migration

Tous les services d'E/S virtuels utilisés par le domaine à migrer doivent être disponibles sur la machine cible. En d'autres termes, les conditions suivantes doivent être remplies :

• Tous les disques backend virtuels utilisés dans le domaine à migrer doivent être définis sur la machine cible. Ce stockage partagé peut être un disque SAN ou un espace de stockage disponible via les protocoles NFS ou iSCSI. Le disque virtuel backend défini doit avoir les mêmes noms de service et de volume que sur la machine source. Les chemins d'accès peuvent être différents sur les machines source et cible, mais ils doivent pointer vers le même disque backend.

  ---

  Mise en garde  - Une migration réussira même si les chemins d'accès à un disque virtuel backend sur les machines source et cible ne se réfèrent pas au même stockage. Cependant, le comportement du domaine sur la machine cible sera imprévisible, et il est possible que le domaine soit inutilisable. Pour corriger cette situation, arrêtez le domaine, corrigez le problème de configuration et redémarrez le domaine. Si vous n'exécutez pas ces étapes, le domaine risque de rester dans un état incohérent.

  ---

• Chaque périphérique réseau virtuel dans le domaine à migrer doit posséder un commutateur de réseau virtuel correspondant sur la machine cible. Les commutateurs de réseau virtuel doivent tous posséder le même nom que le commutateur de réseau virtuel auquel le périphérique est connecté sur la machine source.

  Par exemple, si vnet0 dans le domaine à migrer est connecté à un service de commutateur virtuel appelé switch-y, un domaine sur la machine cible doit fournir un service de commutateur virtuel appelé switch-y.

  ---

  Remarque - Le réseau physique sur la machine cible doit être correctement configuré, de sorte que le domaine migré puisse accéder aux ressources réseau dont il a besoin. Sinon, certains services risquent d'être indisponibles sur le domaine une fois la migration terminée.

  Par exemple, vous pouvez souhaiter vous assurer que le domaine peut accéder au bon sous-réseau sur le réseau. Vous pouvez également vouloir vérifier que les passerelles, routeurs ou pare-feu sont correctement configurés, de sorte que le domaine puisse atteindre les systèmes distants à partir de la machine cible.

  ---

  Les adresses MAC utilisées par le domaine à migrer qui se trouvent dans la plage allouée automatiquement doivent être disponibles sur la machine cible.

• Un service de concentrateur de console virtuelle (vcc) doit exister sur la machine cible et disposer d'au moins un port libre. Les contraintes explicites de la console sont ignorées au cours de la migration. La console du domaine migré est créée en utilisant le nom du domaine migré comme groupe de consoles et n'importe quel port disponible sur n'importe quel périphérique vcc disponible du domaine de contrôle. Si aucun des ports disponibles n'est libre dans le domaine de contrôle, la console est créée à l'aide d'un port disponible sur un périphérique vcc disponible dans un domaine de service. La migration échoue s'il y a un conflit avec le nom de groupe par défaut.

• Chaque SAN virtuel utilisé par le domaine à migrer doit être défini sur la machine cible.

Configuration requise des périphériques d'extrémité PCIe pour la migration

Vous ne pouvez pas effectuer une migration de domaine sur un domaine d'E/S configuré avec des périphériques d'extrémité PCIe.

Pour plus d'informations sur la fonction d'E/S directes (DIO), reportez-vous à la section Création d'un domaine d'E/S en assignant les périphériques d'extrémité PCIe.

Configuration requise pour la migration des fonctions virtuelles SR-IOV PCIe

Vous ne pouvez pas effectuer une migration de domaine sur un domaine d'E/S configuré avec des fonctions virtuelles SR-IOV PCIe.

Pour plus d'informations sur la fonction SR-IOV, reportez-vous au Chapter 7, Création d'un domaine d'E/S à l'aide des fonctions virtuelles SR-IOV PCIe.

Configuration requise pour les E/S hybrides NIU

Vous pouvez migrer un domaine qui utilise des ressources d'E/S hybride NIU. Une contrainte définissant les ressources d'E/S hybrides NIU n'est pas une contrainte impérative d'un domaine logique. Si un tel domaine est migré sur une machine ne disposant pas de ressources NIU disponibles, la contrainte est préservée, mais non satisfaite.

Notez que la fonctionnalité d'E/S hybride NIU est remplacée par la fonction SR-IOV. Oracle VM Server for SPARC 3.3 est la dernière version logicielle à inclure cette fonction.

Configuration requise des unités cryptographiques pour la migration

Sur les plates-formes comportant des unités cryptographiques, vous pouvez migrer un domaine invité associé à des unités cryptographiques s'il exécute un système d'exploitation prenant en charge la reconfiguration dynamique (DR) des unités cryptographiques.

Au début de la migration, Logical Domains Manager détermine si le domaine à migrer prend en charge la reconfiguration dynamique des unités cryptographiques. Si tel est le cas, Logical Domains Manager tente de supprimer les unités cryptographiques du domaine. A la fin de la migration, les unités cryptographiques sont de nouveau ajoutées au domaine migré.

Reconfiguration retardée dans un domaine actif

Les opérations de reconfiguration retardée actives sur les hôtes source et cible empêchent le début de la migration. Vous n'êtes pas autorisé à démarrer une opération de reconfiguration retardée pendant qu'une migration est en cours.

Migration alors que la stratégie de gestion de l'alimentation élastique est en cours d'application sur un domaine actif

Vous pouvez effectuer une migration en direct lorsque la stratégie de gestion de d'alimentation (PM) élastique est en cours d'application sur la machine source ou sur la machine cible.

Opérations sur d'autres domaines

Pendant qu'une migration est en cours sur une machine, toute opération pouvant provoquer la modification de l'état ou la configuration du domaine en cours de migration est bloquée. Toutes les opérations sur le domaine lui-même, ainsi que les opérations de liaison et d'arrêt sur les autres domaines de la machine sont bloquées.

Migration d'un domaine à partir de la PROM OpenBoot ou un domaine en cours d'exécution dans le débogueur de noyau

L'exécution de la migration d'un domaine requiert une coordination entre Logical Domains Manager et le SE SE Oracle Solaris en cours d'exécution dans le domaine à migrer. Lorsqu'un domaine à migrer est exécuté dans OpenBoot ou dans le débogueur de noyau (kmdb), cette coordination est impossible. Par conséquent, la tentative de migration échoue.

Lorsqu'un domaine à migrer s'exécute en OpenBoot, le message suivant apparaît :

primary# ldm migrate ldg1 system2
Migration is not supported while the domain ldg1 is in the 'OpenBoot Running' state
Domain Migration of LDom ldg1 failed

Lorsqu'un domaine à migrer s'exécute dans le débogueur de noyau, kmdb, le message suivant apparaît :

primary# ldm migrate ldg1 system2
Migration is not supported while the domain ldg1 is in the 'Solaris debugging' state
Domain Migration of LDom ldg1 failed