¶ Importance
Les Virtual Machines (VMs) sont la base de votre infrastructure virtuelle. Déployer efficacement des VMs implique de reconnaître les différents types de matériel virtuel. Cela nécessite également des compétences en création, clonage et gestion des VMs et des templates, en modification des VMs et en mise à jour des templates.
¶ Leçons du module
- Création de Virtual Machines
- Analyse approfondie du matériel de Virtual Machine
- Modification de Virtual Machines
- Création de Templates et clonage de VMs
- Introduction aux Content Libraries
- Abonnement aux Content Libraries
- Gestion des Templates dans une Content Library
¶ Leçon 1 : Création de Virtual Machines
¶ Objectifs d’apprentissage
• Créer et provisionner une Virtual Machine
• Expliquer l’importance de VMware Tools
• Installer VMware Tools
• Supprimer une Virtual Machine
¶ À propos du provisionnement des Virtual Machines
Vous pouvez créer des VMs de plusieurs façons.
| Méthode de provisionnement | Utiliser vSphere Client | Utiliser VMware Host Client |
|---|---|---|
| Utiliser l’assistant Nouvelle machine virtuelle. | Oui | Oui |
| Déployer des VMs à partir de modèles existants ou de clones. | Oui | Non |
| Déployer des VMs à partir de modèles OVF. | Oui | Oui |
La méthode optimale pour le provisionnement des machines virtuelles dans votre environnement dépend de facteurs tels que la taille et le type de votre infrastructure ainsi que les objectifs que vous souhaitez atteindre.
Vous pouvez utiliser l’assistant Nouvelle machine virtuelle pour créer une machine virtuelle unique si aucune autre VM de votre environnement ne répond à vos besoins, tels qu’un système d’exploitation particulier ou une configuration matérielle spécifique. Par exemple, vous pourriez avoir besoin d’une VM configurée uniquement à des fins de test.
Vous pouvez également créer une machine virtuelle unique, installer un système d’exploitation dessus, puis utiliser cette VM comme modèle à partir duquel cloner d’autres machines virtuelles.
Déployer des VM, des appliances virtuelles et des vApps stockées au format Open Virtual Machine Format (OVF) pour utiliser une VM préconfigurée.
Une appliance virtuelle est une VM qui contient généralement un système d’exploitation et d’autres logiciels préinstallés.
Vous pouvez déployer des VM à partir de modèles OVF qui se trouvent sur des systèmes de fichiers locaux (par exemple, des disques locaux tels que C:), des supports amovibles (par exemple, des CD ou des clés USB), des lecteurs réseau partagés ou des URL.
En plus d’utiliser le vSphere Client, vous pouvez également utiliser VMware Host Client pour créer une VM en utilisant des fichiers OVF. Cependant, plusieurs limitations s’appliquent lorsque vous utilisez VMware Host Client pour cette méthode de déploiement.
Pour des informations sur les limitations OVF et OVA du VMware Host Client, voir vSphere Single Host Management - VMware Host Client à l’adresse : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Création de VM avec l’Assistant Nouvelle machine virtuelle
Dans le vSphere Client, vous pouvez utiliser l’assistant Nouvelle machine virtuelle pour créer une VM.
¶ Assistant Nouvelle machine virtuelle : Nom, Dossier, Ressource de calcul
Vous pouvez utiliser l’assistant Nouvelle machine virtuelle dans le vSphere Client pour créer une VM.
L’assistant vous demande des informations standards :
- Le nom de la VM
- Le dossier dans lequel placer la VM
- La ressource sur laquelle la VM s’exécute
Lorsque vous spécifiez la ressource de calcul, vous pouvez indiquer un hôte, un cluster, un vApp ou un pool de ressources.
La VM peut accéder aux ressources de l’objet sélectionné.
¶ Assistant Nouveau de Machine Virtuelle : Stockage, Compatibilité
Vous sélectionnez le datastore sur lequel stocker les fichiers de la VM.
Vous sélectionnez la version d’ESXi avec laquelle cette machine virtuelle sera compatible.
Lors de la sélection du stockage, vous pouvez choisir la politique de stockage et le datastore. Chaque datastore peut avoir une taille, une vitesse, une disponibilité et d’autres propriétés différentes. Les datastores disponibles sont accessibles à partir de la ressource de calcul que vous avez sélectionnée.
Lors de la sélection de la compatibilité, vous choisissez la version de l’hôte ESXi avec laquelle vous souhaitez que la machine virtuelle soit compatible. Pour donner à votre VM accès aux fonctionnalités matérielles les plus récentes, sélectionnez la dernière version d’ESXi.
¶ Assistant Nouveau Assistant de Machine Virtuelle : Système d’Exploitation Invité
Vous sélectionnez le système d’exploitation invité à installer dans la machine virtuelle.
Lorsque vous sélectionnez un système d’exploitation invité, BIOS ou EFI est choisi par défaut, en fonction du firmware pris en charge par le système d’exploitation.
Si le système d’exploitation prend en charge à la fois BIOS et EFI, vous pouvez modifier la valeur par défaut en éditant la machine virtuelle après sa création et avant d’installer le système d’exploitation invité.
Si vous sélectionnez EFI, vous ne pourrez pas démarrer un système d’exploitation qui ne prend en charge que BIOS, et inversement.
¶ Assistant de nouvelle machine virtuelle : Virtual Hardware
Vous pouvez configurer le hardware de la machine virtuelle.
Les valeurs par défaut pour le CPU, la memory et la taille du hard disk sont basées sur le guest OS que vous avez sélectionné.
Vous pouvez également monter l’ISO image contenant les fichiers d’installation du guest operating system.
¶ Installation du guest operating system
L’installation d’un guest operating system dans votre VM est similaire à son installation sur un ordinateur physique.
Pour installer le guest operating system, vous interagissez avec la VM via la VM console.
En utilisant le vSphere Client, vous pouvez attacher un CD, un DVD ou une ISO image contenant l’installation image au lecteur virtuel CD/DVD.
Sur la diapositive, le guest operating system Windows Server 2008 est en cours d’installation. Vous pouvez utiliser le vSphere Client pour installer un guest operating system. Vous pouvez également installer un guest operating system à partir d’une ISO image ou d’un CD.
L’installation à partir d’une ISO image est généralement plus rapide et plus pratique qu’une installation depuis un CD.
Pour plus d’informations sur l’installation de guest operating systems, consultez la documentation vSphere Virtual Machine Administration à l’adresse : https://docs.vmware.com/en/VMware-vSphere/index.html
Pour plus d’informations sur les guest operating systems supportés, consultez le VMware Compatibility Guide à l’adresse : https://www.vmware.com/resources/compatibility
¶ À propos de VMware Tools
VMware Tools est un ensemble de fonctionnalités qui améliorent la performance du guest operating system d’une VM.
Les avantages et fonctionnalités incluent :
-
Device drivers
- SVGA display
- VMXNET/VMXNET3
- Balloon driver pour la gestion de la memory
- Sync driver pour la mise en pause du I/O
- Paravirtual SCSI controller
-
Amélioration des performances graphiques
-
Amélioration des performances de la souris
-
Guest OS heartbeat service
-
Synchronisation de l’heure
-
Possibilité d’arrêter la VM à distance
VMware Tools améliore la gestion de la VM en remplaçant les drivers génériques du operating system par des VMware drivers optimisés pour le virtual hardware.
Vous installez VMware Tools dans le guest operating system. Lorsque vous installez VMware Tools, vous installez les éléments suivants :
- VMware Tools service : ce service synchronise l’heure dans le guest operating system avec l’heure du host operating system.
- Un ensemble de VMware device drivers, avec des options supplémentaires de monitoring Perfmon.
- Un ensemble de scripts qui vous aide à automatiser les opérations du guest operating system : vous pouvez configurer les scripts pour s’exécuter lorsque l’état d’alimentation de la VM change.
VMware Tools améliore la performance d’une VM et rend possibles de nombreuses fonctionnalités de facilité d’utilisation dans les produits VMware :
- Performances graphiques plus rapides
- Dossiers partagés entre les file systems du host et du guest
- Copier-coller de texte, graphiques et fichiers entre la machine virtuelle et le host ou le client desktop
- Scripting qui aide à automatiser les opérations du guest operating system
Bien que le guest operating system puisse fonctionner sans VMware Tools, de nombreuses fonctionnalités VMware ne sont pas disponibles tant que vous n’avez pas installé VMware Tools.
Par exemple, si VMware Tools n’est pas installé dans votre VM, vous ne pouvez pas utiliser les options shutdown ou restart depuis la toolbar. Vous pouvez uniquement utiliser les power options.
¶ Installation de VMware Tools
Assurez-vous de sélectionner la dernière version de VMware Tools pour votre guest operating system.
Pour savoir quelles ISO images de VMware Tools sont incluses avec vSphere 8, consultez les vSphere 8 Release Notes.
La méthode d’installation de VMware Tools dépend du type de guest operating system.
| Type de guest operating system | Méthode d’installation de VMware Tools |
|---|---|
| Microsoft Windows | Installation depuis windows.iso pour les guests Vista et versions ultérieures |
| Linux | Utilisez l’une des méthodes suivantes : • Installation depuis linux.iso. • Pour les distributions Linux récentes, utilisez open-vm-tools, disponible dans différents systèmes de gestion de paquets Linux tels que yum, apt ou rpm. |
Pour plus de détails sur l’installation de VMware Tools dans un guest operating system Windows ou Linux, ainsi que pour plus d’informations sur l’utilisation de open-vm-tools, consultez la documentation VMware Tools Administration à l’adresse suivante : https://docs.vmware.com/en/VMware-Tools/index.html
¶ Téléchargement de VMware Tools
Vous pouvez télécharger une version spécifique de VMware Tools depuis la page de téléchargement du produit VMware Tools.
Pour plus d’informations sur l’installation de VMware Tools dans des guest operating systems spécifiques, consultez la documentation VMware Tools Administration à l’adresse suivant : https://docs.vmware.com/en/VMware-Tools/index.html
¶ Déploiement de modèles OVF
Vous pouvez déployer n’importe quelle VM ou appliance virtuelle stockée au format OVF.
Les appliances virtuelles sont des VMs préconfigurées :
- Elles sont généralement conçues pour une seule fonction.
- Elles sont également disponibles dans le VMware Marketplace.
Une virtual appliance est une VM préconfigurée qui inclut généralement un guest operating system préinstallé ainsi que d’autres logiciels.
Une virtual appliance est habituellement conçue pour une fonction spécifique, par exemple fournir un navigateur web sécurisé, un firewall ou un utilitaire de backup et recovery.
Une virtual appliance peut être ajoutée ou importée dans l’inventaire de votre vCenter Server system ou dans l’inventaire ESXi.
Les virtual appliances peuvent être importées depuis des sites web tels que le VMware Marketplace : https://marketplace.cloud.vmware.com
Les virtual appliances sont déployées sous forme de OVF templates.
OVF est un format de packaging et de distribution des VMs indépendant de la plateforme, efficace, extensible et ouvert.
Les fichiers OVF sont compressés, ce qui permet des téléchargements plus rapides.
Pour déployer un OVF template en utilisant le vSphere Client, faites un clic droit sur l’objet approprié, tel qu’un data center ou un hôte ESXi, puis sélectionnez Deploy OVF Template.
L’assistant Deploy OVF Template s’affiche. Cliquez sur UPLOAD FILES pour sélectionner les fichiers du template à déployer.
Le vSphere Client valide un fichier OVF avant de l’importer et s’assure qu’il est compatible avec le serveur de destination prévu.
Si l’appliance n’est pas compatible avec l’hôte sélectionné, vous ne pouvez pas l’importer.
¶ Suppression de VMs
Vous pouvez supprimer une VM de la manière suivante :
-
Remove from the inventory :
- La VM est désenregistrée de l’hôte ESXi et de vCenter.
- Les fichiers de la VM restent sur le disk.
- La VM peut être réenregistrée (ajoutée) ultérieurement dans l’inventaire.
-
Delete from disk :
- Tous les fichiers de la VM sont définitivement supprimés du datastore.
- La VM est désenregistrée de l’hôte ESXi et de vCenter.
Lorsque qu’une VM est supprimée de l’inventaire, ses fichiers restent au même emplacement de stockage, et la VM peut être réenregistrée depuis le datastore browser.
¶ Lab 12 : Création et suppression d’une machine virtuelle
Utilisez le vSphere Client pour créer une VM, supprimer une VM de l’inventaire et supprimer une VM du datastore :
- Créer une Virtual Machine
- Supprimer la Virtual Machine de l’inventaire vCenter
- Réenregistrer la Virtual Machine pour l’ajouter de nouveau à l’inventaire vCenter
- Supprimer la Virtual Machine du datastore
Retrouvez le lien du Lab en cliquant ici : Lab 12 : Création et suppression d’une machine virtuelle
¶ Lab 13 : Installation de VMware Tools (Simulation)
Utilisez le vSphere Client pour installer VMware Tools sur une VM Windows existante :
- Monter l’image VMware Tools sur le lecteur DVD de la VM
- Installer VMware Tools avec l’assistant VMware Tools Setup Wizard
- Vérifier que VMware Tools est en cours d’exécution dans le guest OS
Retrouvez le lien du Lab en cliquant ici : Lab 13 : Installation de VMware Tools (Simulation)
¶ Revue des objectifs d’apprentissage
- Créer et provisionner une Virtual Machine
- Expliquer l’importance de VMware Tools
- Installer VMware Tools
- Supprimer une Virtual Machine
¶ Leçon 2 : Analyse approfondie du hardware de la Virtual Machine
¶ Objectifs d’apprentissage
- Identifier les fichiers qui composent une VM
- Comparer les versions de hardware de VM
- Reconnaître les composants de hardware virtuel d’une VM
- Naviguer dans le vSphere Client et examiner les paramètres de la VM
- Identifier les méthodes d’accès à la VM console
¶ Encapsulation d’une Virtual Machine
Chaque VM est stockée soit comme un ensemble de fichiers, soit comme des objets :
- Fichiers dans un répertoire sur un datastore VMFS ou NFS
- Objets sur un datastore vSAN ou vSphere Virtual Volumes
Chaque disque virtuel est encapsulé dans un seul fichier ou objet.
vSphere encapsule chaque VM dans quelques fichiers ou objets, ce qui rend les VMs plus faciles à gérer et à migrer.
Les fichiers et objets de chaque VM sont stockés dans un dossier séparé sur un datastore.
¶ À propos des fichiers de Virtual Machine
Une VM inclut un ensemble de fichiers associés.
La diapositive liste certains des fichiers qui composent une VM.
À l’exception des fichiers de log, le nom de chaque fichier contient le nom de la VM <VM_name>.
Une VM se compose des fichiers suivants :
- Un fichier de configuration (.vmx).
- Si la VM est convertie en template, un fichier de configuration de template (.vmtx) remplace le fichier de configuration (.vmx).
- Des fichiers de swap (.vswp) utilisés pour libérer de la memory lors de périodes de contention.
- Un fichier contenant les paramètres BIOS ou EFI de la VM (.nvram).
- Le fichier de log actuel d’une VM (.log) et un ensemble de fichiers utilisés pour archiver les anciennes entrées de log (-#.log).
En plus du fichier de log actuel vmware.log, jusqu’à six fichiers de log archivés sont maintenus simultanément.
Par exemple, -1.log à -6.log peuvent exister en même temps.
La prochaine fois qu’un fichier de log archivé est créé, par exemple lorsque la VM est arrêtée puis redémarrée, les actions suivantes se produisent :
Le fichier -6.log est supprimé, le fichier -5.log est renommé en -6.log, et ainsi de suite. Enfin, le fichier vmware.log précédent est renommé en -1.log.
- Un ou plusieurs fichiers de disque virtuel. Le premier disque virtuel possède les fichiers VM_name.vmdk et VM_name-flat.vmdk.
Si la VM a plus d’un fichier disque, la paire de fichiers pour les disques suivants est appelée VM_name_#.vmdk et VM_name_#-flat.vmdk. Le # représente le prochain numéro dans la séquence, en commençant par 1.
Par exemple, si la VM appelée Test01 possède deux disques virtuels, cette VM aura les fichiers Test01.vmdk, Test01-flat.vmdk, Test01_1.vmdk, et Test01_1-flat.vmdk.
La liste des fichiers montrée dans la diapositive n’est pas exhaustive.
Pour une liste complète de tous les types de fichiers VM, consultez la documentation vSphere Virtual Machine Administration à l’adresse suivante : https://docs.vmware.com/8.0/TBD
¶ À propos du Virtual Hardware de la VM
Un guest OS accède aux périphériques hardware. Le guest OS ne sait pas que ces périphériques sont virtuels et non physiques.
Toutes les VMs disposent d’un hardware uniforme, à l’exception de quelques variations que l’administrateur système peut appliquer.
Un hardware uniforme rend les VMs portables entre les différentes plateformes de virtualisation VMware.
Vous pouvez configurer les paramètres de memory et de CPU de la VM.
vSphere prend en charge plusieurs fonctionnalités récentes de CPU, y compris les virtual CPU performance counters.
Vous pouvez ajouter des disques virtuels (virtual hard disks) et des NICs.
Vous pouvez également ajouter et configurer du hardware virtuel, tel que des lecteurs CD/DVD et des périphériques SCSI.
Tous les périphériques ne sont pas disponibles pour être ajoutés ou configurés.
Par exemple, vous ne pouvez pas ajouter de périphériques vidéo, mais vous pouvez configurer les périphériques vidéo et les cartes graphiques disponibles.
Vous pouvez ajouter plusieurs périphériques USB, tels que des security dongles et des périphériques de mass storage, à une VM hébergée sur un hôte ESXi auquel les périphériques sont physiquement connectés.
Lorsque vous attachez un périphérique USB à un hôte physique, ce périphérique est disponible uniquement pour les VMs situées sur cet hôte.
Ces VMs ne peuvent pas se connecter à un périphérique sur un autre hôte du data center.
Un périphérique USB est disponible pour une seule VM à la fois.
Lorsque vous retirez un périphérique USB d’une VM, il devient disponible pour les autres VMs situées sur le même hôte.
Vous pouvez avoir 64 virtual SCSI targets pour un virtual SCSI adapter si vous utilisez un PVSCSI driver.
Cependant, vous ne pouvez avoir que 15 virtual SCSI targets pour un virtual SCSI adapter autre que PVSCSI.
Le SATA controller fournit l’accès aux virtual disks, aux périphériques CD/DVD, et aux périphériques USB.
Le SATA virtual controller est présenté à une machine virtuelle comme un AHCI SATA controller.
L’interface de communication de Virtual Machine (VMCI) est une infrastructure qui fournit un canal de communication à haute vitesse entre une VM et l’hyperviseur.
Vous ne pouvez pas ajouter ni supprimer des périphériques VMCI.
Le VMCI SDK facilite le développement d’applications qui utilisent l’infrastructure VMCI.
Sans VMCI, les VMs communiquent avec le host en utilisant la couche réseau.
L’utilisation de la couche réseau ajoute de la surcharge (overhead) à la communication.
Avec VMCI, la surcharge de communication est minimale et les tâches nécessitant des échanges peuvent être optimisées.
Les types de communication suivants sont disponibles :
- Datagrams : sans connexion, similaires à des paires de files d’attente UDP
- Connection oriented : similaire à TCP
VMCI fournit des socket APIs similaires aux APIs utilisées pour les applications TCP/UDP. Les adresses IP sont remplacées par des VMCI ID numbers.
Par exemple, vous pouvez porter netperf pour utiliser des VMCI sockets au lieu de TCP/UDP.
VMCI est désactivé par défaut.
Pour plus d’informations sur le hardware virtuel, consultez la documentation vSphere Virtual Machine Administration : https://docs.vmware.com/en/VMware-vSphere/index.html
Pour une liste complète des limites de configuration de Virtual Machine, consultez VMware Configuration Maximums : https://configmax.vmware.com
¶ Versions de Virtual Hardware
La version du virtual hardware, ou niveau de compatibilité de la VM, détermine les fonctionnalités du operating system qu’une VM prend en charge.
N’utilisez pas une version plus récente qui n’est pas prise en charge par le produit VMware.
| Compatibilité | Version de Virtual Hardware |
|---|---|
| ESXi 8.0 | 20 |
| ESXi 7.0 U2 et versions ultérieures | 19 |
| ESXi 7.0 U1 et versions ultérieures | 18 |
| ESXi 7.0 et versions ultérieures | 17 |
| ESXi 6.7 U2 et versions ultérieures | 15 |
| ESXi 6.7 et versions ultérieures | 14 |
| La version 16 de Virtual Hardware est spécifique à Workstation et Fusion Pro. |
Chaque version d’un produit VMware inclut une version correspondante de VM hardware.
Le tableau montre la dernière version de hardware que chaque version d’ESXi prend en charge.
Chaque niveau de compatibilité de VM prend en charge au moins cinq versions majeures ou mineures de vSphere.
Pour plus d’informations sur la compatibilité des virtual machines, consultez la documentation vSphere Virtual Machine Administration : https://docs.vmware.com/en/VMware-vSphere/index.html
Pour obtenir la liste complète des versions de VM hardware, consultez l’article de la base de connaissances : https://kb.vmware.com/s/article/1003746
¶ À propos du CPU et de la mémoire
Vous pouvez ajouter, modifier ou configurer les ressources CPU et mémoire afin d’améliorer les performances d’une VM.
Le nombre maximum de vCPUs (virtual CPUs) que vous pouvez attribuer à une VM dépend des facteurs suivants :
- Le nombre de logical CPUs présents sur l’host
- Le type et la version du guest operating system installé
Une VM exécutée sur un ESXi 8.0 host peut avoir jusqu’à 768 vCPUs.
La taille maximale de la mémoire d’une VM dépend du paramètre de compatibilité de la VM.
La taille maximale de la mémoire d’une VM avec une compatibilité ESXi 8.0, exécutée sur ESXi 8.0, est de 24 To.
Vous dimensionnez le CPU et la mémoire de la VM en fonction des applications et du guest operating system.
Vous pouvez utiliser la fonctionnalité multicore vCPU pour contrôler le nombre de cœurs par socket virtuel dans une VM. Grâce à cette capacité, les operating systems ayant des restrictions de socket peuvent utiliser davantage de cœurs du CPU de l’host, ce qui augmente les performances globales.
Une VM ne peut pas avoir plus de virtual CPUs que le nombre de logical CPUs sur l’host.
Le nombre de logical CPUs correspond au nombre de cœurs physiques du processeur, ou au double de ce nombre si l’hyperthreading est activé.
Par exemple, si un host possède 128 logical CPUs, vous pouvez configurer la VM pour 128 vCPUs.
Vous pouvez définir la plupart des paramètres de mémoire lors de la création de la VM ou après l’installation du guest operating system.
Certaines actions nécessitent d’éteindre la VM avant de modifier les paramètres.
Les paramètres de ressource mémoire d’une VM déterminent la quantité de mémoire de l’host allouée à la VM.
La taille de la mémoire de virtual hardware détermine la quantité de mémoire disponible pour les applications qui s’exécutent dans la VM. Une VM ne peut pas bénéficier de plus de ressources mémoire que la taille configurée de sa mémoire de virtual hardware.
Vous pouvez reconfigurer la quantité de mémoire allouée à une VM pour améliorer ses performances.
La taille maximale de mémoire pour une VM dépend du paramètre de compatibilité de la VM.
¶ Maximums de calcul
vSphere fournit des maximums de calcul, disponibles à l’adresse suivante : https://configmax.vmware.com
| vSphere 8 | |
|---|---|
| Élément | Valeur |
| vCPUs par VM | 768 |
| Mémoire par VM | 24 To |
| CPUs par host | 896 |
| Mémoire par host | 24 To |
| Hosts par cluster | 96 |
Pour la liste complète des maximums de configuration, consultez : https://configmax.vmware.com/
¶ À propos du stockage virtuel
Les virtual disks sont connectés à des virtual storage adapters.
L’ESXi host propose aux VMs plusieurs choix de storage adapters :
- BusLogic Parallel
- LSI Logic Parallel
- LSI Logic SAS
- VMware Paravirtual SCSI
- AHCI SATA controller
- Virtual NVMe
Les storage adapters fournissent la connectivité de votre ESXi host à une storage unit ou à un réseau spécifique.
ESXi prend en charge différentes classes d’adapters, y compris SCSI, iSCSI, RAID, Fibre Channel, Fibre Channel over Ethernet (FCoE) et Ethernet.
ESXi accède directement aux adapters par l’intermédiaire des device drivers dans le VMkernel :
- BusLogic Parallel : l’host bus adapter compatible Mylex (BusLogic) BT/KT-958.
- LSI Logic Parallel : le LSI Logic LSI53C10xx Ultra320 SCSI I/O controller est pris en charge.
- LSI Logic SAS : l’LSI Logic SAS adapter possède une interface série.
- VMware Paravirtual SCSI : un storage adapter haute performance qui peut fournir un débit supérieur et une utilisation CPU réduite.
- AHCI SATA controller : permet l’accès aux virtual disks et aux périphériques CD/DVD. Le SATA virtual controller apparaît pour une VM comme un AHCI SATA controller.
- Virtual NVMe : NVMe est un protocole pour connecter et accéder aux périphériques de flash storage via le PCI Express bus. NVMe est une alternative aux protocoles existants d’accès block-based server storage I/O.
¶ À propos des Thick-Provisioned Virtual Disks
Le thick provisioning utilise tout l’espace disque défini lors de la création du virtual disk, indépendamment de la quantité d’espace réellement utilisée par le guest operating system file system.
Les types de thick-provisioned disks sont soit eager zeroed, soit lazy zeroed :
- Dans un eager-zeroed thick-provisioned disk, chaque bloc est pré-rempli avec un zéro.
- Dans un lazy-zeroed thick-provisioned disk, un bloc est rempli de zéros avant que les données ne soient écrites pour la première fois.
Dans un lazy-zeroed thick-provisioned disk, l’espace requis pour le virtual disk est alloué lors de la création. Les données restantes sur le périphérique physique ne sont pas effacées pendant la création. Plus tard, les données sont remplacées par des zéros à la demande, lors du premier write provenant de la VM. Ce type de disque est le paramètre par défaut.
Dans un eager-zeroed thick-provisioned disk, l’espace requis pour le virtual disk est alloué lors de la création. Les données restantes sur le périphérique physique sont remplacées par des zéros dès la création du disque.
¶ À propos des Thin-Provisioned Virtual Disks
Avec le thin provisioning, les VMs utilisent l’espace disque selon les besoins :
- Les virtual disks utilisent uniquement la capacité nécessaire pour contenir les fichiers actuels.
- La VM voit toujours la taille totale du disque allouée.
Exécutez la commande unmap pour récupérer l’espace inutilisé des virtual disks.
Les fonctions de reporting et les alertes aident à gérer les allocations et la capacité.
Vous pouvez mélanger les formats thick et thin.
Les exemples suivants montrent une utilisation efficace du storage :
- Provisioned space pour les virtual disks : 140 GB
- Available datastore capacity : 100 GB
- Used datastore capacity : 80 GB
Un thin-provisioned disk n’utilise que l’espace de datastore dont il a initialement besoin. Si le thin disk requiert plus d’espace par la suite, il peut s’étendre jusqu’à la capacité maximale qui lui a été allouée.
Le thin provisioning fournit des alertes (alarms) et des rapports (reports) qui suivent l’allocation par rapport à l’utilisation actuelle de la capacité de storage. Les storage administrators peuvent utiliser le thin provisioning pour optimiser l’allocation du storage dans les environnements virtuels. Avec le thin provisioning, les utilisateurs peuvent exploiter l’espace disque disponible de manière optimale mais sûre grâce à la overallocation.
ESXi prend en charge la récupération d’espace libre (reclamation of free space), également appelée commande unmap, qui aide la storage array à récupérer l’espace inutilisé. Pour plus d’informations sur la récupération d’espace et sur l’exécution de la commande SCSI unmap, consultez la documentation vSphere Storage à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/index.html
¶ Gestion des Datastores contenant des Thin-Provisioned Disks
Lorsque l’espace total alloué aux thin-provisioned disks dépasse la taille du datastore, ce datastore devient overcommitted.
Pour surveiller activement la capacité du datastore :
- Configurez des alarms afin d’envoyer des notifications concernant :
— l’overallocation du disque du datastore
— l’utilisation du disque de la VM - Utilisez le reporting pour visualiser l’utilisation de l’espace.
Pour gérer activement la capacité du datastore :
- Augmentez la capacité du datastore si nécessaire.
- Utilisez vSphere Storage vMotion pour atténuer les problèmes d’utilisation de l’espace sur un datastore particulier.
L’utilisation de thin-provisioned virtual disks pour vos VMs est un moyen d’optimiser la capacité de votre datastore. Mais si votre datastore n’est pas dimensionné correctement, il peut devenir overcommitted. Un datastore devient overcommitted lorsque la capacité totale de ses thin-provisioned virtual disks est supérieure à la capacité du datastore.
Lorsque la capacité d’un datastore est atteinte, le vSphere Client vous invite à fournir plus d’espace sur le VMFS datastore sous-jacent. Les VMs se mettent en pause si elles essaient d’écrire des données sur le datastore.
Surveillez la capacité de votre datastore en configurant des alarms pour vous alerter sur :
- le niveau d’allocation complète des disques d’un datastore
- la quantité d’espace disque utilisée par une VM
Gérez la capacité de votre datastore en augmentant dynamiquement sa taille lorsque cela est nécessaire. Vous pouvez également utiliser vSphere Storage vMotion pour atténuer les problèmes d’utilisation de l’espace.
Par exemple, avec vSphere Storage vMotion, vous pouvez migrer une VM hors d’un datastore. La migration peut être effectuée en passant de virtual disks au format thick vers le format thin sur le datastore cible.
¶ Thick-Provisioned et Thin-Provisioned Disks
Les options de virtual disks diffèrent en termes de temps de création, d’allocation de blocs, de disposition (layout) et de mise à zéro des blocs de fichiers alloués (zeroing out).
| Type de Virtual Disk | Temps de création | Allocation des blocs | Disposition (Virtual disk layout) | Mise à zéro des blocs de fichiers alloués (Zeroing out) |
|---|---|---|---|---|
| Thick Provisioned – Lazy-Zeroed | Rapide | Entièrement préalloués | Plus grande probabilité de blocs de fichiers contigus | Les blocs de fichiers sont mis à zéro lorsque chaque bloc est écrit pour la première fois |
| Thick Provisioned – Eager-Zeroed | Lent et proportionnel à la taille du disque | Entièrement préalloués | Plus grande probabilité de blocs de fichiers contigus | Les blocs de fichiers sont alloués et mis à zéro lors de la création du disque |
| Thin Provisioned | Le plus rapide | Alloués et mis à zéro à la demande lors du premier write sur le bloc | La disposition varie selon l’état dynamique du volume au moment de l’allocation | Les blocs de fichiers sont mis à zéro au moment de leur allocation |
¶ À propos des Virtual Networks
Les VMs et les machines physiques communiquent via un virtual network.
Lorsque vous configurez le networking d’une VM, vous sélectionnez ou modifiez les paramètres suivants :
- Le type de network adapter
- Le port group auquel se connecter
- L’état de la network connection
- Le choix de se connecter ou non au network lors du démarrage (power on) de la VM
Pour plus d’informations sur les virtual networks, consultez la documentation vSphere Networking à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/index.html
¶ À propos des Virtual Network Adapters
Lorsque vous configurez une VM, vous pouvez ajouter des network adapters (NICs) et spécifier le type d’adapter.
Dans la mesure du possible, sélectionnez VMXNET3.
| |Types de Network Adapter|
| Type | Description |
|---|---|
| E1000 – E1000E | Version émulée d’une Intel Gigabit Ethernet NIC, avec pilotes disponibles dans les nouveaux guest operating systems. |
| VMXNET3 | Disponible uniquement avec VMware Tools. |
| Flexible | Peut fonctionner soit comme un Vlance, soit comme un VMXNET adapter. |
| PVRDMA | Périphérique paravirtualisé qui améliore les performances des périphériques virtuels. Il fournit une interface de type RDMA pour les vSphere guests. |
| SR-IOV pass-through | Permet à une VM et à un physical adapter d’échanger des données sans utiliser le VMkernel comme intermédiaire. |
Les types de network adapters disponibles dépendent des facteurs suivants :
- Le niveau de compatibilité de la VM (VM compatibility level ou hardware version), qui dépend de l’host qui l’a créée ou récemment mise à jour. Par exemple, la VMXNET3 virtual NIC requiert la hardware version 14 ou ultérieure.
- Si la compatibilité de la VM est mise à jour vers la dernière version pour l’host actuel.
- Le guest operating system
Les types de NICs suivants sont pris en charge :
-
E1000E : version émulée de l’Intel 82574 Gigabit Ethernet NIC. E1000E est l’adapter par défaut pour Windows 8 et Windows Server 2012.
-
E1000 : version émulée de l’Intel 82545EM Gigabit Ethernet NIC, avec des pilotes disponibles dans les nouveaux guest operating systems, y compris Windows XP et versions ultérieures ainsi que Linux version 2.4.19 et ultérieures.
-
Flexible : s’identifie comme un Vlance adapter lorsque la VM démarre, mais s’initialise et fonctionne soit comme un Vlance, soit comme un VMXNET adapter, selon le pilote qui l’initialise. Avec VMware Tools installé, le pilote VMXNET transforme l’adapter Vlance en VMXNET adapter plus performant.
-
Vlance : version émulée de l’AMD 79C970 PCnet32 LANCE NIC, un ancien NIC de 10 Mbps avec pilotes disponibles dans les legacy guest operating systems 32 bits. Une VM configurée avec cet network adapter peut utiliser immédiatement son network.
-
VMXNET3 : un paravirtualized NIC conçu pour la performance. VMXNET3 offre toutes les fonctionnalités disponibles dans VMXNET2 et ajoute plusieurs nouvelles fonctionnalités, telles que la prise en charge du multiqueue (également appelée Receive Side Scaling sous Windows), le IPv6 offloads, et la livraison d’interruptions MSI/MSI-X.
-
Avec PVRDMA, plusieurs guests peuvent accéder au périphérique RDMA en utilisant l’API verbs, une interface standard de l’industrie. Un ensemble de ces verbs a été implémenté pour exposer un périphérique guest compatible RDMA (PVRDMA) aux applications. Les applications peuvent utiliser le PVRDMA guest driver pour communiquer avec le périphérique physique sous-jacent.
PVRDMA prend en charge RDMA, offrant les fonctionnalités suivantes :
— OS bypass
— Zero-copy
— Faible latence et haute bande passante
— Moindre consommation d’énergie et accès plus rapide aux données -
SR-IOV pass-through : représentation d’une virtual function sur un physical NIC avec prise en charge SR-IOV. Ce type d’adapter convient aux VMs qui nécessitent davantage de ressources CPU ou dans lesquelles la latence peut provoquer des défaillances. Si les VMs sont sensibles aux délais réseau, SR-IOV peut fournir un accès direct aux virtual functions des physical NICs pris en charge, en contournant les virtual switches et en réduisant la charge (overhead).
Le SR-IOV pass-through est disponible pour Red Hat Enterprise Linux 6 et versions ultérieures, ainsi que pour Windows Server 2008 R2 avec SP2. Une version du operating system peut contenir un default virtual function driver pour certains NICs. Pour d’autres, vous devez le télécharger et l’installer depuis un emplacement fourni par le NIC ou le host vendor.
¶ À propos des PCI Passthrough Devices
Les passthrough devices aident votre environnement à utiliser efficacement les ressources et à améliorer les performances.
Vous connectez le guest OS d’une VM à des PCI ou PCIe passthrough devices qui sont configurés sur un ESXi host.
| PCI Passthrough Devices | Description |
|---|---|
| vSphere DirectPath I/O | • La VM accède directement au périphérique PCI ou PCIe physique sur un host spécifique. • La VM est limitée à cet host particulier. |
| vSphere Dynamic DirectPath I/O | • Le périphérique PCI ou PCIe passthrough n’est pas directement mappé à la VM. • Permet à vSphere DRS de placer une VM sur n’importe quel ESXi host du cluster qui fournit le périphérique passthrough assigné. |
| NVIDIA GRID GPU | • Périphérique graphique utilisant la technologie NVIDIA GRID vGPU. • Permet aux VMs d’utiliser des allocations GPU partielles, complètes ou multiples. |
Avec vSphere DirectPath I/O, vous pouvez accéder directement à des périphériques tels que des cartes graphiques ou des cartes son haute performance. Une VM spécifie un périphérique PCI ou PCIe en utilisant son hardware address.
Lorsque des périphériques vSphere DirectPath I/O sont attribués à une virtual machine, certaines opérations ne peuvent pas être effectuées sur cette VM. Ces opérations incluent la mise en suspension (suspending), la migration avec vMotion, la création ou la restauration de snapshots de la virtual machine
Avec vSphere Dynamic DirectPath I/O, l’hardware address du périphérique passthrough n’est plus directement mappée à la VM.
vSphere Dynamic DirectPath I/O est utile sur les hosts qui disposent de périphériques PCI passthrough et pour les périphériques virtualisés qui nécessitent un périphérique matériel attribué directement pour les prendre en charge.
vSphere Dynamic DirectPath I/O permet à vSphere DRS d’identifier un host au sein du cluster qui dispose d’un périphérique disponible avec le même fournisseur (vendor) et le même nom de modèle.
vSphere DRS intervient uniquement lors du power on de la VM et n’effectue aucune action de répartition de charge (load balancing).
Les périphériques NVIDIA GRID vGPU optimisent les opérations graphiques complexes et les exécutent avec de hautes performances sans surcharger le CPU. NVIDIA GRID vGPU offre des performances graphiques et une évolutivité inégalées en partageant un physical GPU unique entre plusieurs virtual machines, sous forme de périphériques passthrough distincts activés pour vGPU.
Pour plus d’informations sur vSphere Dynamic DirectPath I/O, consultez vSphere 7 – Assignable Hardware à cette adresse : https://blogs.vmware.com/vsphere/2020/03/vsphere-7-assignable-hardware.html
¶ Autres Virtual Devices
Une VM doit avoir un vCPU et une virtual memory. L’ajout d’autres virtual devices rend la VM plus utile :
- CD/DVD drive : pour se connecter à un CD, un DVD ou une image ISO.
- USB 3.0 et 3.1 : pris en charge avec des périphériques connectés à l’host ou au client.
- Floppy drive : pour connecter une VM à un lecteur de disquette ou à une image de disquette.
- Generic SCSI devices : une VM peut être connectée à des SCSI adapters supplémentaires.
- vGPUs : une VM peut utiliser les GPUs du physical host pour des activités à forte intensité de calcul.
- Precision Clock : fournit à une virtual machine un accès à l’heure système de l’ESXi host principal.
- vTPM : Trusted Platform Module 2.0 virtual cryptoprocessor, fournissant des fonctions de sécurité basées sur le matériel.
Le Virtual CPU (vCPU) et la virtual memory constituent le minimum requis en termes de virtual hardware. L’ajout d’un virtual hard disk, de virtual NICs et d’autres virtual devices rend la VM plus utile.
Pour plus d’informations sur le virtual machine hardware disponible et sur l’ajout de virtual hardware à une VM, consultez :
vSphere Virtual Machine Administration à cette adresse : https://docs.vmware.com/en/VMware-vSphere/8.0/TBD
¶ À propos de la Virtual Machine Console
La VM console fournit les fonctionnalités de souris, clavier et écran pour contrôler la VM.
Vous pouvez utiliser la remote console ou la Web console pour vous connecter aux périphériques du client.
Vous pouvez ouvrir la VM console à partir du vSphere Client :
- La Web console affiche la VM console dans un onglet séparé du navigateur.
- La remote console nécessite le téléchargement de l’application autonome VMware Remote Console (VMRC), qui s’ouvre dans une fenêtre distincte. L’application autonome VMware Remote Console permet de se connecter aux périphériques du client et de lancer des virtual machine consoles sur des remote hosts.
Vous utilisez la VM console pour accéder au BIOS ou à l’EFI de la VM, installer un operating system sur une VM, allumer ou éteindre la VM, et réinitialiser la VM.
La VM console n’est normalement pas utilisée pour se connecter à la VM pour les tâches quotidiennes. Remote Desktop Connection, Virtual Network Connection, ou d’autres options sont généralement utilisées pour se connecter au virtual desktop.
La VM console est utilisée pour des tâches telles que le power cycling, la configuration du hardware, et le dépannage des problèmes de network.
¶ Lab 14 : Ajout de Virtual Hardware
Utilisez le vSphere Client pour examiner la configuration d’une virtual machine et ajouter du virtual hardware à la virtual machine :
- Examiner la configuration d’une Virtual Machine
- Ajouter des Virtual Hard Disks à la Virtual Machine
- Comparer les Thin-Provisioned et Thick-Provisioned Disks
Retrouvez le lien du Lab en cliquant ici : Lab 14 : Ajout de Virtual Hardware
¶ Revue des objectifs d’apprentissage
- Identifier les fichiers qui composent une VM
- Comparer les versions de VM hardware
- Reconnaitre les composants de virtual hardware d’une VM
- Naviguer dans le vSphere Client et examiner les paramètres d’une VM
- Identifier les méthodes d’accès à une VM console
¶ Leçcon 3 : Modification des Virtual Machines
¶ Objectifs d’apprentissage
- Décrire les paramètres et options d’une virtual machine
- Ajouter un périphérique hot-pluggable
- Augmenter dynamiquement la taille d’un virtual disk
¶ Modification des paramètres de Machine Virtuelle
Vous pouvez modifier la configuration d’une VM en éditant les paramètres de la VM :
- Ajouter du virtual hardware :
— Vous pouvez ajouter certains composants lorsque la VM est powered on. - Supprimer du virtual hardware :
— Vous pouvez supprimer certains composants uniquement lorsque la VM est powered off. - Définir les options de VM.
- Contrôler les ressources CPU et mémoire d’une VM.
Vous pourriez avoir à modifier la configuration d’une VM, par exemple pour ajouter un network adapter ou un virtual disk.
Vous pouvez effectuer toutes les modifications de la VM lorsque la VM est powered off.
Certaines modifications de VM hardware peuvent être effectuées lorsque la VM est powered on.
¶ Périphériques à chaud
Avec l’option hot plug, vous pouvez ajouter des ressources à une VM en cours d’exécution.
Exemples de hot-pluggable devices :
- USB controllers
- Ethernet adapters
- Hard disk devices
Avec les systèmes d’exploitation invités supportés, vous pouvez également ajouter du CPU et de la memory pendant que la VM est powered on.
L’ajout de périphériques à un physical server ou le retrait de périphériques d’un physical server nécessite une interaction physique avec le serveur dans le data center.
Lorsque vous utilisez des VMs, les ressources peuvent être ajoutées dynamiquement sans interruption de service.
Vous devez shut down une VM pour retirer du hardware, mais vous pouvez reconfigurer la VM sans entrer dans le data center.
Vous pouvez ajouter du CPU et de la memory pendant que la VM est powered on.
Ces fonctionnalités sont appelées CPU Hot Add et Memory Hot Plug, et elles sont supportées uniquement sur les guest operating systems qui prennent en charge la fonctionnalité hot-pluggable.
Ces fonctionnalités sont désactivées par défaut. Pour utiliser ces fonctionnalités de hot plug, les exigences suivantes doivent être respectées :
- Vous devez installer VMware Tools.
- La VM doit utiliser la hardware version 11 ou ultérieure.
- Le guest operating system dans la VM doit supporter les fonctionnalités de CPU et de memory hot-plug.
- Les fonctionnalités de hot plug doivent être activées dans les paramètres CPU ou Memory de l’onglet Virtual Hardware.
Si le virtual NUMA est configuré avec les paramètres de virtual CPU hot-plug, la VM démarre sans virtual NUMA.
À la place, la VM utilise UMA (Uniform Memory Access).
¶ Augmentation dynamique de la taille d’un Virtual Disk
Vous pouvez augmenter la taille d’un virtual disk appartenant à une VM powered on.
- Le virtual disk ne doit pas avoir de snapshots attachés.
- Il peut être nécessaire d’utiliser des system tools pour rendre le nouvel espace utilisable.
Après avoir augmenté la taille d’un virtual disk, vous pourriez avoir besoin d’augmenter la taille du file system sur ce disque.
Utilisez l’outil approprié dans le guest OS pour configurer le file system afin d’utiliser l’espace disque nouvellement alloué.
¶ Expansion des disques Thin-Provisioned
Les thin-provisioned virtual disks peuvent être convertis en format thick, eager-zeroed.
Choisissez l’une des méthodes suivantes pour inflate un thin-provisioned disk sur une VM qui est powered on ou powered off :
- Sélectionnez le fichier de la VM avec l’extension .vmdk et choisissez Inflate.
- Sélectionnez thick-provisioned lorsque vous utilisez vSphere Storage vMotion pour migrer la VM vers un datastore différent.
Lorsque vous inflate un thin-provisioned disk, le virtual disk expansé occupe tout l’espace du datastore qui lui avait été initialement provisionné.
L’inflating d’un thin-provisioned disk convertit un thin disk en virtual disk au format thick-provisioned, eager-zeroed.
¶ Options de VM : Paramètres généraux
Vous pouvez utiliser l’onglet VM Options pour modifier des propriétés telles que le display name de la VM et le type de guest operating system installé.
Sous General Options, vous pouvez afficher l’emplacement et le nom du configuration file (avec l’extension .vmx) ainsi que l’emplacement du répertoire de la VM.
Vous pouvez sélectionner le texte du configuration file et de l’emplacement de travail pour les copier-coller dans un document. Cependant, seuls le display name et le type de guest operating system peuvent être modifiés.
La modification du display name ne change pas les noms de tous les fichiers de la VM ni le répertoire dans lequel la VM est stockée.
Lorsqu’une VM est créée, les noms de fichiers et le nom du répertoire associés à la VM sont basés sur son display name.
Mais le changement ultérieur du display name ne modifie pas le filename ni le nom du répertoire.
¶ Options de VM : Paramètres VMware Tools
Vous pouvez utiliser les contrôles de VMware Tools pour personnaliser les power buttons de la VM.
Lorsque vous utilisez les contrôles de VMware Tools pour personnaliser les power buttons d’une VM, la VM doit être powered off.
Vous pouvez sélectionner la case Check and upgrade VMware Tools before each power on pour vérifier s’il existe une version plus récente de VMware Tools.
Si une image ISO contenant une version plus récente est trouvée, VMware Tools est mis à jour lorsque la VM est power cycled.
Lorsque vous sélectionnez la case Synchronize guest time with host, l’horloge du guest operating system se synchronise avec celle du host.
Pour des informations sur les bonnes pratiques de gestion du temps pour les guest operating systems que vous utilisez, consultez les articles de la VMware Knowledge Base aux adresses suivantes :
¶ Options de VM : Paramètres de démarrage de la VM
Il se peut que vous ayez parfois besoin de définir les VM boot options.
Lorsque vous créez une VM et sélectionnez un guest operating system, le BIOS ou l’EFI est sélectionné automatiquement, selon le firmware supporté par le système d’exploitation.
Si le système d’exploitation supporte à la fois BIOS et EFI, vous pouvez modifier l’option de démarrage selon vos besoins. Cependant, vous devez effectuer ce changement avant d’installer le guest OS.
Le UEFI Secure Boot est une norme de sécurité qui garantit que seul le logiciel de confiance du fabricant est utilisé lors du démarrage de votre PC.
Dans un système d’exploitation qui supporte le UEFI Secure Boot, chaque élément du logiciel de démarrage est signé, y compris le bootloader, le kernel du système d’exploitation et les operating system drivers.
Si vous configurez le Secure Boot pour une VM, vous ne pouvez charger que des signed drivers dans cette VM.
Avec la valeur Boot Delay, vous pouvez définir un délai entre le moment où une VM est allumée et celui où le guest OS commence à démarrer.
Un démarrage différé peut être utile pour échelonner les démarrages des VMs lorsque plusieurs VMs sont powered on.
Vous pouvez modifier les paramètres BIOS ou EFI. Par exemple, vous pouvez forcer une VM à démarrer depuis un CD/DVD.
La prochaine fois que la VM sera powered on, elle passera directement dans le BIOS.
Un accès forcé à la configuration du firmware est beaucoup plus simple que d’allumer la VM, d’ouvrir une console et d’essayer rapidement d’appuyer sur la touche F2.
Avec le paramètre Failed Boot Recovery, vous pouvez configurer la VM pour réessayer de démarrer après 10 secondes (par défaut) si la VM ne trouve pas de boot device.
¶ Lab 15 : Modification des Machines Virtuelles
Modifiez la taille de la memory d’une VM, augmentez la taille du storage d’une VM, et renommez une VM :
- Ajuster l’allocation de Memory sur une Virtual Machine powered on
- Augmenter la taille d’un Virtual Disk
- Configurer le Guest OS pour reconnaître l’espace disque additionnel
- Renommer une Virtual Machine dans l’inventaire vCenter
Retrouvez le lien du Lab en cliquant ici : Lab 15 : Modification des Machines Virtuelles
¶ Revue des objectifs d’apprentissage
- Décrire les paramètres et options d’une Virtual Machine
- Ajouter un hot-pluggable device
- Augmenter dynamiquement la taille d’un virtual disk
¶ Leçon 4 : Création de Templates et Clonage de VMs
¶ Objectifs d’apprentissage
- Créer un template d’une virtual machine
- Déployer une virtual machine à partir d’un template
- Cloner une virtual machine
- Créer des customization specifications pour les guest operating systems
¶ À propos des Templates
Un template est une image statique d’une virtual machine.
Vous utilisez des templates pour créer et provisionner de nouvelles VMs.
Un template inclut généralement :
- Un guest operating system
- Une ou plusieurs applications
- Une configuration spécifique de VM hardware
- VMware Tools
Pour utiliser les templates, vous devez être connecté à vCenter.
La création de templates rend le provisioning des virtual machines beaucoup plus rapide et moins sujet aux erreurs que le provisioning de physical machines ou la création d’une VM à l’aide de l’assistant New Virtual Machine wizard.
Les templates coexistent avec les VMs dans l’inventory.
Vous pouvez organiser des collections de VMs et de templates dans des dossiers arbitraires et appliquer des permissions aux VMs et aux templates.
Vous pouvez convertir des VMs en templates sans avoir à copier entièrement les fichiers de la VM et créer un objet.
Vous pouvez déployer une VM à partir d’un template.
La VM déployée est ajoutée au dossier que vous avez sélectionné lors de la création du template.
Pour créer et utiliser des templates, vous devez être connecté à vCenter.
Vous ne pouvez pas utiliser de templates si vous utilisez VMware Host Client pour gérer un host directement.
¶ Création d’un Template : Cloner une VM en Template
Vous pouvez créer des templates en utilisant différentes méthodes.
L’une d’elles consiste à cloner la VM en template.
La VM peut être powered on ou powered off.
L’une des options offertes par Clone to Template est le choix du type de format pour stocker les virtual disks de la VM :
- Same format as source
- Thin-provisioned format
- Thick-provisioned lazy-zeroed format
- Thick-provisioned eager-zeroed format
¶ Création d’un Template : Conversion d’une VM en Template
Vous pouvez créer un template en convertissant une VM en template.
Dans ce cas, la VM doit être powered off.
L’option Convert to Template ne propose pas de choix de format et laisse le fichier disque de la VM inchangé.
Le configuration file de la VM (.vmx) est remplacé par un template configuration file (.vmtx).
¶ Création d’un Template : Cloner un Template
Vous pouvez créer un template à partir d’un template existant.
¶ Mise à jour des Templates
Vous mettez à jour un template pour inclure de nouveaux patches, ajouter ou supprimer du virtual hardware, mettre à niveau VMware Tools, mettre à jour la VM hardware version, et installer de nouvelles applications.
Pour mettre à jour un template :
-
Convertir le template en VM.
- Les VMs ne peuvent pas être déployées à partir de ce template tant qu’il est une VM.
-
Placer la VM sur un isolated network afin d’empêcher l’accès des utilisateurs.
-
Apporter les modifications nécessaires à la VM.
-
Convertir la VM en template.
Pour mettre à jour votre template afin d’inclure de nouveaux patches ou logiciels, vous n’avez pas besoin de créer un autre template.
À la place, vous convertissez le template en VM. Vous pouvez ensuite power on la VM et y apporter des modifications.
Pour plus de sécurité, vous pourriez vouloir empêcher les utilisateurs d’accéder à la VM pendant la mise à jour.
Pour bloquer l’accès, déconnectez la VM du network ou placez-la sur un isolated network.
Connectez-vous au guest operating system de la VM et appliquez le patch ou installez le logiciel.
Lorsque vous avez terminé, power off la VM et convertissez-la de nouveau en template.
¶ Déploiement de VMs à partir d’un Template
Pour déployer une VM, vous devez fournir des informations telles que le VM name, l’inventory location, le host, le datastore, et les données de guest operating system customization.
¶ Clonage des Machines Virtuelles
Le clonage d’une VM crée une VM qui est une copie exacte de l’originale :
- Le cloning est une alternative au déploiement d’une VM à partir d’un template.
- La source VM peut être powered on ou powered off.
Pour cloner une VM, vous devez être connecté à vCenter.
Vous ne pouvez pas cloner de VMs si vous utilisez VMware Host Client pour gérer directement un host.
Lorsque vous clonez une VM qui est powered on, les services et applications ne sont pas automatiquement quiesced lors du clonage de la VM.
Lorsque vous décidez entre cloner une VM ou déployer une VM à partir d’un template, prenez en compte les points suivants :
- Lorsque vous déployez plusieurs VMs à partir d’un template, toutes les VMs démarrent avec la même base image. Le clonage de plusieurs VMs à partir d’une VM en cours d’exécution peut ne pas créer des VMs identiques, selon l’activité en cours dans la VM au moment du clonage.
- Les VM templates utilisent de l’espace disque, donc vous devez planifier vos besoins en disk space en conséquence.
- Le déploiement d’une VM à partir d’un template est plus rapide que le clonage d’une VM en cours d’exécution, en particulier lorsque vous devez déployer plusieurs VMs en même temps.
¶ Personnalisation du Guest Operating System
Lorsque vous déployez une VM à partir d’un template ou que vous clonez une VM, vous pouvez personnaliser certains aspects du guest operating system.
En personnalisant un guest operating system, vous pouvez modifier des informations, y compris les détails suivants :
- Computer name
- Network settings
- License settings
- Time zone
- Administrator ou root password
- Windows Security Identifier
La personnalisation du guest operating system empêche les conflits qui pourraient survenir lorsque vous déployez une VM et un clone avec des paramètres de guest OS identiques.
Sans personnalisation, les VMs conservent le host name, l’IP address, etc., de la source VM ou du template.
¶ À propos des Customization Specifications
Vous pouvez créer une customization specification pour préparer le guest operating system :
- Les specifications sont stockées dans la vCenter database.
- Les Windows et Linux guests sont supportés.
Pour gérer les customization specifications, sélectionnez Policies and Profiles dans le main menu.
Dans le panneau VM Customization Specifications, vous pouvez créer des specifications ou gérer celles déjà existantes.
¶ Personnalisation du Guest Operating System
Lors du clonage d’une VM ou du déploiement d’une VM à partir d’un template, vous pouvez utiliser une customization specification pour préparer le guest operating system.
Vous pouvez définir les paramètres de customization en utilisant une customization specification existante lors du clonage ou du déploiement.
Vous créez la specification à l’avance. Pendant le clonage ou le déploiement, vous pouvez sélectionner la customization specification à appliquer à la nouvelle VM.
VMware Tools doit être installé sur le guest operating system que vous souhaitez personnaliser.
Le guest operating system doit être installé sur un disk attaché au SCSI node 0:0 dans la configuration de la VM.
Pour plus d’informations sur la personnalisation du guest operating system, consultez la documentation vSphere Virtual Machine Administration à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Lab 16 : Création de Templates et Déploiement de VMs
Créez un VM template, créez une customization specification, et déployez des VMs à partir d’un template :
- Créer un Virtual Machine Template
- Créer des Customization Specifications
- Déployer des Virtual Machines à partir d’un Template
Retrouvez le lien du Lab en cliquant ici : Lab 16 : Création de Templates et Déploiement de VMs
¶ Revue des objectifs d’apprentissage
- Créer un template d’une virtual machine
- Déployer une virtual machine à partir d’un template
- Cloner une virtual machine
- Créer des customization specifications pour les guest operating systems
¶ Leçon 5 : Introduction aux Content Libraries
¶ Objectifs d’apprentissage
- Identifier les avantages d’une content library
- Reconnaître les types de content libraries
- Créer une local content library
- Déployer une virtual machine à partir d’une content library
¶ À propos des Content Libraries
Les content libraries sont des dépôts de OVF templates et d’autres types de fichiers qui peuvent être partagés et synchronisés à travers les systèmes vCenter à l’échelle mondiale.
Les organisations peuvent avoir plusieurs instances de vCenter dans des data centers à travers le monde.
Sur ces instances de vCenter, elles peuvent avoir une collection de templates, d’ISO images, etc.
Le problème est que tous ces éléments sont indépendants les uns des autres, avec différentes versions de ces fichiers et templates sur diverses instances de vCenter.
La content library est la solution à ce problème.
Elle permet de stocker des OVF templates, des ISO images ou tout autre type de fichiers dans un emplacement central.
Les templates, images et fichiers peuvent être publiés, et d’autres content libraries peuvent s’y abonner et télécharger le contenu.
La content library maintient le contenu à jour en se synchronisant périodiquement avec le publisher, garantissant ainsi que la dernière version est disponible.
¶ Avantages des Content Libraries
L’efficacité du stockage et la cohérence sont des raisons essentielles d’installer et d’utiliser une content library.
Avec les content libraries, les administrateurs peuvent réaliser les fonctions suivantes :
- Stocker et partager du contenu, comme des templates, des ISO images, des scripts.
- Effectuer une gestion distribuée des fichiers.
- Synchroniser les content libraries entre plusieurs sites et instances vCenter.
- Monter un fichier ISO directement depuis une content library.
- Maintenir des versions de VM templates.
Les content libraries sont stockées sur des vSphere datastores.
Partager du contenu et garantir que ce contenu reste à jour sont des tâches majeures.
Par exemple, pour une instance principale de vCenter, vous créez une central content library pour stocker les copies originales des OVF templates, ISO images, scripts, et autres types de fichiers.
Lorsque vous publiez cette content library, d’autres bibliothèques, situées n’importe où dans le monde, peuvent s’y abonner et télécharger une copie exacte des données.
Lorsqu’un OVF template est ajouté, modifié ou supprimé du published catalog, le subscriber se synchronise avec le publisher, et les libraries sont mises à jour avec le contenu le plus récent.
À partir de vSphere 7, vous pouvez mettre à jour un template tout en déployant simultanément des VMs à partir de ce template.
De plus, la content library conserve deux copies du VM template, la version précédente et la version actuelle. Vous pouvez effectuer un roll back du template pour annuler les modifications qui y ont été apportées.
¶ Types de Content Libraries
Le contenu est stocké dans l’un des types de content library suivants :
- Local : contenu contrôlé par l’administrateur
- Published : une bibliothèque locale disponible pour abonnement
- Subscribed : une bibliothèque qui se synchronise avec une bibliothèque publiée
Les administrateurs peuvent modifier le contenu d’une local content library ou d’une published content library.
Les utilisateurs ne peuvent pas modifier le contenu d’une subscribed content library.
Une subscribed content library ne peut pas être publiée.
Une local library est la forme la plus simple de bibliothèque. Une local library est disponible dans les data centers qui sont des objets du local vCenter.
Une published library est une local library disponible pour abonnement.
En utilisant la vCenter database, la content library suit les changements de versions. Aucune option n’est disponible pour utiliser les versions précédentes du contenu.
Une subscribed library est configurée pour s’abonner à une published library.
Un administrateur ne peut pas modifier directement le contenu de la subscribed library. Cependant, l’administrateur peut contrôler la manière dont les données sont synchronisées vers la subscribed content library.
¶ Interface des Content Libraries
Pour créer et gérer vos content libraries, depuis le main menu, sélectionnez Content Libraries.
¶ Création d’une Local Content Library
Lorsque vous créez une content library, vous sélectionnez le type de content library, par exemple une Local content library.
¶ Remplissage de la Content Library avec des Templates
Vous pouvez remplir la content library avec les types de templates suivants :
VM Templates :
- Peuvent être stockés sur n’importe quel type de datastore, sauf NFS
- Stockés dans le format de disque par défaut du datastore (par exemple, thick-provisioned eager-zeroed)
- Sont associés à un host
- Apparaissent dans l’inventory vCenter
OVF Templates :
- Doivent être stockés sur le datastore (de n’importe quel type) associé à la content library
- Stockés en format thin-provisioned
- Ne sont pas associés à un host
- N’apparaissent pas dans l’inventory vCenter
Lorsque vous créez un VM template (au lieu d’un OVF template) dans une content library, l’élément de la bibliothèque est lié à un VM template dans l’inventory vCenter.
L’élément de la content library et l’objet correspondant dans l’inventory sont reliés de la manière suivante :
- Si vous convertissez le VM template dans l’inventory vCenter en VM, l’élément correspondant de la VM template library est supprimé.
- Si vous renommez le VM template dans l’inventory vCenter, l’élément correspondant de la VM template library est également renommé, et inversement.
- Si vous supprimez le VM template dans l’inventory vCenter, l’élément correspondant de la VM template library est également supprimé.
Pour la liste complète des différences entre les VM templates et les OVF templates dans une content library, consultez la documentation vSphere Virtual Machine Administration : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Ajout de VM Templates ou d’OVF Templates dans une Content Library
Lorsque vous clonez une virtual machine en template dans une content library, vous pouvez choisir de créer un VM template ou un OVF template.
Dans cet exemple, vous clonez la VM Photon-01 en un VM template dans une content library.
¶ Ajout d’OVF Templates dans une Content Library
Lorsque vous clonez un template depuis l’inventory vCenter vers un template dans une content library, le template est stocké comme un OVF template dans la bibliothèque.
¶ Visualisation des éléments d’une Content Library
Le contenu d’une content library est divisé en catégories :
-
Templates :
- VM templates
- OVF templates
-
Other Types :
- Tous les autres types de fichiers, tels que des ISO images
Vous pouvez monter un fichier ISO directement depuis une content library.
Vous connectez le périphérique CD/DVD à un fichier ISO stocké dans la content library, par exemple pour installer un guest OS sur une nouvelle VM.
Les fichiers ISO sont disponibles uniquement pour les VMs enregistrées sur un ESXi host pouvant accéder au datastore où est située la content library.
Ces fichiers ISO ne sont pas disponibles pour les VMs sur des hosts qui ne peuvent pas voir le datastore sur lequel la content library est située.
¶ Déploiement de VMs à partir d’une Content Library
Vous pouvez déployer des VMs à partir de templates dans une content library en utilisant l’assistant New Virtual Machine.
Sur la page Select a template, vous pouvez choisir un template depuis une content library ou depuis l’inventory vCenter.
L’onglet Content Library liste les OVF templates, et l’onglet Data Center liste les VM templates, y compris les VM templates que vous avez ajoutés à la content library.
¶ Lab 17 : Utilisation des content libraries locales
Créez une local content library pour cloner et déployer des machines virtuelles :
- Créer une local content library
- Créer un OVF Template dans la content library
- Créer un VM Template dans la content library
- Afficher les templates de la content library
- Déployer une VM à partir d’un template dans la content library
Retrouvez le lien du Lab en cliquant ici : Lab 17 : Utilisation des content libraries locales
¶ Révision des objectifs d’apprentissage
- Identifier les avantages d’une content library
- Reconnaître les différents types de content libraries
- Créer une local content library
- Déployer une virtual machine depuis une content library
¶ Leçon 6 : S’abonner aux content libraries
¶ Objectifs d’apprentissage
- Publier des content libraries
- S’abonner à une content library publiée
¶ Bibliothèques de contenu : Locales, publiées et abonnées
Vous pouvez publier une local content library afin que d’autres bibliothèques puissent s’y abonner et télécharger une copie des données.
Après la synchronisation, les published libraries et les subscribed libraries contiennent les mêmes éléments, ou la subscribed library contient uniquement les métadonnées des éléments.
Vous pouvez créer une local library comme source pour le contenu que vous souhaitez conserver ou partager. Vous créez la local library sur une seule instance de vCenter. Ensuite, vous pouvez ajouter ou supprimer des éléments dans la local library.
Vous pouvez publier une local library, et ce content library service endpoint peut être accessible par d’autres instances vCenter dans votre environnement virtuel, qu’elles soient ou non dans le même enhanced linked mode group. Lorsque vous publiez une bibliothèque, vous pouvez configurer la méthode d’authentification que la subscribed library doit utiliser pour s’y authentifier.
Vous pouvez créer une subscribed library et remplir son contenu en la synchronisant avec une published library. Vous pouvez choisir si une subscribed library contient des copies des fichiers de la published library ou uniquement les métadonnées des éléments de la bibliothèque.
La published library peut se trouver sur la même instance de vCenter que la subscribed library, ou plus probablement, la subscribed library peut référencer une published library située sur une autre instance de vCenter.
Vous ne pouvez pas ajouter d’éléments à une subscribed library. Vous pouvez uniquement ajouter des éléments à une local library ou à une published library.
Après la synchronisation, les deux bibliothèques contiennent les mêmes éléments, ou la subscribed library contient uniquement les métadonnées des éléments.
Vous pouvez publier cette content library afin que d’autres bibliothèques situées partout dans le monde puissent s’y abonner et télécharger une copie exacte des données. Si un modèle OVF template est ajouté, modifié ou supprimé de la published library, la subscribed library se synchronise avec la published library, et les bibliothèques sont mises à jour avec le contenu le plus récent.
¶ Publication d’une Content Library
Vous pouvez activer la publication sur une local content library en modifiant ses paramètres.
Vous pouvez ajouter une protection par mot de passe à la bibliothèque.
Les subscribed libraries utilisent l’URL de souscription pour accéder à la published library.
¶ Abonnement à une Content Library
Vous abonnez une content library à une published content library en configurant le chemin vers l’URL de souscription :
- Vous pouvez immédiatement télécharger tout le contenu de la bibliothèque vers l’emplacement de stockage que vous configurez.
- Pour économiser de l’espace, vous pouvez stocker uniquement les métadonnées des éléments jusqu’à leur utilisation.
Lorsqu’un abonnement à une content library est créé, l’administrateur choisit comment le contenu se synchronise avec la published content library. Le contenu peut être téléchargé immédiatement si l’espace de stockage n’est pas une contrainte.
La synchronisation peut être configurée à la demande (on-demand), de sorte que seules les métadonnées soient copiées lors de la création de l’abonnement. La totalité du contenu de la content library est téléchargée la première fois que ce contenu est utilisé. Ainsi, l’espace est économisé, car certains modèles (templates) et images ISO ne sont pas encore utilisés et donc pas téléchargés.
¶ Affichage des Content Libraries
Le volet Content Libraries affiche toutes les local libraries et subscribed libraries, ainsi que l’état d’activation de la publication sur une local library.
¶ Affichage des modèles de Content Library abonnés
Le volet OVF & OVA Templates répertorie les modèles OVF templates. Pour mettre à jour la liste, vous sélectionnez ACTIONS > Synchronize.
Le volet VM Templates répertorie les VM templates. Pour mettre à jour la liste, vous devez créer et publier un abonnement dans la published library afin de pousser les VM templates vers la subscribed library.
Vous pouvez synchroniser uniquement les OVF templates. Si un abonné lance une synchronisation avec une published library qui contient à la fois des VM templates et des OVF templates, seuls les OVF templates sont synchronisés dans la subscribed library. Les VM templates sont synchronisés lorsqu’une publisher library les publie à ses abonnés.
Vous pouvez publier uniquement les VM templates. Si vous publiez une bibliothèque entière qui contient à la fois des VM templates et des OVF templates, seuls les VM templates sont répliqués vers l’abonné. Pour synchroniser les OVF templates et d’autres types de fichiers, l’abonné doit initier la synchronisation.
¶ Création d’un abonnement pour publier des VM Templates
- Depuis le volet de la published library, sélectionnez ACTIONS > New Subscription et créez un abonnement.
- Une fois l’abonnement créé, sélectionnez l’abonnement dans la liste et cliquez sur PUBLISH.
Si vous ajoutez de nouveaux VM templates à la published library, vous devez les publier afin que la subscribed library les reçoive.
Les subscriptions vous permettent de publier des éléments de bibliothèque vers un subscriber à tout moment. Créez une subscription pour une publisher library afin de contrôler la distribution des templates vers le subscriber.
¶ Synchronisation des bibliothèques avec ou sans Enhanced Linked Mode
Les vitesses de transfert sont optimisées lors de la synchronisation des published libraries et des subscribed content libraries dans le même domaine vCenter Single Sign-On.
Si Enhanced Linked Mode est configuré entre plusieurs instances vCenter et que les ESXi hosts peuvent communiquer entre eux, alors la réplication s’effectue entre les ESXi hosts en utilisant NFC. Si les datastores utilisés par les published libraries et les subscribed libraries existent dans la même baie de stockage, alors VAAI est utilisé pour des transferts plus efficaces.
Lorsque Enhanced Linked Mode n’est pas disponible, le contenu d’une published library doit être transféré via HTTPS en utilisant le composant Transfer Service. Dans ce cas, trois scénarios sont possibles, en fonction de la configuration du stockage :
- Les published libraries et les subscribed libraries résident toutes deux sur un datastore.
- Les published libraries et les subscribed libraries résident toutes deux sur un système de fichiers NFS monté sur les instances vCenter.
- La published library réside sur un système de fichiers NFS, tandis que la subscribed library réside sur un datastore.
Lorsqu’un élément est modifié dans une content library, le numéro de l’élément est incrémenté pour signaler la modification. Le numéro de version de la content library dans son ensemble est également incrémenté. Ce processus est appelé simple versioning. Le Content Library Service détermine si une synchronisation doit avoir lieu en utilisant le simple versioning. Le simple versioning ne stocke pas plusieurs versions et n’offre pas de fonctionnalités de retour arrière (rollback). Il s’agit uniquement d’une valeur numérique attribuée à la content library et à son contenu.
Le numéro de version de la content library est vérifié en premier :
- Si ce numéro correspond à celui des published libraries et des subscribed libraries, aucune synchronisation n’est nécessaire.
- Si une divergence est détectée, le numéro de version de chaque élément de la bibliothèque est vérifié.
- Si des divergences sont constatées, seuls les éléments présentant ces divergences sont synchronisés.
¶ Configuration avancée
Vous pouvez utiliser la page Advanced Configuration pour contrôler et optimiser la manière dont une published library stocke et synchronise le contenu.
¶ Maximums de Content Library
La content library comporte les maximums de configuration suivants :
| Élément de configuration | Maximum |
|---|---|
| Taille d’un élément de content library | 1 To |
| Nombre total d’éléments par bibliothèque | 1 000 |
| Nombre total d’éléments de bibliothèque par instance vCenter (toutes bibliothèques confondues) | 2 000 |
| Nombre maximum d’opérations de synchronisation concurrentes sur l’instance vCenter de la published library | 16 |
| Nombre total de bibliothèques par instance vCenter | 1 000 |
La content library peut être prise en charge par un datastore ou stockée sur l’espace de stockage disponible de vCenter.
Quelle que soit l’option sélectionnée, la content library ne peut être prise en charge que par un seul système de fichiers ou un seul datastore.
La taille maximale d’un élément de bibliothèque est de 1 To.
Une content library peut contenir un maximum de 1 000 éléments et un total de 2 000 éléments pour toutes les bibliothèques d’une même instance vCenter.
Le nombre maximum d’opérations de synchronisation concurrentes sur l’instance vCenter de la published library est de 16.
La synchronisation automatique s’effectue toutes les 240 minutes par défaut, mais la durée et la fréquence peuvent être configurées dans les paramètres de content library advanced configuration.
L’administrateur peut synchroniser une content library entière ou un élément individuel à tout moment via le vSphere Client.
¶ Lab 18 : Utilisation des Content Libraries abonnées
Publiez une local content library et créez une seconde bibliothèque qui s’y abonne :
- Publier une Local Content Library
- Créer une Subscribed Content Library
- Créer une Subscription pour les VM Templates
- Déployer une VM depuis la Subscribed Content Library
Retrouvez le lien du Lab en cliquant ici : Lab 18 : Utilisation des Content Libraries abonnées
¶ Revue des objectifs d’apprentissage
- Publier des content libraries
- S’abonner à une published content library
¶ Leçon 7 : Gestion des templates dans une Content Library
¶ Objectifs d’apprentissage
- Gérer plusieurs versions de VM templates dans les content libraries
¶ Avantages de l’utilisation d’une Content Library pour gérer les VM Templates
Lorsqu’ils sont gérés par une content library, vous pouvez travailler avec les VM templates de la manière suivante :
- Apporter des modifications aux VM templates en les check-out.
- Déployer des VMs tout en appliquant des correctifs au VM template.
- Obtenir un historique des modifications apportées au VM template.
- Accéder à deux copies du VM template, la version précédente et la version actuelle.
- Revenir à une version précédente du VM template.
App-LibTemplate est géré par la content library SA-Local-Library.
La gestion des VM templates avec la content library présente plusieurs avantages :
- Vous pouvez surveiller les modifications qui ont été effectuées par des utilisateurs privilégiés.
- Vous pouvez corriger ou modifier des VMs pendant que le template est utilisé pour déployer des VMs.
- Vous pouvez consulter l’historique des modifications apportées à une VM.
¶ Vue d’ensemble du processus de gestion des versions de template
Pour créer une nouvelle version d’un template, vous effectuez les étapes suivantes :
- Check-out d’une VM depuis le template.
- Apporter des modifications à la VM.
- Check-in de la VM vers le template.
¶ Check-out d’une VM depuis le Template
Pour mettre à jour un VM template, vous utilisez l’onglet Versioning afin de faire un check-out d’une VM depuis le template.
Vous pouvez effectuer l’opération de check-out pour mettre à jour une machine virtuelle (virtual machine) à partir d’un VM template. Pendant ce processus, les autres utilisateurs ne peuvent pas faire de check-out du VM template, mais ils peuvent déployer une virtual machine depuis ce VM template sans aucune interruption.
Lorsque vous effectuez un check-out d’un VM template, vous ne pouvez pas convertir la virtual machine en template, ni migrer la virtual machine vers un autre inventaire vCenter.
¶ Apporter des modifications à la VM
Après avoir fait un check-out du template vers une VM, vous pouvez effectuer des modifications matérielles ou logicielles sur la VM.
Vous pouvez modifier la VM alors que le VM template reste disponible pour les déploiements de VMs.
Si vous ne souhaitez pas conserver les modifications apportées à la VM, vous pouvez supprimer la VM en check-out.
vSphere utilise la technologie de linked clone pour cloner un VM template lors du check-out. Ce clone de VM est utilisé pour les modifications et mises à jour, tandis que le VM template original reste disponible dans la content library pour le déploiement de VMs. Une fois les modifications apportées à la VM clonée terminées, celle-ci est réintégrée (re-merged) dans le VM template, la VM clonée est supprimée, et le VM template est mis à jour.
Vous pouvez supprimer la virtual machine en check-out afin d’éviter de créer de nouvelles versions ou d’empêcher d’autres utilisateurs d’utiliser une version défectueuse.
Pour supprimer la VM en check-out, cliquez sur l’ellipse à côté de la VM en check-out et sélectionnez Discard Checked Out VM.
¶ Check-in de la VM vers le Template
Après avoir apporté des modifications à la VM, vous effectuez un check-in de la VM vers le template.
Le champ Check in notes est obligatoire.
Lorsque vous effectuez un check-in de la VM vers un template, vous créez une nouvelle version du VM template contenant l’état mis à jour de la virtual machine.
¶ Affichage des versions de Template
Les informations de version apparaissent dans l’onglet Versioning.
Chaque fois que vous effectuez un check-in de la VM vers le template, vous créez une nouvelle version du VM template.
Les informations de versioning mettent en évidence les détails suivants :
- Qui a effectué les mises à jour
- Quand les mises à jour ont été effectuées
- Les notes ou informations ajoutées lors des mises à jour
La qualité des notes dans l’onglet Versioning peut varier, selon la personne qui les saisit. Quelle qu’en soit la qualité, les notes sont enregistrées et conservées dans la base de données vCenter jusqu’à la suppression du VM template.
¶ Suppression et restauration des versions de Template
Supprimez une version précédente d’un VM template si vous ne souhaitez plus autoriser l’utilisation de ce template.
Restaurez une version d’un VM template si :
- Le dernier VM template contient des modifications dont vous n’avez plus besoin.
- Vous avez commis une erreur lors de votre dernière modification.
La suppression d’un VM template retire le template et son contenu de l’inventaire.
¶ Lab 19 : Gestion des versions de Templates dans la Content Library
Gérez plusieurs versions d’un VM template dans la local content library :
- Faire un Check-out d’un VM template dans la Content Library
- Apporter des modifications au VM template
- Faire un Check-in du VM template dans la Content Library
- Revenir à une version précédente du VM template
Retrouvez le lien du Lab en cliquant ici : Lab 19 : Gestion des versions de Templates dans la Content Library
¶ Revue des objectifs d’apprentissage
- Gérer plusieurs versions de VM templates dans les content libraries
¶ Points clés
- vCenter fournit des fonctionnalités pour le provisionnement des virtual machines, telles que les templates, le clonage et les content libraries.
- En déployant des VMs à partir d’un template, vous pouvez créer de nombreuses VMs facilement et rapidement.
- Vous pouvez gérer dynamiquement la configuration d’une VM en ajoutant des périphériques hot-pluggable et en augmentant la taille du disque virtuel d’une VM.
- Vous pouvez publier une local content library afin que d’autres bibliothèques puissent s’y abonner et télécharger une copie exacte des données.
- Vous pouvez mettre à jour un VM template géré par une content library alors que ce même VM template est utilisé pour déployer des VMs.
Chapitre précédent : 6 - Configuration du stockage vSphere - Chapitre suivant : 8 - Gestion des machines virtuelles (VMs)