Article de reference

VMware ESXi

VMware ESXi (anciennement ESX ) est un hyperviseur de type 1 de classe entreprise développé par VMware , une filiale de Broadcom , pour le déploiement et la gestion d'ordinateur...

VMware ESXi (anciennement ESX ) est un hyperviseur de type 1 de classe entreprise développé par VMware , une filiale de Broadcom , pour le déploiement et la gestion d'ordinateurs virtuels . En tant qu'hyperviseur de type 1, ESXi n'est pas une application logicielle installée sur un système d'exploitation (OS) ; il comprend et intègre plutôt des composants OS vitaux, tels qu'un noyau .

Après la version 4.1 (sortie en 2010), VMware a renommé ESX en ESXi . ESXi remplace Service Console (un système d'exploitation rudimentaire) par un système d'exploitation plus étroitement intégré. ESX/ESXi est le composant principal de la suite logicielle VMware Infrastructure .

Le nom ESX est à l'origine une abréviation de Elastic Sky X. [ En septembre 2004, le remplaçant d'ESX a été appelé en interne VMvisor , mais a ensuite été changé en ESXi (le « i » dans ESXi signifiant « intégré »).

Architecture

ESX fonctionne sur un système nu (sans système d'exploitation) contrairement aux autres produits VMware. Il comprend son propre noyau. Dans l'ancien VMware ESX, un noyau Linux était démarré en premier puis utilisé pour charger divers composants de virtualisation spécialisés, y compris ESX, autrement connu sous le nom de composant vmkernel. Le noyau Linux était la machine virtuelle principale ; il était invoqué par la console de service. Lors de l'exécution normale, le vmkernel s'exécutait sur l'ordinateur nu et la console de service basée sur Linux fonctionnait comme première machine virtuelle. VMware a abandonné le développement d'ESX à la version 4.1 et utilise désormais ESXi, qui n'inclut pas du tout de noyau Linux.

Le vmkernel est un micro-noyau avec trois interfaces : le matériel, les systèmes invités et la console de service (Console OS).

Interface avec le matériel

Le vmkernel gère directement le processeur et la mémoire, en utilisant l'analyse avant exécution (SBE) pour gérer les instructions CPU spéciales ou privilégiées et le SRAT (table d'allocation des ressources système) pour suivre la mémoire allouée.

L'accès à d'autres matériels (tels que les périphériques réseau ou de stockage) s'effectue à l'aide de modules. Au moins certains des modules dérivent de modules utilisés dans le noyau Linux . Pour accéder à ces modules, un module supplémentaire appelé vmklinuximplémente l'interface du module Linux. Selon le fichier README, « Ce module contient la couche d'émulation Linux utilisée par le vmkernel. »

Le vmkernel utilise les pilotes de périphériques :

  1. net/e100
  2. net/e1000
  3. net/e1000e
  4. net/bnx2
  5. filet/tg3
  6. filet/forcedeth
  7. net/pcnet32
  8. bloc/cciss
  9. scsi/adp94xx
  10. scsi/aic7xxx
  11. scsi/aic79xx
  12. SCSI/IPS
  13. scsi/lpfcdd-v732
  14. scsi/megaraid2
  15. scsi/mptscsi_2xx
  16. scsi/qla2200-v7.07
  17. scsi/megaraid_sas
  18. scsi/qla4010
  19. scsi/qla4022
  20. SCSI/VMKISCSI
  21. scsi/aacraid_esx30
  22. scsi/lpfcdd-v7xx
  23. scsi/qla2200-v7xx

Ces pilotes correspondent pour la plupart à ceux décrits dans la liste de compatibilité matérielle de VMware . Tous ces modules sont sous licence GPL . Les programmeurs les ont adaptés pour fonctionner avec le vmkernel : VMware Inc. a modifié le chargement des modules et quelques autres éléments mineurs.

Console de service

Dans ESX (et non ESXi), la console de service est un système d'exploitation à usage général résiduel principalement utilisé comme bootstrap pour le noyau VMware, vmkernel, et secondairement utilisé comme interface de gestion. Ces deux fonctions du système d'exploitation de la console sont obsolètes à partir de la version 5.0, car VMware migre exclusivement vers le modèle ESXi. La console de service, à toutes fins utiles, est le système d'exploitation utilisé pour interagir avec VMware ESX et les machines virtuelles qui s'exécutent sur le serveur.

Écran violet de la mort

Un écran de diagnostic violet tel qu'il apparaît dans VMware ESX Server 3.0
Un écran de diagnostic violet de VMware ESXi 4.1

En cas d'erreur matérielle, le vmkernel peut intercepter une exception de vérification de la machine. Cela entraîne l'affichage d'un message d'erreur sur un écran de diagnostic violet. C'est ce qu'on appelle familièrement écran de diagnostic violet ou écran violet de la mort (PSoD, cf écran bleu de la mort (BSoD)).

Lors de l'affichage d'un écran de diagnostic violet, vmkernel écrit les informations de débogage sur la partition de vidage de mémoire. Ces informations, ainsi que les codes d'erreur affichés sur l'écran de diagnostic violet, peuvent être utilisées par le support VMware pour déterminer la cause du problème.

Versions

VMware ESX était auparavant disponible en deux types principaux : ESX et ESXi, mais à partir de la version 5, l'ESX d'origine a été abandonné au profit d'ESXi.

ESX et ESXi antérieurs à la version 5.0 ne prennent pas en charge Windows 8/Windows 2012. Ces systèmes d'exploitation Microsoft ne peuvent fonctionner que sur ESXi 5.x ou version ultérieure.

VMware ESXi, une version plus compacte d'ESX, n'inclut pas la console de service ESX. Avant que Broadcom n'acquière VMware, cette dernière était disponible (sans qu'il soit nécessaire d'acheter une licence vCenter ) en téléchargement gratuit auprès de VMware, avec certaines fonctionnalités désactivées.

ESXi signifie « ESX intégré ».

VMware ESXi est à l'origine une version compacte de VMware ESX qui permettait une empreinte disque plus petite de 32 Mo sur l'hôte. Avec une console de configuration simple pour la plupart des configurations réseau et une interface client VMware Infrastructure basée à distance, cela permet de consacrer davantage de ressources aux environnements invités.

Il existe deux variantes d'ESXi :

  • Installation de VMware ESXi
  • Édition intégrée de VMware ESXi

Le même support peut être utilisé pour installer l'une ou l'autre de ces variantes en fonction de la taille du support cible. Il est possible de mettre à niveau ESXi vers VMware Infrastructure 3 ou vers VMware vSphere 4.0 ESXi.

Initialement nommé VMware ESX Server édition ESXi, après plusieurs révisions, le produit ESXi est finalement devenu VMware ESXi 3. De nouvelles éditions ont ensuite suivi : ESXi 3.5, ESXi 4, ESXi 5 et (à partir de 2015 ) ESXi 6.

Poursuite pour violation de la GPL

VMware a été poursuivi en justice par Christoph Hellwig, un développeur du noyau Linux. Le procès a débuté le 5 mars 2015. Il a été allégué que VMware avait détourné des parties du noyau Linux, et, après un rejet par le tribunal en 2016, Hellwig a annoncé qu'il ferait appel.

L'appel a été décidé en février 2019 et à nouveau rejeté par le tribunal allemand, au motif que les « exigences procédurales relatives à la charge de la preuve du plaignant » ne sont pas respectées.

En mars 2019, lors de la dernière étape du procès, le tribunal régional supérieur de Hambourg a également rejeté la plainte pour des raisons de procédure. Par la suite, VMware a officiellement annoncé qu'il supprimerait le code en question. Hellwig a ensuite retiré son dossier et a suspendu toute action en justice.

Produits connexes ou complémentaires

Les produits suivants fonctionnent conjointement avec ESX :

  • vCenter Server permet de surveiller et de gérer plusieurs serveurs ESX, ESXi et GSX. De plus, les utilisateurs doivent l'installer pour exécuter des services d'infrastructure tels que :
    • vMotion (transfert de machines virtuelles entre serveurs à la volée pendant leur exécution, sans aucun temps d'arrêt)
    • svMotion , également appelé Storage vMotion (transfert de machines virtuelles entre les LUN de stockage partagé à la volée, sans aucun temps d'arrêt)
    • vMotion amélioré, également appelé evMotion (un vMotion et un svMotion simultanés, pris en charge sur la version 5.1 et supérieure)
    • Planificateur de ressources distribuées (DRS) (vMotion automatisé basé sur les exigences/demandes de charge de l'hôte/de la machine virtuelle)
    • Haute disponibilité (HA) (redémarrage des systèmes d'exploitation invités des machines virtuelles en cas de défaillance d'un hôte ESX physique)
    • Tolérance aux pannes (FT) (basculement quasi instantané d'une machine virtuelle en cas de défaillance d'un hôte physique)
  • Converter permet aux utilisateurs de créer des machines virtuelles compatibles avec VMware ESX Server ou Workstation à partir de machines physiques ou de machines virtuelles créées par d'autres produits de virtualisation. Converter remplace les produits VMware « P2V Assistant » et « Importer » : P2V Assistant permet aux utilisateurs de convertir des machines physiques en machines virtuelles, et Importer permet d'importer des machines virtuelles à partir d'autres produits dans VMware Workstation.
  • vSphere Client (anciennement VMware Infrastructure Client) permet de surveiller et de gérer une instance unique d'un serveur ESX ou ESXi. Après ESX 4.1, vSphere Client n'était plus disponible à partir du serveur ESX/ESXi mais devait être téléchargé à partir du site Web de VMware.

Cisco Nexus 1000v

La connectivité réseau entre les hôtes ESX et les machines virtuelles qui y sont exécutées repose sur des cartes réseau virtuelles (à l'intérieur de la machine virtuelle) et des commutateurs virtuels. Ces derniers existent en deux versions : le vSwitch « standard » qui permet à plusieurs machines virtuelles sur un seul hôte ESX de partager une carte réseau physique et le « vSwitch distribué » où les vSwitchs sur différents hôtes ESX forment ensemble un commutateur logique. Cisco propose dans sa gamme de produits Cisco Nexus le Nexus 1000v , une version avancée du vSwitch distribué standard. Un Nexus 1000v se compose de deux parties : un module de supervision (VSM) et sur chaque hôte ESX un module Ethernet virtuel (VEM). Le VSM fonctionne comme un appareil virtuel au sein du cluster ESX ou sur du matériel dédié (série Nexus 1010) et le VEM fonctionne comme un module sur chaque hôte et remplace un dvS (commutateur virtuel distribué) standard de VMware.

La configuration du commutateur est effectuée sur le VSM à l'aide de la CLI NX-OS standard . Elle offre des fonctionnalités permettant de créer des profils de port standard qui peuvent ensuite être attribués à des machines virtuelles à l'aide de vCenter.

Il existe plusieurs différences entre le dvS standard et le N1000v. L'une d'entre elles est que le commutateur Cisco prend généralement en charge les technologies réseau telles que l'agrégation de liens LACP ou que le commutateur VMware prend en charge de nouvelles fonctionnalités telles que le routage basé sur la charge physique de la carte réseau. Cependant, la principale différence réside dans l'architecture : le Nexus 1000v fonctionne de la même manière qu'un commutateur Ethernet physique tandis que le dvS s'appuie sur les informations d'ESX. Cela a des conséquences, par exemple, en termes d'évolutivité, où la limite Kappa pour un N1000v est de 2048 ports virtuels contre 60000 pour un dvS.

Le Nexus1000v est développé en coopération entre Cisco et VMware et utilise l' API du dvS.

Outils de gestion tiers

VMware ESX étant un leader sur le marché de la virtualisation des serveurs, les fournisseurs de logiciels et de matériel proposent une gamme d'outils permettant d'intégrer leurs produits ou services à ESX. Citons par exemple les produits de Veeam Software avec des applications de sauvegarde et de gestion et un plug-in permettant de surveiller et de gérer ESX à l'aide de HP OpenView , Quest Software avec une gamme d'applications de gestion et de sauvegarde et la plupart des principaux fournisseurs de solutions de sauvegarde proposent des plug-ins ou des modules pour ESX. L'utilisation de Microsoft Operations Manager (SCOM) 2007/2012 avec un pack de gestion Bridgeways ESX permet à l'utilisateur d'avoir une vue en temps réel de l'état de santé du centre de données ESX.

Les fournisseurs de matériel tels que Hewlett Packard Enterprise et Dell incluent des outils permettant de prendre en charge l'utilisation d'ESX(i) sur leurs plates-formes matérielles. Le module ESX pour la plate-forme de gestion OpenManage de Dell en est un exemple.

VMware a ajouté un client Web depuis la version 5, mais il ne fonctionne que sur vCenter et ne contient pas toutes les fonctionnalités. vEMan est une application Linux qui tente de combler cette lacune. Ce ne sont là que quelques exemples : il existe de nombreux produits tiers permettant de gérer, de surveiller ou de sauvegarder les infrastructures ESX et les machines virtuelles qui y sont exécutées.

Limitations connues

En septembre 2020, voici les limitations connues de VMware ESXi 7.0 U1.

Limitations des infrastructures

Certains maximums dans ESXi Server 7.0 peuvent influencer la conception des centres de données :

  • RAM maximale du système invité : 24 To
  • RAM maximale du système hôte : 24 To
  • Nombre d'hôtes dans un cluster à haute disponibilité ou Distributed Resource Scheduler : 96
  • Nombre maximal de processeurs par machine virtuelle : 768
  • Nombre maximal de processeurs par hôte : 768
  • Nombre maximal de CPU virtuels par cœur de CPU physique : 32
  • Nombre maximal de machines virtuelles par hôte : 1 024
  • Nombre maximal de processeurs virtuels par machine virtuelle tolérante aux pannes : 8
  • RAM système invité maximale par machine virtuelle tolérante aux pannes : 128 Go
  • Taille maximale du volume VMFS5 : 64 To, mais la taille maximale du fichier est de 62 To - 512 octets
  • Mémoire vidéo maximale par machine virtuelle : 4 Go

Limitations de performances

En termes de performances, la virtualisation impose un coût en termes de travail supplémentaire que le processeur doit effectuer pour virtualiser le matériel sous-jacent. Les instructions qui effectuent ce travail supplémentaire, ainsi que d'autres activités qui nécessitent une virtualisation, ont tendance à se trouver dans les appels du système d'exploitation. Dans un système d'exploitation non modifié, les appels au système d'exploitation introduisent la plus grande partie de la « charge » de virtualisation.

La paravirtualisation ou d'autres techniques de virtualisation peuvent aider à résoudre ces problèmes. VMware a développé l'interface de machine virtuelle à cet effet et certains systèmes d'exploitation la prennent actuellement en charge. Une comparaison entre la virtualisation complète et la paravirtualisation pour le serveur ESX montre que dans certains cas, la paravirtualisation est beaucoup plus rapide.

Limitations du réseau

Lorsque vous utilisez les fonctionnalités réseau avancées et étendues à l'aide du commutateur virtuel distribué Cisco Nexus 1000v, les limitations suivantes liées au réseau s'appliquent :

  • 64 hôtes ESX/ESXi par VSM (Virtual Supervisor Module)
  • 2048 interfaces Ethernet virtuelles par VMware vDS (commutateur distribué virtuel)
  • et un maximum de 216 interfaces virtuelles par hôte ESX/ESXi
  • 2048 VLAN actifs (un à utiliser pour la communication entre les VEM et VSM)
  • 2048 profils de port
  • 32 cartes réseau physiques par hôte ESX/ESXi (physique)
  • 256 canaux de port par VMware vDS (commutateur distribué virtuel)
  • et un maximum de 8 canaux de port par hôte ESX/ESXi

Limitations de la structure Fibre Channel

Quel que soit le type d'adaptateur SCSI virtuel utilisé, il existe les limitations suivantes :

  • Maximum de 4 adaptateurs SCSI virtuels, dont l'un doit être dédié à l'utilisation du disque virtuel
  • Maximum de 64 LUN SCSI par adaptateur

Plus d articles de Worldlex Wiki

Revenez a l index pour explorer davantage de pages sur l histoire, la science, la culture, la geographie et la societe en francais.

Explorer l index