Ignorer les liens de navigation | |
Quitter l'aperu | |
Guide d'administration d'Oracle VM Server for SPARC 2.2 Oracle VM Server for SPARC (Français) |
Partie I Logiciel Oracle VM Server for SPARC .2.2
1. Présentation du logiciel Oracle VM Server for SPARC
2. Installation et activation du logiciel
3. Sécurité d'Oracle VM Server for SPARC
4. Configuration des services et du domaine de contrôle
5. Configuration des domaines invités
6. Configuration des domaines d'E/S
7. Utilisation des disques virtuels
8. Utilisation des réseaux virtuels
Introduction à la migration de domaines
Présentation d'une opération de migration
Sécurité pour les opérations de migration
Réalisation de migrations non interactives
Configuration requise des CPU pour la migration de domaines
Configuration requise pour la mémoire
Configuration requise des périphériques d'E/S physiques pour la migration
Configuration requise des périphériques d'E/S virtuels physiques pour la migration
Configuration requise pour les E/S hybrides NIU
Configuration requise des unités cryptographiques pour la migration
Reconfiguration retardée dans un domaine actif
Migration de domaines liés ou inactifs
Configuration requise des périphériques d'E/S virtuels physiques pour la migration
Configuration requise des périphériques d'extrémité PCIe pour la migration
Surveillance d'une migration en cours
Annulation d'une migration en cours
Récupération sur un échec de migration
11. Gestion des configurations de domaine
12. Réalisation d'autres tâches d'administration
Partie II Logiciel Oracle VM Server for SPARC facultatif
13. Outil de conversion physique-à-virtuel Oracle VM Server for SPARC
14. Assistant de configuration d'Oracle VM Server for SPARC (Oracle Solaris 10)
15. Utilisation du logiciel MIB (Management Information Base ) Oracle VM Server for SPARC
16. Recherche de Logical Domains Manager
17. Utilisation de l'interface XML avec Logical Domains Manager
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.
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 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.
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.
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 - Après une migration, la reconfiguration dynamique (DR) de la mémoire est désactivée pour le domaine migré tant qu'il n'a pas été redémarré. Après le redémarrage, la reconfiguration dynamique de la mémoire est réactivée pour le domaine.
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.
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.
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.
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.
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.
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.
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.
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.