Ignorer les liens de navigation
Quitter l'aperu
| Guide d'administration d'Oracle VM Server for SPARC 3.0 Oracle VM Server for SPARC (Français)

Périmètre de la recherche:

- Ce document
- Toute la bibliothque

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

Astuce - Vous pouvez réduire le temps total de migration en ajoutant d'autres CPU virtuelles au domaine `primary` sur les machines source et cible. Il est préférable, mais pas obligatoire, de disposer d'au moins 16 CPU dans chaque domaine `primary`.

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.

- 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

Remarque - A partir de Oracle Solaris 11.1, il n'est pas nécessaire d'effectuer une réinitialisation pour permettre la reconfiguration dynamique de la mémoire (DR) sur un domaine migré. Dans les versions antérieures à Oracle Solaris 11.1, la reconfiguration dynamique est désactivée pour le domaine migré tant qu'il n'a pas été réinitialisé. Après la réinitialisation, la reconfiguration dynamique de la mémoire est réactivée 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.

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

Notez que la fonctionnalité d'ES hybride NIU a été abandonnée au profit de la fonction SR-IOV.

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

Remarque - Si les contraintes des unités cryptographiques ne peuvent pas être respectées sur la machine cible, l'opération de migration ne sera toutefois pas bloquée. Dans ce cas, le domaine migré peut présenter moins d'unités cryptographiques qu'avant l'opération de migration.

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

A partir de la version 3.0 d'Oracle VM Server for SPARC 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.

Dans les versions antérieures d'Oracle VM Server for SPARC, 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 3.0.

Copyright © 2007, 2013, Oracle et/ou ses affiliés. Tous droits réservés. Notice légale |