vSphere 6.5 – Les nouveautés

Ceci est le premier d’une série d’articles concernant vSphere 6.5, et principalement les nouveautés concernant le vCenter. J’ajouterai les liens dans cet article au fur et à mesure où ils seront publiés.
Il n’y a désormais quasiment plus de contrainte nécessitant de conserver un vCenter sous Windows au lieu de passer à vCenter Server Appliance. Au contraire, certaines fonctionnalités ne sont désormais supportées que sur vCenter Server Appliance et non sous Windows.



Nouvelle interface de gestion de vCenter Server Appliance

L’interface d’administration de l’appliance s’est enrichie.

Outre les éléments présents en 6.0, apparaissent de nouvelles statistiques d’utilisation réseau, CPU, mémoire et database.
Et le choix de la langue d’interface est cette fois évidente, avec une url se terminant par ?locale=en, ?locale=fr ou autre.



Migration de vCenter

Un outil de migration de vCenter était apparu avec vSphere 6.0 Update 2.
Avec vSphere 6.5, cet outil évolue et prends désormais en charge les migration depuis les vCenters sous Windows en versions 5.5 et 6.0 vers vCenter Server Appliance 6.5.
C’est le même outil qui permet de déployer un nouveau vCenter Server Appliance ou d’en faire une restauration.

Les fans de Linux ou Mac seront content, l’outil de migration est multi-plateforme.

Voir l’article vSphere 6.5 – Upgrade vers vCenter Server Appliance 6.5



vCenter Server Backup and Restore

vCenter Server Appliance propose une fonctionnalité de sauvegarde/restauration des paramètres et de l’historique du vCenter.
Pour l’instant cette fonction n’est accessible que manuellement dans l’interface de gestion ou bien via les APIs. Espérons que VMware fornira rapidement la fonction PowerCLI correspondante, et/ou que les différents éditeurs tiers proposeront des outils d’automatisation.

Voir l’article vSphere 6.5 – Upgrade vers vCenter Server Appliance 6.5



VMware Update Manager

Il est désormais intégré au vCenter Server Appliance. Plus besoin d’un serveur Windows pour cette fonctionnalité.

L’outil de migration cité plus haut se charge de transférer les paramètres du VUM dédié à celui intégré au vCenter.
Ne restera que quelques petits ajustements à faire, par exemple si VUM allait chercher sur un disque local ou UNC les données générées par UMDS. Il est toujours possible de télécharger les mises à jour avec Update Manager Dowload Service 6.5, mais le vCenter devra aller les chercher en http.



vSphere Web Client – http://[vcenter_fqdn]/vsphere-client

C’est désormais le client incontournable, car c’est le seul disposant de toutes les fonctionnalités, en attendant que le vSphere Client HTML5 monte en puissance.
Pas de révolution si ce n’est quelques améliorations cosmétiques et quelques rafraîchissements dynamiques qui font leur apparition.



vSphere Client – http://[vcenter_fqdn]/ui

Je pense que c’est la fonctionnalité qui m’a le moins convaincu, bien qu’elle soit prometteuse.

Ce nouveau client, qui reprend le nom du client C# (et tant pis pour la confusion), lequel n’est pas porté en 6.5, est enfin officiellement supporté par VMware et activé par défaut. Développé en HTML5 et n’ayant pas besoin de plugin, il est compatible avec tous les navigateurs.

Il permettra à terme de s’affranchir de Flash, mais en est encore loin car il lui manque nombre de fonctionnalités. Cependant VMware a annoncé qu’il serait mis à jour régulièrement, indépendemment de la montée de version du vCenter.



ESXi Secure Boot

Il s’agit d’un mode de sécurité lié à l’UEFI dans lequel tous les vib de l’hyperviseur doivent être signés et sont contrôlés à chaque démarrage.
Lorsqu’il est activé, il est impossible d’installer un vib non signé, et si un vib non signé avait été installé avant activation il ne pourrait alors plus s’exécuter (bloquant potentiellement tout démarrage de VM ou certaines fonctionnalités, selon la fonction du vib).

Pour la petite histoire, j’ai eu l’occasion de l’expérimenter sans le vouloir, et je me suis fait des frayeurs lors de l’upgrade de mon ESX physique en 6.5.
J’avais dans le passé installé Unlocker (http://www.insanelymac.com/forum/files/file/339-unlocker/) pour ajouter le support des dernières versions de MacOS X. C’est bien sûr à ne surtout pas faire en prod. Toujours est-il que cet utilitaire était installé et que je l’avais oublié.
Après upgrade en 6.5, impossible de démarrer quelque VM que ce soit. J’obtenais systématiquement le message « Transport (VMDB) error -45: Failed to connect to peer process. » et rien de plus clair dans les logs.
Il m’a fallu une bonne heure pour identifier la cause. Après désinstallation de Unlocker et reboot de l’ESX, tout est rentré dans l’ordre.
J’aurais pu aussi désactiver secure boot, mais je n’avais plus besoin de Unlocker de toute façon.



VM Secure Boot

C’est la déclinaison du Secure Boot au niveau de la VM, qui nécessitera que tous les drivers soient signés numériquement.
Il faut passer le boot de la VM en mode EFI et activer le secure boot. Attention, la bascule de Bios à EFI après installation de l’OS peut lui poser des problèmes de démarrage.



vCenter Server High Availability

vCenter Server Appliance intègre désormais nativement une option de haute disponibilité.
Le vCenter est cloné en nœuds actifs, passifs ou témoins qui assurent la continuité en cas de perte du nœud actif (perte d’un host par exemple).

Je n’ai pas fait de test sur une infra physique, uniquement sur mon home lab, avec des hosts virtuels hébergeant eux-même le vCenter. La réactivité est donc probablement moins bonne qu’en production. Cependant à mon sens ce n’est pas réellement de la haute disponibilité, en raison des délais de démarrage des process sur le noeud qui devient actif.
Mais ça reste une excellente solution pour reprendre rapidement et automatiquement la main sur une infra qui a perdu son vCenter actif.

Voir l’article vSphere 6.5 – vCenter Server High Availability.



Image Builder

C’est outil, nécessaire à Auto Deploy mais pouvant être utilisé seul est passé en mode graphique (même si PowerCLI reste nécessaire pour certaines tâches).
Il permet notamment de créer de nouvelles images ESXi incluant toutes les VIBs spécifiques nécessaires à un environnement donné (drivers ou autres).

Voir l’article vSphere 6.5 – Image Builder



Auto Deploy

Auto Deploy permet de déployer des hosts ESXi automatiquement en s’appuyant sur les images enregistrées dans Image Builder (ainsi que sur une infra de boot PXE non fournie). Cette fonctionnalité existait déjà mais ne s’administrait que via PowerCLI. En vSphere 6.5, une interface graphique apparaît, même si PowerCLI reste nécessaire pour certaines options.

Voir l’article vSphere 6.5 – Auto Deploy.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *