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 de la migration de domaine du manuel Notes de version d’Oracle VM Server for SPARC 2.2.

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 Gestión del protocolo de hora de red (tareas) du manuel Guía de administración del sistema: servicios de red. Pour configurer un domaine en tant que client NTP Oracle Solaris 11, reportez-vous à la section Gestión del protocolo de hora de red (tareas) du manuel Oracle Administración Solaris: Servicios de red.

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.

• Pour les systèmes exécutant le SE Oracle Solaris 10, les machines source et cible doivent posséder le même type de processeur.

• Pour le SE Oracle Solaris 11, la définition de la propriété cpu-arch permet d'effectuer la migration entre des systèmes possédant des processeurs de type différent. Les valeurs de la propriété cpu-arch prises en charge sont les suivantes :

  • 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.

  • generic utilise des fonctions matérielles de la CPU pour permettre à un domaine invité d'effectuer une migration indépendante du type de CPU.

  L'utilisation de la valeur generic peut entraîner une détérioration des performances par rapport à 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.

  Utilisez la commande psrinfo -pv pour déterminer le type de processeur, comme suit :

  # psrinfo -pv
  The physical processor has 8 virtual processors (0-7)
    SPARC-T4 (chipid 0, clock 2548 MHz)

• Lorsque le domaine à migrer exécute le SE Oracle Solaris 11, vous pouvez faire migrer le domaine entre un système source et un système cible dont les processeurs ont des fréquences et des valeurs de fréquence STICK différentes. Ce type de migration est possible même lorsque la valeur de la propriété cpu-arch n'est pas définie. Toutefois, lorsque le domaine à migrer exécute le SE Oracle Solaris 10 la fréquence des processeurs et les valeurs de fréquence STICK des deux machines doivent correspondre.

  Utilisez la commande prtconf -pv pour déterminer la fréquence STICK, comme suit :

  # prtconf -pv | grep stick-frequency
      stick-frequency:  05f4bc08

  ---

  Remarque - La fréquence à laquelle le registre STICK augmente est dérivée de la fréquence de la CPU à pleine vitesse. Cependant, même si la fréquence de la CPU sur les deux machines est identique, la fréquence de registre STICK exacte peut légèrement différer et ainsi bloquer la migration.

  ---

Configuration requise pour la mémoire

Il doit y avoir suffisamment de mémoire libre sur la machine cible pour permettre la migration d'un domaine. Par ailleurs, voici les quelques propriétés qui doivent être conservées pendant la migration :

• Il doit être possible de créer le même nombre de blocs de mémoire de taille identique.

• Les adresses physiques des blocs de mémoire ne doivent pas nécessairement correspondre, mais les mêmes adresses réelles doivent être conservées pendant la migration.

Par ailleurs, la disposition de la mémoire disponible sur la machine cible doit être compatible avec la disposition de la mémoire du domaine à migrer ou la migration échouera. Plus précisément, si la mémoire de la machine cible est fragmentée en plusieurs petites plages d'adresse, mais si le domaine à migrer nécessite une seule large plage d'adresse, la migration échouera. L'exemple suivant illustre ce scénario. La machine cible possède 2 Go de mémoire libre dans deux blocs de mémoire :

# ldm list-devices memory
MEMORY
    PA                   SIZE
    0x108000000          1G
    0x188000000          1G

Le domaine à migrer, ldg-src, possède également 2 Go de mémoire libre, mais il est disposé sur un seul bloc de mémoire :

# ldm list -o memory ldg-src
NAME
ldg-src

MEMORY
    RA               PA               SIZE
    0x8000000        0x208000000      2G

Etant donné cette disposition de la mémoire, la migration échoue :

# ldm migrate-domain ldg-src t5440-sys-2
Target Password:
Unable to bind 2G memory region at real address 0x8000000
Domain Migration of LDom ldg-src failed

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.

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. 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.

  ---

  Attention - 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 à l'aide d'un port disponible sur le premier périphérique vcc du domaine de contrôle. La migration échoue s'il y a un conflit avec le nom de groupe par défaut.

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 hybride NIU n'est pas une contrainte matérielle d'un domaine logique. Si un tel domaine est migré sur une machine ne disposant pas de ressources NIU disponibles, le contrainte est préservée, mais non remplie.

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.

Les versions suivantes du SE Oracle Solaris prennent en charge la reconfiguration dynamique des unités cryptographiques :

• Au moins le SE Solaris 10 10/09

• Au moins le SE Solaris 10 5/08 OS plus patch ID 142245-01

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. Les opérations de reconfiguration retardée sont bloquées lorsqu'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

La migration de domaines n'est pas prise en charge pour une machine source ou cible sur laquelle la stratégie de gestion de d'alimentation (PM) élastique est en cours d'application. Si la stratégie PM sur la machine source ou cible est commutée de performance à élastique alors qu'une migration est en cours, la commutation de stratégie est différée jusqu'à la fin de la migration. La commande de migration renvoie une erreur si une migration de domaine est tentée lorsque la stratégie élastique est en cours d'application sur la machine source ou 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 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 à moins que le domaine à migrer dispose d'une seule CPU. Lorsque le domaine à migrer dispose d'une seule CPU, la migration est effectuée lorsque certaines contraintes et limitations sont respectées. Reportez-vous à la section Restrictions de la migration de domaine du manuel Notes de version d’Oracle VM Server for SPARC 2.2.