¶ Importance
La gestion efficace des VMs nécessite des compétences en migration de VMs, en création de snapshots et en gestion des ressources des VMs.
¶ Leçons du module
- Migration des VMs avec vSphere vMotion
- Configuration de l’Enhanced vMotion Compatibility
- Migration des VMs avec vSphere Storage vMotion
- Migrations Cross vCenter
- Création de snapshots de Virtual Machines
- Concepts de CPU virtuel et de mémoire virtuelle
- Contrôle des ressources (Resource Controls)
¶ Leçon 1 : Migration de VMs avec vSphere vMotion
¶ Objectifs d’apprentissage
- Identifier les types de migrations de VMs que vous pouvez effectuer dans une instance vCenter
- Expliquer le fonctionnement de vSphere vMotion
- Vérifier les prérequis de vSphere vMotion
- Migrer des virtual machines en utilisant vSphere vMotion
¶ À propos de la migration de VM
La migration signifie déplacer une VM d’un host, datastore, ou d’une instance vCenter vers un autre host, datastore, ou une autre instance vCenter.
La migration peut être cold ou hot :
- Une cold migration déplace une VM arrêtée ou suspendue.
- Une hot migration déplace une VM allumée.
vCenter effectue des vérifications de compatibilité avant de migrer des VMs suspendues ou allumées afin de s’assurer que la VM est compatible avec le host cible.
¶ Types de migration
Le type de migration que vous effectuez dépend de l’état d’alimentation de la VM que vous sélectionnez dans l’inventaire et du type de migration que vous choisissez dans l’assistant Migrate.
L’assistant Migrate propose les options de migration suivantes :
-
Compute resource only :
— Déplacer une VM, mais pas son stockage, vers un autre host.
— Pour une hot migration, vSphere vMotion est utilisé pour déplacer la VM. -
Storage only :
— Déplacer les fichiers ou objets d’une VM vers un nouveau datastore.
— Pour une hot migration, vSphere Storage vMotion est utilisé pour déplacer la VM. -
Both compute resource and storage :
— Déplacer une VM vers un autre host et datastore.
— Pour une hot migration, vSphere vMotion et vSphere Storage vMotion sont utilisés pour déplacer la VM. -
Cross vCenter Server export :
— Déplacer la VM vers un host et un datastore gérés par une instance vCenter différente qui n’est pas liée au domaine SSO actuel.
L’objectif de la migration détermine quelle technique de migration utiliser. Par exemple, vous pourriez avoir besoin d’arrêter un host pour maintenance tout en gardant les VMs en fonctionnement. Dans ce cas, utilisez vSphere vMotion pour migrer les VMs au lieu d’effectuer une migration cold ou d’une VM suspendue.
Si vous devez déplacer les fichiers d’une VM vers un autre datastore afin de mieux équilibrer la charge disque ou de migrer vers une autre storage array, vous utilisez vSphere Storage vMotion.
Certaines techniques de migration, telles que la migration avec vSphere vMotion, ont des exigences matérielles spécifiques qui doivent être respectées.
D’autres techniques, comme une cold migration, n’ont pas d’exigences matérielles particulières.
¶ À propos de vSphere vMotion
Une migration vSphere vMotion déplace une VM allumée d’un host (ressource de calcul) vers un autre.
vSphere vMotion offre les fonctionnalités suivantes :
- Amélioration de l’utilisation globale du matériel
- Continuité de fonctionnement des VMs tout en permettant l’arrêt planifié d’un ESXi host
- Utilisation de vSphere DRS pour équilibrer les VMs entre les hosts
Avec vSphere vMotion, vous pouvez migrer des VMs en cours d’exécution d’un ESXi host vers un autre ESXi host sans interruption ni temps d’arrêt.
vSphere DRS utilise vSphere vMotion pour migrer des VMs en cours d’exécution d’un host vers un autre afin de s’assurer que les VMs disposent des ressources dont elles ont besoin.
Avec vSphere vMotion, l’état complet de la VM est déplacé d’un host vers un autre, mais les données restent stockées dans le même datastore.
Les informations d’état incluent le contenu mémoire actuel ainsi que toutes les informations qui définissent et identifient la VM.
Le contenu mémoire comprend les données de transaction et les éléments du système d’exploitation et des applications présents en mémoire.
Les informations de définition et d’identification stockées dans l’état incluent toutes les données qui correspondent aux éléments matériels de la VM, tels que le BIOS ou EFI, les périphériques, le CPU, et les adresses MAC des cartes Ethernet.
¶ Configuration des réseaux vSphere vMotion
Les migrations vSphere vMotion nécessitent une configuration correcte des adaptateurs VMkernel sur les hosts source et destination.
Pour configurer le réseau vSphere vMotion, vous devez configurer un adaptateur VMkernel avec le service vSphere vMotion activé sur le host source et le host destination.
¶ Workflow de migration vSphere vMotion
Le host source (ESXi01) et le host destination (ESXi02) peuvent accéder au shared datastore qui contient les fichiers de la VM.
Une animation est disponible à cette adresse : https://vmware.bravais.com/s/FbzaDb6owpSMKyKc940F.
Une migration vSphere vMotion se compose des étapes suivantes :
- Une shadow VM est créée sur le host de destination.
- L’état mémoire de la VM est copié via le réseau vSphere vMotion depuis le host source vers le host cible à travers le réseau vSphere vMotion. Les utilisateurs continuent d’accéder à la VM et, potentiellement, de modifier des pages en mémoire. Une liste des pages modifiées en mémoire est conservée dans un memory bitmap sur le host source.
- Après la première passe de copie de l’état mémoire, une autre passe de copie mémoire est effectuée pour transférer les pages qui ont changé durant la dernière itération. Ce processus itératif de copie mémoire continue jusqu’à ce que le nombre de pages modifiées soit suffisamment faible pour être transféré en moins de 500 millisecondes.
- Après que la majeure partie de la mémoire de la VM a été copiée du host source vers le host cible, la VM est quiesced (mise en pause). Aucune activité supplémentaire ne se produit sur la VM. Pendant cette période de quiesce, vSphere vMotion transfère l’état des périphériques de la VM ainsi que le memory bitmap vers le host de destination.
- Immédiatement après que la VM est quiesced sur le host source, elle est initialisée et démarre sur le host cible. Une requête Gratuitous Address Resolution Protocol (GARP) notifie le sous-réseau que l’adresse MAC de la VM A est désormais accessible via un port physique de switch différent. Les fichiers de la VM sont déverrouillés par le host source et verrouillés par le host de destination.
- Les utilisateurs accèdent à la VM sur le host de destination au lieu du host source.
- Les pages mémoire que la VM utilisait sur le host source sont marquées comme libres.
Pour une discussion détaillée sur le fonctionnement de vSphere vMotion, consultez The vMotion Process Under the Hood : https://blogs.vmware.com/vsphere/2019/07/the-vmotion-process-under-the-hood.html.
¶ Exigences des VMs pour une migration vSphere vMotion
Pour une migration avec vSphere vMotion, une VM doit respecter les exigences suivantes :
- Si elle utilise un disque RDM, le fichier RDM et le LUN auquel il est mappé doivent être accessibles par le host de destination.
- Elle ne doit pas avoir de connexion à un périphérique virtuel, tel qu’un lecteur CD/DVD ou floppy drive, avec une image locale au host montée.
Vous pouvez utiliser vSphere vMotion pour migrer une VM avec un périphérique attaché via une remote console (comme un périphérique physique ou une image disque).
Pour la liste complète des exigences de migration vSphere vMotion, consultez vCenter Server and Host Management : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Exigences des hosts pour une migration vSphere vMotion
Les hosts source et destination doivent avoir les caractéristiques suivantes :
-
Accessibilité à tout le stockage de la VM :
— 128 migrations concurrentes sont possibles par datastore.
— Si l’emplacement du swap file sur le host de destination diffère de l’emplacement du swap file sur le host source, le swap file est copié vers le nouvel emplacement. -
Port VMkernel avec vSphere vMotion activé
-
Correspondance des familles d’adresses IP du réseau de management (IPv4 ou IPv6) entre les hosts source et destination
Vous ne pouvez pas migrer une VM depuis un host enregistré dans vCenter avec une adresse IPv4 vers un host enregistré avec une adresse IPv6.
La copie d’un swap file vers un nouvel emplacement peut entraîner un ralentissement des migrations. Si le host de destination ne peut pas accéder à l’emplacement du swap file spécifié, il stocke le swap file avec le fichier de configuration de la VM.
-
Le nombre de tâches vSphere vMotion actives et concurrentes dépend de la vitesse du réseau vSphere vMotion :
— Chaque processus vSphere vMotion actif nécessite un débit minimum de 250 Mbit/seconde (Mbps) sur le réseau vSphere vMotion.
— Les migrations concurrentes sont limitées à 4 sur un réseau 1 Gbps.
— Les migrations concurrentes sont limitées à 8 sur un réseau 10 Gbps (ou plus rapide).
— Pour de meilleures performances, dédiez au moins deux groupes de ports VMkernel au trafic vSphere vMotion. -
CPUs compatibles :
— Les ensembles de fonctionnalités du CPU du host source et du host de destination doivent être compatibles.
— Certaines fonctionnalités peuvent être masquées en utilisant l’Enhanced vMotion Compatibility (EVC) ou des compatibility masks.
Pour plus de détails sur les exigences des hosts pour vSphere vMotion, consultez vCenter Server and Host Management : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Réalisation d’une migration vSphere vMotion
vSphere vMotion est utilisé pour déplacer une VM allumée vers un host différent.
Chaque fois que vous migrez une VM sous tension, vSphere vMotion effectue le travail de déplacement de la VM d’un host vers un autre. Le host est également appelé compute resource.
L’assistant Migrate propose plusieurs options pour déplacer une VM d’une compute resource à une autre :
- Change compute resource
- Change both compute resource and storage
- Cross vCenter Server export
Dans tous ces cas, si la VM migrée est sous tension, alors vSphere vMotion réalise la migration.
¶ Vérification des erreurs de migration
Lorsque vous sélectionnez le host ou le cluster, des vérifications de validation sont effectuées afin de s’assurer que la majorité des prérequis vSphere vMotion sont respectés.
Si la validation réussit, vous pouvez continuer dans l’assistant.
Si la validation échoue, une liste d’erreurs et d’avertissements vSphere vMotion s’affiche dans le volet Compatibility.
Avec des avertissements, vous pouvez tout de même effectuer une migration vSphere vMotion.
En revanche, avec des erreurs, vous ne pouvez pas continuer. Vous devez quitter l’assistant et corriger toutes les erreurs avant de relancer la migration.
Si une défaillance survient pendant la migration vSphere vMotion, la VM n’est pas migrée et continue de fonctionner sur le host source.
¶ Migration des VMs chiffrées
Lorsqu’elles sont sous tension, les VMs chiffrées sont migrées automatiquement à l’aide de encrypted vSphere vMotion.
Pour les VMs qui ne sont pas chiffrées, sélectionnez l’un des éléments suivants dans le menu encrypted vSphere vMotion :
- Disabled
- Opportunistic (default) : encrypted vSphere vMotion est utilisé si les hosts source et destination le prennent en charge
- Required : si le host source ou destination ne prend pas en charge encrypted vSphere vMotion, la migration échoue
Encrypted vSphere vMotion
- Garantit la confidentialité, l’intégrité et l’authenticité des données transférées lors d’une migration avec vSphere vMotion.
- Est pris en charge pour toutes les variantes de vSphere vMotion, y compris la migration cross-vCenter.
- Encrypted vSphere Storage vMotion n’est pas pris en charge.
- Pour les VMs chiffrées, encrypted vSphere vMotion ne peut pas être désactivé.
¶ Lab 20 : vSphere vMotion Migrations
Configurer le réseau vSphere vMotion et migrer des machines virtuelles en utilisant vSphere vMotion :
- Configurer le réseau vSphere vMotion sur sa-esxi-01.vclass.local
- Configurer le réseau vSphere vMotion sur sa-esxi-02.vclass.local
- Préparer les machines virtuelles pour la migration vSphere vMotion
- Migrer des machines virtuelles en utilisant vSphere vMotion
Retrouvez le lien du Lab en cliquant ici : Lab 20 : vSphere vMotion Migrations
¶ Revue des objectifs d’apprentissage
- Identifier les types de migrations de VM que vous pouvez effectuer au sein d’une instance vCenter
- Expliquer le fonctionnement de vSphere vMotion
- Vérifier les prérequis de vSphere vMotion
- Migrer des machines virtuelles en utilisant vSphere vMotion
¶ Leçon 2 : Configuration de Enhanced vMotion Compatibility
¶ Revue des objectifs d’apprentissage
- Décrire le rôle de Enhanced vMotion Compatibility dans les migrations
- Configurer le mode CPU EVC sur un cluster vSphere
- Expliquer comment le mode CPU EVC par VM fonctionne avec vSphere vMotion
- Configurer le mode Graphics EVC sur un cluster vSphere ou une VM
¶ Contraintes CPU lors d’une migration vSphere vMotion
La compatibilité CPU entre les hosts source et cible est une exigence de vSphere vMotion qui doit être respectée.
| Caractéristique | Correspondance exacte requise entre source host et target host | Raison |
|---|---|---|
| Vitesses d’horloge, tailles de cache, hyperthreading et nombre de cœurs | Non | Le VMkernel virtualise ces caractéristiques. |
| Fabricant (Intel ou AMD), famille et génération (Opteron4, Intel Westmere) | Oui | Les jeux d’instructions contiennent de nombreuses petites différences. |
| Présence ou absence d’instructions SSE3, SSSE3 ou SSE4.1 | Oui | Les instructions multimédias sont utilisables directement par les applications. |
| Assistance matérielle à la virtualisation | Pour les VM 32-bit : Non | Le VMkernel virtualise cette caractéristique. |
| Pour les VM 64-bit sur Intel : Oui | L’implémentation 64-bit Intel avec VMware utilise Intel VT. |
Selon la caractéristique CPU, une correspondance exacte entre le source host et le target host peut ou non être requise.
Par exemple, si l’hyperthreading est activé sur le source host et désactivé sur le destination host, la migration vSphere vMotion se poursuit, car le VMkernel gère cette différence de caractéristiques.
En revanche, si le processeur du source host prend en charge les instructions SSE4.1 et que celui du destination host ne les prend pas en charge, les hosts sont considérés comme incompatibles et la migration vSphere vMotion échoue. Les instructions SSE4.1 sont des instructions au niveau applicatif qui contournent la couche de virtualisation et peuvent provoquer une instabilité des applications en cas de non-correspondance après une migration avec vSphere vMotion.
¶ À propos de Enhanced vMotion Compatibility
Enhanced vMotion Compatibility est une fonctionnalité de cluster qui permet les migrations vSphere vMotion entre des hosts n’ayant pas des ensembles de fonctionnalités identiques.
Cette fonctionnalité utilise des CPU baselines pour configurer tous les processeurs du cluster activés pour Enhanced vMotion Compatibility.
Enhanced vMotion Compatibility vérifie que tous les hosts d’un cluster présentent le même ensemble de fonctionnalités CPU aux VM, même si les CPU des hosts diffèrent.
Enhanced vMotion Compatibility facilite la migration vSphere vMotion en toute sécurité à travers différentes générations de CPU. Avec Enhanced vMotion Compatibility, vous pouvez utiliser vSphere vMotion pour migrer des VM entre des CPU qui seraient autrement considérés comme incompatibles.
Avec Enhanced vMotion Compatibility, vCenter peut imposer la compatibilité vSphere vMotion entre tous les hosts d’un cluster en les forçant à exposer un ensemble commun de fonctionnalités CPU (baseline) aux VM. Une baseline est un ensemble de fonctionnalités CPU prises en charge par chaque host du cluster. Lorsque vous configurez Enhanced vMotion Compatibility, vous définissez tous les processeurs des hosts du cluster pour qu’ils présentent les fonctionnalités d’un processeur baseline. Après activation des fonctionnalités pour un cluster, les hosts qui y sont ajoutés sont automatiquement configurés selon la CPU baseline.
Les hosts qui ne peuvent pas être configurés selon la baseline ne sont pas autorisés à rejoindre le cluster. Les VM du cluster voient toujours un ensemble de fonctionnalités CPU identique, quel que soit le host sur lequel elles s’exécutent. Comme le processus est automatique, Enhanced vMotion Compatibility est simple à utiliser et ne requiert aucune connaissance spécialisée des fonctionnalités CPU ni des masks.
¶ Exigences de cluster EVC pour le mode CPU
Tous les hosts du cluster doivent satisfaire plusieurs exigences liées au CPU :
- Utiliser des CPU d’un seul fournisseur, soit Intel, soit AMD.
- Être activés pour la virtualisation matérielle : AMD-V ou Intel VT.
- Être activés pour la technologie d’exécution désactivée : AMD No eXecute (NX) ou Intel eXecute Disable (XD).
- Être configurés pour la migration vSphere vMotion.
Les applications dans les VM doivent être compatibles avec l’ID CPU.
Avant de créer un cluster Enhanced vMotion Compatibility, veuillez vous assurer que les hosts que vous souhaitez ajouter au cluster répondent aux exigences.
Enhanced vMotion Compatibility configure automatiquement les hosts dont les CPU disposent des technologies Intel FlexMigration et AMD-V Extended Migration afin qu’ils soient compatibles avec vSphere vMotion avec des hosts utilisant des CPU plus anciens.
Pour qu’Enhanced vMotion Compatibility fonctionne correctement, les applications dans les VM doivent être développées de manière à utiliser l’instruction machine CPU ID pour découvrir les fonctionnalités CPU, comme le recommandent les fabricants de CPU. vSphere ne peut pas prendre en charge Enhanced vMotion Compatibility avec des applications qui ne respectent pas les recommandations des fabricants de CPU pour la détection des fonctionnalités CPU.
Pour déterminer quels modes EVC sont compatibles avec votre CPU, consultez le VMware Compatibility Guide à l’adresse suivante : http://www.vmware.com/resources/compatibility. Recherchez le modèle de serveur ou la famille de CPU, puis cliquez sur l’entrée de la colonne CPU Series afin d’afficher les modes EVC compatibles.
¶ Configuration du mode CPU EVC sur un cluster existant
Vous configurez le mode CPU EVC sur un cluster existant afin de garantir la compatibilité CPU vSphere vMotion entre les hosts du cluster.
Vous pouvez utiliser l’une des méthodes suivantes pour créer un cluster Enhanced vMotion Compatibility :
- Créer un cluster vide avec le mode EVC configuré, puis y déplacer les hosts.
- Configurer le mode EVC sur un cluster existant.
Pour activer EVC sur un cluster existant, tous les hosts doivent être placés en mode maintenance. Par conséquent, toutes les VM du cluster existant doivent être éteintes ou suspendues. Afin d’éviter un temps d’arrêt des VM, la méthode recommandée pour activer EVC est d’activer cette fonctionnalité sur un cluster vide et nouveau.
Pour obtenir des informations sur la prise en charge des processeurs avec Enhanced vMotion Compatibility, veuillez consulter l’article de la base de connaissances VMware 1003212 à l’adresse suivante : http://kb.vmware.com/kb/1003212.
¶ Modification du mode CPU EVC pour un cluster
Plusieurs approches du mode EVC sont disponibles pour garantir la compatibilité CPU :
- Si tous les hosts d’un cluster sont compatibles avec un mode EVC plus récent, vous pouvez modifier le mode EVC d’un cluster Enhanced vMotion Compatibility existant.
- Vous pouvez configurer le mode EVC pour un cluster qui n’a pas encore de mode EVC configuré.
Vous pouvez augmenter ou diminuer le niveau du mode EVC, mais les VM doivent être dans l’état d’alimentation approprié pour effectuer cette opération.
| Mode EVC | Action sur l’alimentation des VM |
|---|---|
| Augmenter le mode EVC vers une CPU baseline avec plus de fonctionnalités | - Les VM en cours d’exécution peuvent rester allumées. - Les nouvelles fonctionnalités du mode EVC ne sont pas disponibles pour les VM tant qu’elles n’ont pas été éteintes puis rallumées (mettre en pause et reprendre la VM n’est pas suffisant). |
| Diminuer le mode EVC vers une CPU baseline avec moins de fonctionnalités | - Les VM doivent être éteintes si elles fonctionnent avec un mode EVC plus élevé que celui que vous souhaitez configurer. |
¶ Mode CPU EVC de la machine virtuelle
Le mode EVC peut être appliqué à certaines ou à toutes les machines virtuelles dans un cluster :
- Au niveau de la machine virtuelle, le mode EVC facilite la migration des machines virtuelles au-delà du cluster et à travers les systèmes vCenter et les centres de données.
- Vous pouvez appliquer des définitions plus granulaire de la compatibilité améliorée de vMotion pour des machines virtuelles spécifiques.
- Le mode EVC de la machine virtuelle est indépendant du mode EVC défini au niveau du cluster.
Avec le mode EVC par machine virtuelle, le mode EVC devient un attribut de la machine virtuelle plutôt que de la génération de processeur spécifique sur laquelle elle est démarrée dans le cluster. Cette fonctionnalité permet une migration transparente entre deux centres de données ayant des processeurs différents. De plus, la fonctionnalité est conservée par machine virtuelle et ne perd pas le mode EVC lors des migrations entre clusters ou des cycles d'alimentation.
Dans ce diagramme, le mode EVC n'est pas configuré au niveau du cluster. Le cluster est composé de modèles de CPU différents avec des ensembles de fonctionnalités variés. Les machines virtuelles avec le mode EVC par machine virtuelle peuvent s'exécuter sur n'importe quel hôte ESXi capable de satisfaire le mode EVC défini.
¶ Compatibilité vMotion améliorée pour les GPU vSGA
EVC peut également définir une base commune d'ensembles de fonctionnalités GPU dans un cluster.
Les fonctionnalités non incluses dans la base appliquée sont masquées et ne sont pas exposées aux machines virtuelles.
La compatibilité vMotion améliorée pour vSGA est prise en charge avec les GPU matériels ainsi que les moteurs de rendu GPU logiciels.
¶ Exigences du cluster EVC pour le mode graphique
EVC pour les GPU vSGA est configuré au niveau du cluster ESXi :
- Tous les hôtes ESXi doivent satisfaire aux exigences GPU de la base définie.
- Des hôtes supplémentaires ne peuvent pas rejoindre le cluster s'ils ne satisfont pas aux exigences de la base.
- Un cluster mixte d'hôtes ESXi 6.7 et ESXi 7.0 est pris en charge lors de l'utilisation de la compatibilité vMotion améliorée au niveau du cluster.
EVC pour les GPU vSGA est configuré au niveau de la machine virtuelle :
- La compatibilité des machines virtuelles pour ESXi 7.0 Update 1 est requise (version matérielle de la machine virtuelle 18).
- Les machines virtuelles utilisant la compatibilité vMotion améliorée au niveau de la machine virtuelle doivent fonctionner sur ESXi 7.0 Update 1.
¶ Configuration du mode graphique EVC sur un cluster existant
Au niveau du cluster, vous configurez EVC pour les vSGA de la même manière que l'EVC pour le CPU.
¶ Mode graphique EVC de la machine virtuelle
Au niveau de la machine virtuelle, vous configurez EVC pour les vSGA de la même manière que l'EVC pour le CPU.
¶ Revue des objectifs d’apprentissage
- Décrire le rôle de la compatibilité vMotion améliorée dans les migrations
- Configurer le mode EVC CPU sur un cluster vSphere
- Expliquer comment fonctionne le mode EVC CPU par machine virtuelle avec vSphere vMotion
- Configurer le mode graphique EVC sur un cluster vSphere ou une machine virtuelle
¶ Leçon 3 : Migration des machines virtuelles avec vSphere Storage vMotion
¶ Objectifs d’apprentissage
- Expliquer le fonctionnement de vSphere Storage vMotion
- Reconnaître les lignes directrices pour l’utilisation de vSphere Storage vMotion
- Migrer des machines virtuelles en utilisant vSphere Storage vMotion
- Migrer à la fois les ressources de calcul et de stockage d’une machine virtuelle
¶ À propos de vSphere Storage vMotion
Avec vSphere Storage vMotion, vous pouvez migrer une machine virtuelle sous tension d’un datastore à un autre, quel que soit le type de datastore.
En utilisant vSphere Storage vMotion, vous pouvez effectuer les tâches suivantes :
- Déplacer des machines virtuelles hors des baies pour maintenance ou pour une mise à jour.
- Changer le type de provisionnement du disque.
- Modifier les fichiers de la machine virtuelle sur le datastore de destination pour qu'ils correspondent au nom de l'inventaire de la machine virtuelle.
- Migrer entre les datastores pour équilibrer le trafic sur les chemins de stockage et réduire les latences.
- Redistribuer les machines virtuelles ou les disques virtuels vers différents volumes de stockage pour équilibrer la capacité ou améliorer les performances.
vSphere Storage vMotion offre une flexibilité permettant de déplacer les disques virtuels pour des raisons de performance ou de transformer les types de disques, ce que vous pouvez utiliser pour récupérer de l’espace.
Vous pouvez placer la machine virtuelle et tous ses disques dans un seul emplacement, ou vous pouvez sélectionner des emplacements séparés pour le fichier de configuration de la machine virtuelle et chaque disque virtuel. Lors d'une migration avec vSphere Storage vMotion, la machine virtuelle ne change pas d’hôte.
Que vous effectuiez une migration vSphere Storage vMotion ou une migration à froid, vous pouvez renommer les fichiers de la machine virtuelle sur le datastore de destination. La migration renomme tous les fichiers de disque virtuel, de configuration, de snapshot et les fichiers .nvram.
¶ vSphere Storage vMotion en action
vSphere Storage vMotion utilise une architecture de mise en miroir des entrées/sorties (I/O) pour copier les blocs de disque entre la source et la destination.
Une animation est disponible à cette adresse : https://vmware.bravais.com/s/FnHZwq043PJ8dV3ZRV7p.
Le processus de migration vSphere Storage vMotion comprend les étapes suivantes :
- Initier la migration du stockage.
- Utiliser le moteur de données VMkernel ou les APIs vSphere Storage – Intégration des baies pour copier les données.
- Démarrer un nouveau processus de machine virtuelle.
- Miroiter les appels I/O vers les blocs de fichiers déjà copiés sur le disque virtuel du datastore de destination.
- Passer au processus de la machine virtuelle de destination pour commencer à accéder à la copie du disque virtuel.
Le processus de migration du stockage effectue un seul passage du disque, copiant tous les blocs vers le disque de destination. Si des blocs sont modifiés après avoir été copiés, ces blocs sont synchronisés de la source vers la destination via le pilote de mise en miroir, sans besoin de passages récursifs.
Cette approche garantit une intégrité transactionnelle complète et est suffisamment rapide pour être imperceptible pour l'utilisateur final. Le pilote de mise en miroir utilise le moteur de données VMkernel pour copier les blocs de données du disque source vers le disque de destination. Le pilote de mise en miroir effectue de manière synchrone les écritures sur les deux disques pendant l'opération vSphere Storage vMotion.
Enfin, les opérations vSphere Storage vMotion sont effectuées soit en interne sur un seul hôte ESXi, soit déchargées vers la baie de stockage. Les opérations effectuées en interne sur l'hôte ESXi utilisent un moteur de données intégré au VMkernel. Les opérations sont déchargées vers la baie de stockage si celle-ci prend en charge les APIs vSphere Storage – Intégration des baies, également appelées accélération matérielle.
¶ Identification des baies de stockage prenant en charge les APIs vSphere Storage – Intégration des baies
vSphere Storage vMotion décharge ses opérations vers la baie de stockage si :
- La baie prend en charge les APIs vSphere Storage – Intégration des baies, également appelées accélération matérielle.
- Les deux datastores se trouvent dans la même baie de stockage.
Utilisez le client vSphere pour déterminer si votre baie de stockage prend en charge l'accélération matérielle.
¶ Lignes directrices et limitations de vSphere Storage vMotion
Lignes directrices :
- Planifiez la migration et coordonnez-vous avec les administrateurs.
- Effectuez les migrations pendant les heures creuses.
Limitation :
- Les disques de machine virtuelle indépendants doivent être en mode persistant.
Une machine virtuelle et son hôte doivent répondre à certaines exigences en matière de ressources et de configuration pour que les disques de la machine virtuelle (VMDK) puissent être migrés avec vSphere Storage vMotion. L'une des exigences est que l'hôte sur lequel la machine virtuelle fonctionne doit avoir accès à la fois au datastore source et au datastore cible.
Lors d'une migration avec vSphere Storage vMotion, vous pouvez changer le type de provisionnement du disque. La migration avec vSphere Storage vMotion modifie les fichiers de la machine virtuelle sur le datastore de destination pour qu'ils correspondent au nom de l'inventaire de la machine virtuelle. La migration renomme tous les fichiers de disque virtuel, de configuration, de snapshot et les fichiers .nvram. Si les nouveaux noms dépassent la longueur maximale autorisée pour les noms de fichier, la migration échoue.
¶ Changer à la fois les ressources de calcul et de stockage pendant la migration
Lorsque vous modifiez à la fois les ressources de calcul et le stockage pendant la migration, une machine virtuelle change à la fois d’hôte et de datastore, et éventuellement de réseau, que ce soit au sein d'une même instance de vCenter ou entre plusieurs instances.
- Cette technique combine vSphere vMotion et vSphere Storage vMotion en une seule opération.
- Vous pouvez migrer des machines virtuelles entre clusters, centres de données et instances de vCenter.
Vous pouvez migrer des machines virtuelles au-delà des limites d'accessibilité du stockage et entre des hôtes, au sein et entre des clusters, des centres de données et des instances de vCenter.
¶ Cas d’utilisation pour le changement à la fois des ressources de calcul et du stockage
La migration des ressources de calcul et du stockage est utile dans les cas suivants :
- Migrer une machine virtuelle située sur le stockage local d'un hôte vers un hôte utilisant du stockage partagé.
- Migrer une machine virtuelle vers un nouveau cluster, lorsque le cluster cible n'a pas accès au stockage du cluster source.
- Migrer une machine virtuelle vers un autre centre de données, dont le stockage n'est pas partagé avec celui du centre de données source.
- Migrer une machine virtuelle vers une autre instance de vCenter, dont le stockage n'est pas partagé avec celui de l'instance de vCenter source.
¶ Lab 21 : Migrations vSphere Storage vMotion
Utilisez vSphere Storage vMotion pour migrer des machines virtuelles :
- Migrer les fichiers de machine virtuelle d'un datastore à un autre
- Migrer à la fois les ressources de calcul et de stockage d'une machine virtuelle
Retrouvez le lien du Lab en cliquant ici : Lab 21 : Migrations vSphere Storage vMotion
¶ Revue des objectifs d’apprentissage
- Expliquer le fonctionnement de vSphere Storage vMotion
- Reconnaître les lignes directrices pour l’utilisation de vSphere Storage vMotion
- Migrer des machines virtuelles en utilisant vSphere Storage vMotion
- Migrer à la fois les ressources de calcul et de stockage d'une machine virtuelle
¶ Leçon 4 : Migrations entre vCenter
¶ Objectifs d’apprentissage
- Reconnaître les types de migrations de machines virtuelles que vous pouvez effectuer entre des instances de vCenter
¶ À propos des migrations entre vCenter
Avec vSphere vMotion, vous pouvez migrer des machines virtuelles entre des instances de vCenter, qu'elles soient ou non dans le même groupe Enhanced Linked Mode.
Les migrations entre vCenter sont utiles dans les cas suivants :
- Équilibrer les charges de travail entre des clusters et des instances de vCenter situés dans le même site ou dans une autre zone géographique.
- Déplacer des machines virtuelles entre des environnements ayant des objectifs différents, par exemple, d'un environnement de développement vers un environnement de production.
- Déplacer des machines virtuelles pour répondre à différents accords de niveau de service (SLA) concernant l'espace de stockage, les performances, etc.
- Déplacer des machines virtuelles d'un centre de données vSphere sur site vers un centre de données dans le cloud public, comme VMware Cloud sur AWS.
¶ Exigences des migrations entre vCenter
Les migrations entre vCenter ont les exigences suivantes :
- Les hôtes doivent être synchronisés au niveau du temps.
- Les deux instances de vCenter peuvent être dans le même domaine vCenter Single Sign-On ou dans des domaines différents.
Les migrations entre vCenter doivent répondre aux exigences suivantes :
- Les deux instances de vCenter doivent être synchronisées au niveau du temps pour une vérification correcte du jeton vCenter Single Sign-On.
- Les deux instances de vCenter n'ont pas besoin d'être dans le même groupe Enhanced Linked Mode.
- Pour la migration des ressources de calcul uniquement, les deux instances de vCenter doivent être connectées au stockage partagé sur lequel la machine virtuelle est située.
Vous pouvez effectuer des migrations entre vCenter avec des instances de versions différentes. Pour des informations sur les versions prises en charge, consultez l'article de la base de connaissances VMware 2106952 à l'adresse http://kb.vmware.com/kb/2106952.
¶ Effectuer un vMotion entre vCenter dans le même domaine SSO
Dans l'assistant de migration, sélectionnez une ressource de calcul dans l'instance de vCenter de destination.
¶ Effectuer un vMotion entre vCenter dans des domaines SSO différents
Dans l'assistant de migration, sélectionnez "Exportation Cross vCenter Server" comme type de migration.
Optionnellement, vous pouvez cloner la machine virtuelle plutôt que de la migrer.
Dans l'assistant de migration, vous spécifiez le FQDN ou l'adresse IP de l'instance de vCenter cible ainsi que les identifiants vCenter. Les autres options de l'assistant sont similaires à celles permettant de changer à la fois les ressources de calcul et le stockage : vous sélectionnez la ressource de calcul, le datastore et le réseau VM à utiliser dans l'instance de vCenter cible.
Ensuite, vous spécifiez le FQDN ou l'adresse IP de l'instance de vCenter cible ainsi que les identifiants vCenter.
Les autres options de l'assistant sont similaires à celles permettant de changer à la fois les ressources de calcul et le stockage : vous sélectionnez la ressource de calcul, le datastore et le réseau VM à utiliser dans l'instance de vCenter cible.
¶ Vérifications réseau pour les migrations entre vCenter
vCenter effectue plusieurs vérifications de compatibilité réseau pour éviter les problèmes de configuration suivants :
- Incompatibilité de l'adresse MAC sur l'hôte de destination
- Migration vSphere vMotion d'un switch distribué vers un switch standard
- Migration vSphere vMotion entre des switches distribués de versions différentes
¶ Couche réseau VMkernel et piles TCP/IP
La couche réseau VMkernel fournit la connectivité aux hôtes et gère le trafic système standard de vSphere vMotion, du stockage IP, de la tolérance de panne vSphere, de vSAN, et d'autres.
Les piles TCP/IP au niveau du VMkernel configurées par défaut sont :
- Pile TCP/IP par défaut
- Pile TCP/IP vSphere vMotion
- Pile TCP/IP de provisioning
Vous pouvez également créer une pile TCP/IP personnalisée.
Considérez les points clés suivants concernant les piles TCP/IP au niveau du VMkernel :
- Pile TCP/IP par défaut : Fournit la prise en charge réseau pour le trafic de gestion entre vCenter et les hôtes ESXi ainsi que pour le trafic système tel que vSphere vMotion, le stockage IP et la tolérance de panne vSphere.
- Pile TCP/IP vSphere vMotion : Prend en charge le trafic pour les migrations à chaud des machines virtuelles.
- Pile TCP/IP de provisioning : Prend en charge le trafic pour la migration à froid des machines virtuelles, le clonage et la création de snapshots. Vous pouvez utiliser la pile TCP/IP de provisioning pour gérer le trafic NFC lors de migrations vSphere vMotion longue distance. Les adaptateurs VMkernel configurés avec la pile TCP/IP de provisioning gèrent le trafic de clonage des disques virtuels des machines migrées lors de migrations vSphere vMotion longue distance.
En utilisant la pile TCP/IP de provisioning, vous pouvez isoler le trafic des opérations de clonage sur une passerelle séparée. Après avoir configuré un adaptateur VMkernel avec la pile TCP/IP de provisioning, tous les adaptateurs sur la pile TCP/IP par défaut sont désactivés pour le trafic de provisioning. - Piles TCP/IP personnalisées : Vous pouvez créer une pile TCP/IP personnalisée sur un hôte pour acheminer le trafic réseau via une application personnalisée. Ouvrez une connexion SSH à l'hôte et exécutez la commande CLI vSphere :
esxcli network ip netstack add -N="stack_name"
Prenez les mesures de sécurité appropriées pour empêcher l'accès non autorisé au trafic de gestion et au trafic système dans votre environnement vSphere. Par exemple, isolez le trafic vSphere vMotion dans un réseau séparé comprenant uniquement les hôtes ESXi participant à la migration. Isolez le trafic de gestion dans un réseau auquel seuls les administrateurs réseau et de sécurité peuvent accéder.
¶ Piles TCP/IP vSphere vMotion
Chaque hôte ESXi dispose d'une seconde pile TCP/IP dédiée à la migration vSphere vMotion.
Les piles TCP/IP vSphere vMotion prennent en charge le trafic pour les migrations à chaud des machines virtuelles. Utilisez la pile TCP/IP vSphere vMotion pour offrir une meilleure isolation du trafic vSphere vMotion. Après avoir créé un adaptateur VMkernel sur la pile TCP/IP vSphere vMotion, vous ne pouvez utiliser que cette pile pour la migration vSphere vMotion sur cet hôte.
Les adaptateurs VMkernel sur la pile TCP/IP par défaut sont désactivés pour le service vSphere vMotion après la création d'un adaptateur VMkernel sur la pile TCP/IP vSphere vMotion. Si une migration à chaud utilise la pile TCP/IP par défaut pendant que vous configurez les adaptateurs VMkernel avec la pile TCP/IP vMotion, la migration se termine avec succès. Cependant, ces adaptateurs VMkernel sur la pile TCP/IP par défaut sont désactivés pour les futures sessions vSphere vMotion.
¶ À propos de la migration vSphere vMotion longue distance
La migration vSphere vMotion longue distance est une extension de la migration entre vCenter.
Les instances de vCenter sont réparties sur de grandes distances géographiques et où la latence entre les sites est élevée.
Cas d'utilisation pour la migration vSphere vMotion longue distance :
- Migrations permanentes
- Prévention des sinistres
- Tests de Site Recovery Manager et de prévention des sinistres
- Répartition de charge multisite
- Prise en charge des scénarios "Follow-the-sun"
Dans le scénario "Follow-the-sun", une équipe de support mondiale peut prendre en charge un ensemble spécifique de machines virtuelles. Lorsque l'une des équipes de support termine sa journée de travail, une autre équipe située dans un autre fuseau horaire prend le relais. Les machines virtuelles prises en charge peuvent être déplacées d'un emplacement géographique à un autre, de manière à ce que l'équipe de support en service puisse accéder localement à ces machines virtuelles plutôt qu'à distance.
¶ Prérequis réseau pour la migration vSphere vMotion longue distance
Les migrations vSphere vMotion longue distance doivent se connecter via des connexions de couche 3 :
- Réseau de la machine virtuelle :
— Connexion L2
— La même adresse IP de la machine virtuelle est disponible à la destination - Réseau vSphere vMotion :
— Connexion L3
— 250 Mbps par opération vSphere vMotion
— Le temps de parcours aller-retour entre les hôtes peut atteindre jusqu'à 150 millisecondes.
¶ Revue des objectifs d’apprentissage
- Reconnaître les types de migrations de machines virtuelles que vous pouvez effectuer entre les instances de vCenter
¶ Leçon 5 : Créer des snapshots de machines virtuelles
¶ Objectifs d'apprentissage
- Prendre un snapshot d'une machine virtuelle
- Gérer plusieurs snapshots
- Supprimer des snapshots de machines virtuelles
- Consolider les snapshots
¶ À propos des snapshots de machines virtuelles
Avec les snapshots, vous pouvez préserver l'état de la machine virtuelle afin de pouvoir y revenir de manière répétée.
Par exemple, si des problèmes surviennent pendant le processus de mise à jour ou de mise à niveau, vous pouvez revenir à l'état précédent.
Les snapshots de machines virtuelles ne sont pas recommandés comme stratégie de sauvegarde pour les machines virtuelles.
Les snapshots sont utiles lorsque vous souhaitez revenir de manière répétée au même état sans créer plusieurs machines virtuelles. Des exemples incluent la mise à jour ou la mise à niveau du système d'exploitation invité dans une machine virtuelle.
La relation entre les snapshots est similaire à celle entre un parent et un enfant. Les snapshots sont organisés sous forme d'un arbre de snapshots. Dans un arbre de snapshots, chaque snapshot a un parent et un ou plusieurs enfants, sauf pour le dernier snapshot, qui n'a pas d'enfants.
¶ Prendre des snapshots
Vous pouvez prendre un snapshot lorsqu'une VM est allumée, éteinte ou suspendue.
Un snapshot capture les éléments suivants :
- Configuration de la VM
- État de la mémoire de la VM (facultatif)
- Disques virtuels
Une capture de snapshot n'inclut pas les disques virtuels indépendants (persistants et non persistants).
Un snapshot capture l’état complet de la VM au moment où vous prenez le snapshot, y compris les états suivants :
- État de la mémoire : Le contenu de la mémoire de la VM. L’état de la mémoire est capturé uniquement si la VM est allumée et si vous sélectionnez la case à cocher "Snapshot the virtual machine’s memory" (sélectionnée par défaut).
- État des paramètres : Les paramètres de la VM.
- État des disques : L’état de tous les disques virtuels de la VM.
Au moment où vous prenez le snapshot, vous pouvez également quiescer le système d'exploitation invité. Cette action quiesce le système de fichiers du système d'exploitation invité. Cette option n'est disponible que si vous ne capturez pas l'état de la mémoire dans le snapshot.
¶ Types de snapshots
Un disque delta ou enfant est créé lorsque vous créez un snapshot :
- Sur le datastore, le disque delta est un disque sparse.
- Les disques delta utilisent différents formats sparse selon le type de datastore.
| Type de snapshot | Type de datastore | Nom de fichier | Taille de bloc |
|---|---|---|---|
| VMFSsparse | • VMFS5 avec des disques virtuels de moins de 2 To | #-delta.vmdk | 512 octets |
| SEsparse | • VMFS6 | #-sesparse.vmdk | 4 Ko |
| • VMFS5 avec des disques virtuels de plus de 2 To | |||
| • Économie d'espace (provisionnement mince) | |||
| • Prend en charge la récupération de l'espace (unmap) | |||
| vsanSparse | • vSAN | Delta object | 4 Mo |
Les disques delta utilisent différents formats sparse en fonction du type de datastore.
-
VMFSsparse : VMFS5 utilise le format VMFSsparse pour les disques virtuels de moins de 2 To. VMFSsparse est implémenté au-dessus de VMFS. La couche VMFSsparse traite les opérations I/O émises vers une VM de snapshot. Techniquement, VMFSsparse est un journal de réécriture qui commence vide, immédiatement après qu'un snapshot de la VM soit pris. Le journal de réécriture s'étend à la taille de son VMDK de base, lorsque l'intégralité du VMDK est réécrite avec de nouvelles données après le snapshot de la VM. Ce journal de réécriture est un fichier dans le datastore VMFS. Lors de la création du snapshot, le VMDK de base attaché à la VM est modifié pour le VMDK sparse nouvellement créé.
-
SEsparse : SEsparse est le format par défaut pour tous les disques delta sur les datastores VMFS6. Sur VMFS5, SEsparse est utilisé pour les disques virtuels de 2 To et plus. SEsparse est un format similaire à VMFSsparse, mais avec quelques améliorations. Ce format est efficace en termes d'espace et prend en charge la technique de récupération d'espace. Avec la récupération d'espace, les blocs supprimés par le système d'exploitation invité sont marqués. Le système envoie des commandes à la couche SEsparse dans l'hyperviseur pour "unmapper" (désallouer) ces blocs. Le processus de désallocation permet de récupérer l'espace alloué par SEsparse après que le système d'exploitation invité ait supprimé les données.
¶ Fichiers de Snapshot
Un snapshot se compose d'un ensemble de fichiers :
- -Snapshot#.vmsn : État de la configuration
- -Snapshot#.vmem : État de la mémoire (facultatif)
- -00000#.vmdk : Descripteur de disque
- -00000#-delta.vmdk : Delta VMFS5
- -00000#-sesparse.vmdk : Delta VMFS6
- .vmsd : Stocke les noms, descriptions et relations pour tous les snapshots de la VM
Une VM peut avoir un ou plusieurs snapshots. Pour chaque snapshot, les fichiers suivants sont créés :
- Fichier delta de snapshot : Ce fichier contient les modifications des données du disque virtuel depuis la prise du snapshot. Lorsque vous prenez un snapshot d'une VM, l'état de chaque disque virtuel est préservé. La VM arrête d’écrire dans son fichier
-flat.vmdk. Les écritures sont redirigées vers-######-delta.vmdk(ou-######-sesparse.vmdk) à la place (où######est le prochain numéro dans la séquence). Vous pouvez exclure un ou plusieurs disques virtuels d’un snapshot en les désignant comme disques indépendants. La configuration d’un disque virtuel en tant qu’indépendant se fait généralement lors de la création du disque virtuel, mais cette option peut être modifiée chaque fois que la VM est éteinte. - Fichier descripteur de disque :
-00000#.vmdk. Ce fichier est un petit fichier texte qui contient des informations sur le snapshot. - Fichier d'état de configuration :
-.vmsn. Le#est le prochain numéro dans la séquence, à partir de 1. Ce fichier contient l'état actif de la mémoire de la VM au moment où le snapshot a été pris, y compris le matériel virtuel, l'état de l'alimentation et la version du matériel. - Fichier d'état de la mémoire :
-.vmem. Ce fichier est créé si l'option pour inclure l'état de la mémoire a été sélectionnée lors de la création du snapshot. Il contient l'intégralité du contenu de la mémoire de la VM au moment où le snapshot a été pris. - Fichier de mémoire active du snapshot :
-.vmem. Ce fichier contient le contenu de la mémoire de la VM si l'option d'inclure la mémoire est sélectionnée lors de la création du snapshot. - Le fichier .vmsd est le fichier de la liste des snapshots et est créé au moment où la VM est créée. Il maintient les informations sur les snapshots d’une VM pour pouvoir créer une liste de snapshots dans le vSphere Client. Ces informations comprennent le nom du fichier
.vmsndu snapshot et le nom du fichier de disque virtuel. - Le fichier d'état du snapshot a l'extension
.vmsnet est utilisé pour stocker l'état d’une VM lors de la prise du snapshot. Un nouveau fichier.vmsnest créé pour chaque snapshot pris sur une VM et est supprimé lorsque le snapshot est supprimé. La taille de ce fichier varie, en fonction des options sélectionnées lors de la création du snapshot. Par exemple, inclure l'état de la mémoire de la VM dans le snapshot augmente la taille du fichier.vmsn.
Vous pouvez exclure un ou plusieurs des VMDKs d'un snapshot en désignant un disque virtuel de la VM comme un disque indépendant. Placer un disque virtuel en mode indépendant se fait généralement lors de la création du disque virtuel. Si le disque virtuel a été créé sans activer le mode indépendant, vous devez éteindre la VM pour l'activer.
D'autres fichiers peuvent également exister, en fonction de la version du matériel de la VM. Par exemple, chaque snapshot d'une VM allumée a un fichier _.vmem associé, qui contient la mémoire principale du système d'exploitation invité, sauvegardée dans le cadre du snapshot.
¶ Exemple de fichiers de snapshot de la VM
Cet exemple montre les fichiers de snapshot et de disque virtuel qui sont créés lorsqu'une VM n'a pas de snapshots.
Cet exemple montre les fichiers de snapshot et de disque virtuel qui sont créés lorsqu'une VM a un snapshot.
Cet exemple montre les fichiers de snapshot et de disque virtuel qui sont créés lorsqu'une VM a deux snapshots.
¶ Gestion des Snapshots
Dans le vSphere Client, vous pouvez voir les snapshots de la VM active et effectuer des actions telles que modifier, supprimer et revenir à un snapshot.
Vous pouvez effectuer les actions suivantes depuis la fenêtre Gérer les Snapshots :
- Modifier le snapshot : Modifier le nom et la description du snapshot.
- Supprimer le snapshot : Retirer le snapshot du gestionnaire de snapshots, consolider les fichiers de snapshot avec le disque du snapshot parent et les fusionner avec le disque de base de la VM.
- Supprimer tous les snapshots : Valider tous les snapshots intermédiaires avant l'icône de l'état actuel (Vous êtes ici) et supprimer tous les snapshots pour cette VM.
- Revenir à un snapshot : Restaurer ou revenir à un snapshot particulier. Le snapshot que vous restaurez devient le snapshot actuel.
Lorsque vous revenez à un snapshot, tous ces éléments sont ramenés à l'état dans lequel ils se trouvaient au moment où vous avez pris le snapshot. Si vous souhaitez que la VM soit suspendue, allumée ou éteinte lorsque vous la redémarrez, assurez-vous que la VM soit dans l'état correct lors de la prise du snapshot.
Supprimer un snapshot (SUPPRIMER ou SUPPRIMER TOUS) consolide les modifications entre les snapshots et les états précédents des disques. Supprimer un snapshot écrit également toutes les données du disque delta contenant les informations sur le snapshot supprimé dans le disque parent. Lorsque vous supprimez le snapshot parent de base, toutes les modifications sont fusionnées avec le VMDK de base.
¶ Suppression des Snapshots de la VM
Si vous supprimez un snapshot situé un ou plusieurs niveaux au-dessus du niveau Vous êtes ici, l'état du snapshot est supprimé. Dans cet exemple, les données du snap01 sont intégrées dans le disque parent (disque de base), et la base pour le snap02 est conservée.
Une animation est disponible à cette adresse : https://vmware.bravais.com/s/WhbcXR4sSwk2Vl7MeaXD
Si vous supprimez le dernier snapshot, les modifications sont intégrées dans son parent. Les données de snap02 sont intégrées dans les données de snap01, et le fichier snap02-delta.vmdk est supprimé.
Une animation est disponible à cette adresse : https://vmware.bravais.com/s/l0JYYQzMTv7pvxBqNcQp
Si vous supprimez un snapshot situé un ou plusieurs niveaux en dessous du niveau Vous êtes ici, les snapshots suivants sont supprimés, et vous ne pouvez plus revenir à ces états. Les données de snap02 sont supprimées.
Une animation est disponible à cette adresse : https://vmware.bravais.com/s/NiQxPT3iycemQ8WYXKom
¶ Suppression de tous les Snapshots de la VM
Le mécanisme de suppression de tous les snapshots utilise l'espace de stockage de manière efficace. La taille du disque de base n'augmente pas. Snap01 est intégré dans le disque de base avant que snap02 ne soit intégré.
Une animation est disponible à cette adresse : https://vmware.bravais.com/s/L3ilQHlrywEhIgr5p7RP
Tous les snapshots avant le point Vous êtes ici sont intégrés jusqu'au disque de base. Tous les snapshots après Vous êtes ici sont supprimés.
Comme pour la suppression d'un seul snapshot, les blocs modifiés dans le snapshot écrasent leurs homologues dans le disque de base.
¶ À propos de la Consolidation des Snapshots
La consolidation des snapshots est une méthode permettant d'intégrer une chaîne de disques delta dans les disques de base lorsque le gestionnaire de snapshots montre qu'aucun snapshot n'existe, mais que les fichiers delta des disques restent sur le datastore.
La consolidation des snapshots résout les problèmes qui peuvent survenir avec les snapshots :
- Le fichier descripteur du snapshot est correctement intégré, et la fenêtre des snapshots montre que tous les snapshots ont été supprimés.
- Les fichiers de snapshot (
-delta.vmdkou-sesparse.vmdk) existent toujours dans le dossier de la VM sur le datastore. - Les fichiers de snapshot peuvent continuer à se développer jusqu'à atteindre la taille du fichier
-flat.vmdkou jusqu'à ce que l'espace du datastore soit épuisé.
La consolidation des snapshots est une méthode pour nettoyer les fichiers de disques delta inutiles d'un datastore. Si aucun snapshot n'est enregistré pour une VM, mais que des fichiers delta existent, la consolidation des snapshots intègre la chaîne des fichiers delta et les supprime.
Si la consolidation n'est pas effectuée, les fichiers de disques delta peuvent se développer au point de consommer tout l'espace restant sur le datastore de la VM ou que le fichier delta atteigne sa taille configurée. Le fichier delta ne peut pas être plus grand que la taille configurée pour le disque de base.
¶ Découvrir quand Consolider les Snapshots
Dans l'onglet Surveillance sous Tous les problèmes pour la VM, un avertissement vous notifie qu'une consolidation est nécessaire.
Avec la consolidation des snapshots, vCenter affiche un avertissement lorsque le fichier descripteur et les fichiers de snapshot ne correspondent pas. Après l'affichage de l'avertissement, vous pouvez utiliser le vSphere Client pour intégrer les snapshots.
¶ Consolidation des Snapshots
Après l'apparition de l'avertissement de consolidation des snapshots, vous pouvez utiliser le vSphere Client pour consolider les snapshots.
Tous les disques delta des snapshots sont intégrés dans les disques de base.
Pour une liste des meilleures pratiques concernant l'utilisation des snapshots dans un environnement vSphere, consultez l'article de la base de connaissances VMware 1025279 sur http://kb.vmware.com/kb/1025279.
¶ Lab 22 : Travailler avec les Snapshots
Prenez des snapshots de la VM, revenez à un autre snapshot et supprimez des snapshots :
- Prendre des snapshots d'une machine virtuelle
- Ajouter des fichiers et prendre un autre snapshot d'une machine virtuelle
- Revenir à un snapshot de la machine virtuelle
- Supprimer un snapshot
- Supprimer tous les snapshots
Retrouvez le lien du Lab en cliquant ici : Lab 22 : Travailler avec les Snapshots
¶ Revue des objectifs d'apprentissage
- Prendre un snapshot d'une machine virtuelle
- Gérer plusieurs snapshots
- Supprimer des snapshots de machine virtuelle
- Consolider des snapshots
¶ Leçon 6 : Concepts de CPU Virtuel et de Mémoire
¶ Objectifs d'apprentissage
- Décrire les concepts de CPU et de mémoire en relation avec un environnement virtualisé
- Reconnaître les techniques pour traiter la surconsommation des ressources mémoire
- Identifier les technologies supplémentaires qui améliorent l'utilisation de la mémoire
- Décrire le fonctionnement de VMware Virtual SMP
- Expliquer comment le VMkernel utilise l'hyperthreading
¶ Bases de la Virtualisation de la Mémoire
vSphere possède les couches de mémoire suivantes :
- La mémoire virtuelle du système d'exploitation invité est présentée aux applications par le système d'exploitation.
- La mémoire physique du système d'exploitation invité est présentée à la machine virtuelle par le VMkernel.
- La mémoire de la machine hôte, gérée par le VMkernel, fournit un espace mémoire contigu et adressable utilisé par la machine virtuelle.
Lorsque vous exécutez une machine virtuelle, le VMkernel crée un espace mémoire contigu et adressable pour la VM. Cet espace mémoire possède les mêmes propriétés que l'espace d'adresses mémoire virtuelle présenté aux applications par le système d'exploitation invité. Cet espace mémoire permet au VMkernel d'exécuter plusieurs VMs simultanément tout en protégeant la mémoire de chaque VM contre l'accès par d'autres. Du point de vue d'une application exécutée dans la VM, le VMkernel ajoute un niveau supplémentaire de traduction d'adresses qui mappe l'adresse physique de l'invité à l'adresse physique de l'hôte.
¶ Surconsommation de Mémoire des VMs
La mémoire est surconsommée lorsque l'empreinte mémoire combinée de toutes les VMs allumées dépasse la taille de la mémoire de l'hôte.
Lorsque la mémoire est surconsommée :
- Les VMs n'utilisent pas toujours toute leur mémoire allouée
- Pour améliorer l'utilisation de la mémoire, un hôte ESXi récupère de la mémoire des VMs inactives pour l'allouer aux VMs qui ont besoin de plus de mémoire
- La mémoire des VMs peut être échangée (swap) dans le fichier
.vswp - Les frais généraux de mémoire des VMs peuvent être échangés dans le fichier
vmx-*.vswp
Les tailles totales de mémoire configurées de toutes les VMs peuvent dépasser la quantité de mémoire physique disponible sur l'hôte. Cependant, cette condition ne signifie pas nécessairement que la mémoire est surconsommée. La mémoire est surconsommée lorsque la taille de la mémoire de travail de toutes les VMs dépasse la taille de la mémoire physique de l'hôte ESXi.
En raison des techniques de gestion de la mémoire utilisées par l'hôte ESXi, vos VMs peuvent utiliser plus de RAM virtuelle que la RAM physique disponible sur l'hôte. Par exemple, vous pouvez avoir un hôte avec 32 Go de mémoire et trois VMs fonctionnant avec 12 Go de mémoire chacune. Dans ce cas, la mémoire est surconsommée. Si les trois VMs sont inactives, la mémoire consommée combinée est inférieure à 32 Go. Cependant, si toutes les VMs consomment activement de la mémoire, leur empreinte mémoire peut dépasser les 32 Go et l'hôte ESXi devient surconsommé.
Un hôte ESXi peut manquer de mémoire si les VMs consomment toute la mémoire réservable dans un environnement de mémoire surconsommée. Bien que les VMs allumées ne soient pas affectées, une nouvelle VM pourrait échouer à s'allumer en raison du manque de mémoire. La surconsommation est logique car, généralement, certaines VMs sont légèrement chargées tandis que d'autres sont plus fortement chargées, et les niveaux d'activité relatifs varient dans le temps.
La mémoire de la VM depuis ce fichier est échangée (swap) sur le disque lorsque la mémoire de la machine hôte est surconsommée. La mémoire supplémentaire d'une VM est placée dans un fichier d'échange avec l'extension .vswp. L'hôte utilise le fichier d'échange vmx-*.vswp pour rassembler et suivre les frais généraux de mémoire. Les frais généraux de mémoire font référence à la mémoire utilisée par le processus VMX (VM Executable).
¶ Techniques de Surconsommation de Mémoire
Un hôte ESXi utilise des techniques de surconsommation de mémoire pour permettre la surconsommation de mémoire tout en évitant, si possible, la nécessité de paginer la mémoire sur le disque.
| | Méthodes Utilisées par l'Hôte ESXi |
| Méthode | Détails |
|---|---|
| Partage de pages transparent | Cette méthode économise l'utilisation des pages mémoire physiques. Dans cette méthode, les pages ayant des contenus identiques sont stockées une seule fois. |
| Ballooning | Cette méthode utilise le pilote ballon VMware Tools pour désallouer de la mémoire des machines virtuelles. Le mécanisme de ballooning devient actif lorsque la mémoire est insuffisante, obligeant parfois les VMs à utiliser leurs propres zones de pagination. |
| Compression de mémoire | Cette méthode réduit l'empreinte mémoire d'une VM en stockant la mémoire dans un format compressé. |
| Échange SSD au niveau de l'hôte | L'hôte ESXi peut échanger la mémoire vers des disques à état solide (SSD) attachés localement. |
| Pagination de mémoire de VM sur disque | L'utilisation de l'espace d'échange du VMkernel est le dernier recours en raison de la mauvaise performance. |
Le VMkernel utilise diverses techniques pour réduire dynamiquement la quantité de RAM physique requise pour chaque VM. Chaque technique est décrite dans l'ordre dans lequel elle est utilisée par le VMkernel :
- Page sharing : ESXi peut utiliser une technique propriétaire pour partager de manière transparente les pages de mémoire entre les VMs, éliminant ainsi les copies redondantes des pages de mémoire. Bien que les pages soient partagées par défaut au sein des VMs, depuis vSphere 6.0, les pages ne sont plus partagées par défaut entre les VMs.
- Ballooning : Si la mémoire de l'hôte commence à être insuffisante et que l'utilisation de la mémoire de la VM approche de son objectif, ESXi utilise le ballooning pour réduire les besoins en mémoire de cette VM. En utilisant le module
vmmemctlfourni par VMware, installé dans le système d'exploitation invité dans le cadre de VMware Tools, ESXi peut amener le système d'exploitation invité à libérer les pages de mémoire qu'il considère comme les moins importantes. Le ballooning offre des performances proches de celles d'un système natif sous des contraintes de mémoire similaires. Pour utiliser le ballooning, le système d'exploitation invité doit être configuré avec un espace de swap suffisant. - Memory compression : Si l'utilisation de la mémoire de la VM approche du niveau où un swap au niveau de l'hôte est nécessaire, ESXi utilise la compression de mémoire pour réduire le nombre de pages de mémoire qu'il doit échanger. Parce que la latence de décompression est bien plus faible que la latence de swap-in, la compression des pages de mémoire a un impact significativement moins important sur les performances que l'échange de ces pages.
- Swap to host cache : Le host swap cache est une technique optionnelle de récupération de mémoire qui utilise le stockage flash local pour mettre en cache les pages de mémoire d'une machine virtuelle. En utilisant le stockage flash local, la machine virtuelle évite la latence associée à un réseau de stockage qui pourrait être utilisé si elle échangeait les pages de mémoire vers le fichier de swap virtuel (
.vswp). - Regular host-level swapping : Lorsque la pression sur la mémoire est élevée et que l'hyperviseur doit échanger des pages de mémoire sur disque, l'hyperviseur effectue le swap vers un host swap cache plutôt que vers un fichier
.vswp. Lorsqu'un hôte manque d'espace sur le host cache, la mémoire mise en cache d'une machine virtuelle est migrée vers le fichier.vswprégulier de la machine virtuelle. Chaque hôte doit avoir son propre host swap cache configuré.
¶ Configuration des VMs multicœurs
Vous pouvez créer des VMs avec plusieurs processeurs virtuels (vCPUs). Le nombre de vCPUs que vous configurez pour une seule VM dépend de l'architecture physique de l'hôte ESXi.
En plus de la configuration physique de l'hôte, le nombre de vCPUs configurés pour une VM dépend également du système d'exploitation invité, des besoins et des limites d'évolutivité des applications, ainsi que du cas d'utilisation spécifique de la VM elle-même.
Le VMkernel comprend un planificateur de CPU qui planifie dynamiquement les vCPUs sur les CPUs physiques du système hôte.
Le planificateur VMkernel prend en compte la topologie socket-core-thread lorsqu'il prend des décisions de planification. Les processeurs Intel et AMD combinent plusieurs cœurs de processeur dans un seul circuit intégré, appelé socket dans cette discussion.
Un socket est un seul paquet avec un ou plusieurs CPUs physiques. Chaque cœur possède un ou plusieurs logical CPUs (LCPU dans le diagramme) ou threads. Avec les logical CPUs, le cœur peut planifier un thread d'exécution.
Sur la diapositive, le premier système est un système monocœur à double socket avec deux cœurs et, par conséquent, deux logical CPUs.
Lorsqu'un vCPU d'une VM à vCPU unique ou multi-vCPUs doit être planifié, le VMkernel associe le vCPU à un processeur logique disponible.
¶ À propos de l'Hyperthreading
Avec l'hyperthreading, un cœur peut exécuter deux threads ou ensembles d'instructions en même temps :
- L'hyperthreading fournit plus de logical CPUs sur lesquels les vCPUs peuvent être planifiés.
- L'hyperthreading est activé par défaut.
Pour activer l'hyperthreading :
- Vérifiez que le système hôte prend en charge l'hyperthreading.
- Activez l'hyperthreading dans le BIOS du système.
- Assurez-vous que l'hyperthreading pour l'hôte ESXi est activé.
Si l'hyperthreading est activé, ESXi peut planifier deux threads en même temps sur chaque cœur de processeur (CPU physique). L'inconvénient de l'hyperthreading est qu'il ne double pas la puissance d'un cœur. Ainsi, si les deux threads d'exécution nécessitent les mêmes ressources sur le cœur en même temps, l'un des threads doit attendre. Cependant, sur les systèmes utilisant la technologie hyperthreading, les performances sont améliorées.
Un hôte ESXi activé pour l'hyperthreading doit se comporter presque exactement comme un système standard. Les logical processors sur le même cœur ont des numéros de CPU adjacents. Les logical processors 0 et 1 sont sur le premier cœur, les logical processors 2 et 3 sont sur le deuxième cœur, et ainsi de suite.
Consultez la documentation matérielle du système hôte pour vérifier si le BIOS inclut la prise en charge de l'hyperthreading. Ensuite, activez l'hyperthreading dans le BIOS du système. Certains fabricants appellent cette option Logical Processor, tandis que d'autres l'appellent Enable Hyperthreading.
Utilisez le vSphere Client pour vous assurer que l'hyperthreading est activé pour votre hôte. Pour accéder à l'option d'hyperthreading, allez dans l'onglet Résumé de l'hôte et sélectionnez CPUs sous Hardware.
¶ Équilibrage de la charge CPU
Le VMkernel équilibre le temps processeur pour garantir que la charge est répartie de manière fluide sur les cœurs de processeur du système.
Le planificateur de CPU peut utiliser chaque logical processor indépendamment pour exécuter des VMs, offrant des capacités similaires à celles des systèmes de symmetric multiprocessing (SMP) traditionnels. Le VMkernel gère intelligemment le temps processeur pour garantir que la charge est répartie de manière fluide sur les cœurs de processeur du système. Toutes les 2 à 40 millisecondes (selon la topologie socket-core-thread), le VMkernel cherche à migrer les vCPUs d'un logical processor à un autre pour maintenir l'équilibre de la charge.
Le VMkernel fait de son mieux pour planifier les VMs avec plusieurs vCPUs sur deux cœurs différents, plutôt que sur deux logical processors du même cœur. Cependant, si nécessaire, le VMkernel peut associer deux vCPUs de la même VM à des threads sur le même cœur.
Si un logical processor n'a pas de travail, il est mis dans un état arrêté. Cette action libère ses ressources d'exécution, et la VM s'exécutant sur l'autre logical processor du même cœur peut utiliser l'intégralité des ressources d'exécution du cœur. Étant donné que le planificateur VMkernel prend en compte ce temps d'arrêt, une VM qui fonctionne avec les ressources complètes d'un cœur se voit attribuer plus de ressources qu'une VM fonctionnant sur un demi-cœur. Cette approche de gestion des processeurs garantit que le serveur ne viole pas les règles d'allocation des ressources ESXi.
¶ Revue des objectifs d’apprentissage
- Décrire les concepts de CPU et de mémoire en relation avec un environnement virtualisé
- Reconnaître les techniques pour gérer la surcharge des ressources mémoire
- Identifier les technologies supplémentaires qui améliorent l’utilisation de la mémoire
- Décrire le fonctionnement de VMware Virtual SMP
- Expliquer comment le VMkernel utilise l'hyperthreading
¶ Leçon 7 : Contrôles des ressources
¶ Objectifs d’apprentissage
- Assigner des valeurs de partages pour les ressources CPU et mémoire
- Décrire comment les machines virtuelles se disputent les ressources
- Définir les réservations et les limites CPU et mémoire
¶ Réservations, Limites et Partages
Au-delà des ressources CPU et mémoire configurées pour une VM, vous pouvez appliquer des paramètres d'allocation de ressources à une VM pour contrôler la quantité de ressources allouées :
- Une réservation spécifie l'allocation minimale garantie pour une VM
- Une limite spécifie une borne supérieure pour le CPU ou la mémoire qui peut être allouée à une VM
- Un partage est une valeur qui spécifie la priorité relative ou l'importance de l'accès d'une VM à une ressource donnée
Parce que les VMs utilisent simultanément les ressources d'un hôte ESXi, une concurrence pour les ressources peut se produire.
Pour gérer les ressources de manière efficace, vSphere fournit des mécanismes permettant de donner moins, plus ou une quantité égale d'accès à une ressource définie. vSphere empêche également une VM de consommer une grande quantité de ressources. vSphere accorde une quantité garantie de ressources à une VM dont les performances ne sont pas suffisantes ou qui nécessite une certaine quantité de ressources pour fonctionner correctement.
Lorsque la mémoire ou le CPU de l'hôte est surchargé, l'objectif d'allocation d'une VM se situe entre sa réservation spécifiée et sa limite spécifiée, en fonction des partages de la VM et de la charge du système. vSphere utilise un algorithme d'allocation basé sur les partages pour assurer une utilisation efficace des ressources pour toutes les VMs et garantir une ressource donnée aux VMs qui en ont le plus besoin.
¶ Allocation des ressources : Réservations de RAM
Réservations de RAM :
- La mémoire réservée à une VM est garantie de ne jamais être échangée (swap) ou utilisée pour le ballooning.
- Si un hôte ESXi n'a pas suffisamment de RAM non réservée pour supporter une VM avec une réservation, la VM ne se met pas sous tension.
- Les réservations sont mesurées en Mo, Go ou To. La valeur par défaut est de 0 Mo.
Lors de la configuration d'une réservation de mémoire pour une VM, vous pouvez spécifier la quantité de mémoire configurée pour la VM afin de réserver toute la mémoire de la VM. Par exemple, si une VM est configurée avec 4 Go de mémoire, vous pouvez définir une réservation de mémoire de 4 Go pour la VM. Vous pourriez configurer une telle réservation de mémoire pour une VM critique qui doit maintenir un niveau de performance élevé.
L'hôte ESXi doit disposer de suffisamment de RAM pour prendre en charge une VM avec une réservation, ainsi qu'une certaine quantité de mémoire pour les frais généraux. Les VMs nécessitent une quantité spécifique de mémoire pour les frais généraux afin de pouvoir se mettre sous tension. Par exemple, une VM avec 4 Go de mémoire et deux vCPUs nécessite environ 53 Mo de mémoire pour les frais généraux. Pour plus d'informations sur les frais généraux de mémoire pour les VMs, consultez la gestion des ressources vSphere sur https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Allocation des ressources : Réservations de CPU
Réservations de CPU :
- Le CPU réservé pour une VM est garanti d'être immédiatement planifié sur les cœurs physiques. La VM n'est jamais placée dans un état CPU ready.
- Si un hôte ESXi n'a pas suffisamment de CPU non réservé pour prendre en charge une VM avec une réservation, la VM ne se met pas sous tension.
- Les réservations sont mesurées en MHz ou GHz.
- La valeur par défaut est de 0 MHz.
¶ Limites d'allocation des ressources
Limites de RAM :
- Les VMs ne consomment jamais plus de RAM physique que celle spécifiée par la limite d'allocation de mémoire.
- Les VMs utilisent le mécanisme de swap de la VM (
.vswp) si le système d'exploitation invité tente de consommer plus de RAM que ce qui est spécifié par la limite.
Limites de CPU :
- Les VMs ne consomment jamais plus de CPU physique que ce qui est spécifié par la limite d'allocation de CPU.
- Les threads CPU sont placés dans un état ready si le système d'exploitation invité tente de planifier des threads plus rapidement que ce que la limite permet.
Généralement, spécifier une limite n'est pas nécessaire.
Spécifier des limites présente les avantages et inconvénients suivants :
- Avantages :
Attribuer une limite est utile si vous commencez avec quelques VMs et souhaitez gérer les attentes des utilisateurs. Les performances se détériorent à mesure que vous ajoutez plus de VMs. Vous pouvez simuler une disponibilité de ressources plus limitée en spécifiant une limite.
- Inconvénients :
Vous risquez de gaspiller des ressources inactives si vous spécifiez une limite. Le système n'autorise pas les VMs à utiliser plus de ressources que la limite, même lorsque le système est sous-utilisé et que des ressources inactives sont disponibles. Spécifiez la limite uniquement si vous avez de bonnes raisons de le faire.
¶ Partages d'allocation des ressources
Les partages définissent l'importance relative d'une VM :
- Si une VM dispose du double de partages d'une ressource par rapport à une autre VM, la VM est autorisée à consommer deux fois plus de cette ressource lorsque ces deux VMs se disputent des ressources.
- Les valeurs de partages ne s'appliquent que si un hôte ESXi rencontre une concurrence pour une ressource.
Vous pouvez définir les partages sur haut, normal ou bas. Vous pouvez également sélectionner l'option personnalisée pour attribuer un nombre spécifique de partages à chaque VM.
| Paramètre | Valeurs de partage CPU | Valeurs de partage mémoire |
|---|---|---|
| Haut | 2 000 partages par vCPU | 20 partages par Mo de mémoire configurée pour la VM |
| Normal | 1 000 partages par vCPU | 10 partages par Mo de mémoire configurée pour la VM |
| Bas | 500 partages par vCPU | 5 partages par Mo de mémoire configurée pour la VM |
Les paramètres Haut, Normal et Bas représentent des valeurs de partages avec un ratio de 4:2:1, respectivement. Une valeur personnalisée de partages attribue un nombre spécifique de partages (qui exprime un poids proportionnel) à chaque VM.
¶ Exemple de Partages de Ressources
Les VMs sont des consommatrices de ressources. Les paramètres de ressources par défaut que vous attribuez lors de la création d'une VM conviennent à la plupart des VMs.
Le mécanisme de partage proportionnel s'applique à l'allocation du CPU, de la mémoire, des entrées/sorties (I/O) de stockage et des entrées/sorties (I/O) réseau. Ce mécanisme fonctionne uniquement lorsque les VMs sont en concurrence pour la même ressource.
Vous pouvez ajouter des partages à une machine virtuelle pendant qu'elle est en cours d'exécution.
Vous pouvez ajouter des partages à une VM pendant qu'elle est en cours d'exécution, et la VM obtient plus d'accès à cette ressource (en supposant qu'il y ait une concurrence pour la ressource). Lorsque vous ajoutez une VM, elle obtient également des partages. Le nombre de partages de la VM entre dans le calcul du nombre total de partages, mais les VMs existantes sont garanties de ne pas être privées de la ressource.
Les partages garantissent qu'une VM se voit attribuer une certaine quantité d'une ressource.
Les partages garantissent qu'une VM se voit attribuer une certaine quantité d'une ressource (CPU, RAM, I/O de stockage ou I/O réseau).
Par exemple, considérons la troisième ligne de VMs sur la diapositive :
- La VM D est mise sous tension avec 1 000 partages.
- Avant que la VM D ne soit mise sous tension, un total de 5 000 partages étaient disponibles, mais l'ajout de la VM D augmente le total des partages à 6 000.
- Le résultat est que la valeur des partages des autres VMs diminue. Cependant, la VM A conserve toujours un sixième de la ressource, car elle possède un sixième des partages.
Lorsque vous supprimez ou éteignez une VM, le nombre total de partages diminue, ce qui permet aux VMs restantes d'avoir plus d'accès à la ressource.
¶ Définir les paramètres d'allocation des ressources pour une VM
Vous pouvez modifier les paramètres d'une VM pour configurer l'allocation des ressources CPU et mémoire.
Lors de la réservation de la mémoire, vous pouvez sélectionner la case à cocher Réserver toute la mémoire de l'invité (Tout verrouillé). Cocher cette case garantit que toute la mémoire de la VM est réservée, même si vous modifiez la quantité totale de mémoire de la VM. La réservation de mémoire est immédiatement réajustée lorsque la configuration de la mémoire de la VM change.
¶ Affichage des paramètres d'allocation des ressources d'une VM
Vous pouvez consulter les paramètres de réservations, limites et partages pour toutes les VMs dans un cluster.
¶ Lab 23 : Contrôle des ressources des VMs
Observez le comportement des VMs avec différentes valeurs de partages CPU :
- Créer une concurrence CPU
- Vérifier la fonctionnalité des partages CPU
Retrouvez le lien du Lab en cliquant ici : Lab 23 : Contrôle des ressources des VMs
8-97 Revue des objectifs d'apprentissage
- Attribuer des valeurs de partages pour les ressources CPU et mémoire
- Décrire comment les machines virtuelles se disputent les ressources
- Définir les réservations et limites de CPU et de mémoire
¶ Points clés
- Les migrations à chaud utilisent vSphere vMotion, vSphere Storage vMotion, ou les deux.
- Vous pouvez migrer des VMs entre des instances vCenter, qu'elles se trouvent dans le même domaine SSO, dans des domaines SSO différents, ou éloignées géographiquement.
- Enhanced vMotion Compatibility (EVC) empêche les migrations vSphere vMotion d'échouer en raison de processeurs incompatibles ou de GPU vSGA incompatibles.
- Vous pouvez utiliser les instantanés de VM pour préserver l'état de la VM afin de pouvoir revenir de manière répétée au même état.
- Vous pouvez appliquer des réservations, des limites et des partages sur une VM pour contrôler la quantité de ressources CPU et mémoire allouées.
Chapitre précédent : 7 - Déploiement de machines virtuelles (VMs) - Chapitre suivant : 9 - Déploiement et configuration des clusters vSphere