VMware a publié une nouvelle mise à jour vSphere 6.7 U3b.
Au niveau de cette version, il n’y a pas de nouvelles fonctionnalités.
Toutefois, de nombreux correctifs et mises à jour de sécurité ont été implémentés.
Cette version contient nombreux correctifs de sécurité pour :
Dans cet article, nous allons essayer de comprendre ce qu’est un Platform Services Controller.
À partir de vSphere 6.0, les composants vCenter sont regroupés en deux rôles séparés, comme suit :
PSC est un composant très important dans une plateforme vSphere, car il centralise de nombreuses fonctionnalités importantes.
Platform Services Controller appelé PSC, il simplifie et centralise les services tels que la gestion des licences, les tags, la gestion des identités avec les autorisations, les rôles, les domaines d’authentification unique (SSO) et les certificats.
Le PSC est un composant nécessaire pour pouvoir déployer le vCenter, sans PSC, il est impossible d’installer un vCenter.
Le déploiement est possible selon deux types d’installations :
Le mode intégré permet une installation de vCenter Server et PSC dans une même Appliance (une seule machine virtuelle), il s’agit du mode idéal pour les petits environnements.
Le mode externe permet de déployer une Appliance PSC en premier (une seule VM) et par la suite permet l’installation du vCenter (Une deuxième VM) en indiquant l’adresse du premier PSC Appliance.
Ce type de déploiement (External PSC) nous permet une grande flexibilité, tel que la possibilité de connecter plusieurs vCenter au même PSC et de mettre en place des mécanismes de haute disponibilité et d’équilibrage de charge entre plusieurs instances PSC synchronisées.
vSphere HA utilise le contrôle d’admission pour s’assurer que des ressources suffisantes sont disponible dans un cluster VMware pour assurer la disponibilité des machine virtuelles en cas de basculement à cause d’une de défaillance d’un hôte.
La base du contrôle d’admission vSphere HA est le nombre de défaillances d’hôte que le cluster est autorisé à tolérer (FTT : Number of Failures to Tolerate).
Trois types de contrôle d’admission sont disponibles :
Avec ce type de contrôle d’admission, vSphere HA vérifie qu’un pourcentage spécifié de ressources CPU et Mémoire est réservé pour le basculement.
Lorsque l’option de pourcentage de ressources de cluster est configurée, vSphere HA implémente le contrôle d’admission comme suite :
Prenons l’exemple suivantes pour un cluster VMware :
| Hôtes ESXI | CPU (Ghz) | Mémoire (Go) disponible |
| H1 | 9 | 9 |
| H2 | 9 | 6 |
| H3 | 6 | 6 |
| Machine Virtuelle | CPU (Ghz) | Mémoire (Go) |
| VM 1 | 2 | 1 |
| VM 2 | 2 | 1 |
| VM 3 | 1 | 2 |
| VM 4 | 1 | 1 |
| VM 5 | 1 | 1 |
Les ressources totales requises pour les machines virtuelles sous tension sont de 7 Ghz et 6 Go.
Le total des ressources hôte disponibles pour les machines virtuelles est de 24 Ghz et 21 Go. À partir de là, la capacité de processeur actuelle pour le basculement est de 70% ((24 Ghz – 7 Ghz)/24 Ghz). De même, la capacité de mémoire de basculement actuelle est de 71% (21 Go – 6 Go) / 21 Go).
Étant donné que la capacité de basculement configurée pour le cluster est de 25%, 45% des ressources CPU et 46% des ressources de mémoire sont toujours disponibles.
vSphere HA garantit que même si un nombre spécifié d’hôtes est défaillant, il reste suffisamment de ressources sur le cluster pour permettre le basculement de toutes les machines virtuelles à partir de ces hôtes. .
Donc, vSphere HA effectue le contrôle d’admission comme suit:
Nous allons illustrer par un exemple la méthode de calcul de la taille d’emplacement et son utilisation avec cette stratégie de contrôle d’admission, Considérez les hypothèses suivantes :
1– La taille d’emplacement est calculée en comparant à la fois les exigences de CPU et de mémoire des machines virtuelles et en sélectionnant la plus élevée.
Le besoin en CPU le plus élevé (partagé par VM1 et VM2) est de 2 GHz, tandis que le besoin en mémoire le plus élevé (VM3) est de 2 Go. Partant de là, la taille d’emplacement se compose d’un CPU de 2 GHz et d’une mémoire de 2 Go.
2– Le nombre maximum d’emplacements pouvant être pris en charge par chaque hôte est déterminé.
H1 peut prendre en charge quatre emplacements. H2 peut prendre en charge trois emplacements (le plus bas de 9 GHz/2 GHz et 6 Go/2 Go) et H3 peut aussi en prendre en charge trois.
3- La Capacité de basculement actuelle est calculée.
Le plus gros hôte est H1 et s’il est défectueux, le cluster contient toujours six slots, ce qui est suffisant pour les cinq machines virtuelles sous tension. Si H1 et H2 sont défectueux, il ne reste que trois emplacements, ce qui est insuffisant. Par conséquent, la Capacité de basculement actuelle est de 1.
Le cluster a un slot disponible (les six slots de H2 et H3 moins les cinq slots utilisés).
vSphere HA peut être configuré pour désigner des hôtes ESXI spécifiques comme hôtes de basculement. Avec le contrôle d’admission sur les hôtes de basculement dédiés, en cas de défaillance de l’hôte, vSphere HA tente de redémarrer ses machines virtuelles sur les hôtes de basculement prédéfinis. vSphere HA peut être configuré pour désigner des hôtes ESXI spécifiques comme hôtes de basculement. Avec le contrôle d’admission sur les hôtes de basculement dédiés,
Si cela n’est pas possible parce que les hôtes de basculement sont en panne ou que leurs ressources sont insuffisantes, vSphere HA tente de redémarrer ces VMs sur d’autres hôtes du cluster.
Pour que les fonctionnalités restent disponibles sur un hôte de basculement, vous ne pouvez pas mettre les machines virtuelles sous tension ni utiliser vMotion pour migrer des machines virtuelles vers un hôte de basculement.
De plus, DRS n’utilise pas d’hôte de basculement pour l’équilibrage de la charge.
Avec la publication de vSphere 6.7 U3 et de vSAN 6.7 U3, VMware a ajouté un nouvel outil de ligne de commande VSANTOP.
L’outil s’exécute sur les hôtes ESXi pour afficher les mesures de performance vSAN en temps réel.
VSANTOP vous permet de surveiller et de dépanner les performances vSAN à un niveau très granulaire.
Ce nouvel outil pratique peut aider les administrateurs et le support VMware à résoudre les problèmes liés à l’environnement vSAN.
Lien de la documentation officielle
L’utilisation de l’outil est assez simple : démarrer une session SSH sur l’un des hôtes ESXi membre du cluster vSAN et taper : vsantop (en minuscule).
[root@esxi:~] vsantopPour afficher les différentes vues et mesures de performances dans vsantop, entrez les commandes suivantes :
Pour augmenter le niveau de sécurité de vos hôtes ESXi, vous pouvez utiliser le mode Verrouillage (Lockdown Mode).
A partir de vSphere 6.0, VMware propose deux modes de verrouillage (normal et strict) et une liste d’utilisateurs exceptionnels.
Les utilisateurs exceptionnels ne perdent pas leurs privilèges lorsque l’hôte entre en mode de verrouillage.
Utilisez la liste d’utilisateurs exceptionnels pour ajouter les comptes de solutions tierces et d’applications externes qui doivent accéder directement aux hôtes ESXI lorsque ils sont en mode de verrouillage.
Si ESXi Shell ou SSH est activé et que l’hôte est placé en mode de verrouillage, les comptes de la liste des utilisateurs exceptionnels disposant de privilèges d’administrateur peuvent utiliser ces services. Pour tous les autres utilisateurs, l’accès ESXi Shell ou SSH est désactivé.
À partir de vSphere 6.0, les sessions ESXi ou SSH pour les utilisateurs ne disposant pas de privilèges d’administrateur sont fermées.
En mode de verrouillage, certains services sont désactivés et d’autres ne sont accessibles qu’à certains utilisateurs, veuillez trouver ci-dessous un récapitulatif du comportement du Lockdown Mode :
PNID (Primary Network IDentifier of vCenter Server) est le nom du système (FQDN) défini lors du déploiement de vCenter Server.
vCenter Server ne supporte pas la modification du nom PNID, cette limitation a été remontée à VMware par de nombreux clients et partenaires. (voir KB 2130599).
Heuresement, VMware a pris en charge ces remarques au niveau de vSphere 6.7 Update 3.
À partir de vSphere 6.7 Update 3, il est désormais possible de renommer le nom FQDN ou PNID du vCenter Server, contrairement aux versions précédentes de vSphere.
Cette nouvelle fonctionnalité offre aux clients plus de flexibilité dans la gestion des plateformes VMware.
Pour pouvoir bénéficier de cette nouvelle fonctionnalité de vCenter Server, vous devez disposer de :
Une fois que vous disposez des deux éléments précités, vous devez vérifier et prendre en compte les conditions préalables suivantes :
C’est un changement majeur, donc, une planification adéquate est essentielle.
Surtout, assurez-vous d’avoir des sauvegardes valide de vCenter Server.
VMware a annoncé la nouvelle version du produit vSphere, VMware vSphere 6.7 Update 3.
Cette nouvelle version de vSphere inclut de nouvelles fonctionnalités pour des opérations simplifiées et des performances accrues.
VMware vSphere 6.7 Update 3 introduira la prise en charge de plusieurs GPU virtuels NVIDIA GRID (vGPU) par machine virtuelle.
Vous pouvez configurer jusqu’à quatre vGPU NVIDIA connectés à une machine virtuelle, ce qui permet d’améliorer les graphiques et les performances des applications.
vSphere 6.7 update 3 est désormais compatible avec la 2e génération de processeurs AMD EPYC ™.
PNID (Primary Network IDentifier of vCenter Server) est le nom du système défini lors du déploiement de vCenter Server.
La recommandation générale consiste à utiliser le nom (FQDN), toutefois, il n’a pas été possible de modifier le nom FQDN appelé (PNID) de vCenter Server dans les versions précédentes de vSphere.
Heureusement, la version 6.7 Update 3 offre la possibilité de renommer le nom PNID.
NB : Le nom PNID peut être mise à jour à partir de l’interface VAMI (Virtual Appliance Management Interface).
Lorsque VCSA (vCenter Server Appliance) est installé avec une adresse IP dynamique basée sur un serveur DHCP, une fois l’adresse IP de VCSA modifiée, les enregistrements DNS doivent être mis à jour manuellement.
Avec vSphere 6.7 Update 3, l’utilisation du Dynamic DNS est prise en charge, ce qui permet au VCenter Server de pouvoir enregistrer et mettre à jour de manière dynamique ces enregistrements sur les serveurs DNS.
Plusieurs améliorations ont été apportées à la version 4 du pilote VMXNET3, telles que:
De plus, les pilotes suivants ont été mis à jour:
VMware continue d’améliorer vSAN, avec des fonctionnalités supplémentaires, une efficacité accrue et une gestion simplifiée dans vSAN 6.7 Update 3.
Managed Object Browser (MOB), est une interface graphique intégrée aux systèmes ESXi et vCenter.
Cet utilitaire vSphere vous permet de parcourir les informations détaillées sur des objets tels que des machines virtuelles, des banques de données et des pools de ressources.
Pour vérifier si MOB est activé, ouvrez un navigateur et entrez http://x.x.x.x/mob (remplacez x.x.x.x par l’adresse IP de vCenter Server ou de votre hôte ESXi).
Par défaut, MOB est désactivé dans vSphere 6.x et doit être activé manuellement.
Se connecter à l’hôte ESXI via le vSphere Web Client.
Cliquer sur Gérer ==> Système ==> Paramètres avancés et Sélectionner la clé Config.HostAgent.plugins.solo.enableMob et activez-la.
Pour plus de détails : https://kb.vmware.com/s/article/2108405
Une fois activé, MOB est accessible depuis un navigateur Web.
VxRail Event Code
Depuis la mise à niveau de VxRail 4.5 vers la version 4.7, une grande partie de l’interface de gestion de VxRail Manager a été intégrée au client vSphere 6.7 HTML5.
Depuis lors, les messages d’erreur, les notifications et les alertes VxRail sont disponibles sous l’interface vCenter (au lieu de l’interface VxRail Manager).
Cependant, ces codes de type VXRxxxx ne sont pas vraiment significatifs et ne décrivent pas vraiment le problème.
Pour vous simplifier la vie lors du dépannage de VxRail, je partage avec vous la liste des codes d’alerte et des événements générés par VxRail via le lien suivant : Event Code
En espérant que cet article vous sera utile.
Lors du démarrage d’une machine virtuelle hébergé sous VMware ESXI, l’erreur suivante peut se produire : Failed to lock the file.
Cette erreur est due au verrouillage des fichiers de la machine virtuelle, souvent le disque virtuel (*.VMDK).
Pour empêcher les modifications simultanées des fichiers critiques de la machine virtuelle, Les hôtes VMware ESXi établissent des verrous sur ces fichiers.
Quelques exemples où les fichiers des VMs sont verrouillés:
