IMG_3738

VMSA-2018-0027, un patch critique pour les hyperviseurs VMware

Il y a quelques jours (le 31 Octobre), la société Chaitin Tech, spécialisée dans la sécurité, a annoncé qu’un de ses employés avait réussi à obtenir un accès au shell d’un ESXi en mode root depuis une VM hébergée sur celui-ci. Au delà de la performance technique, assez exceptionnelle il faut bien le dire (je n’ai pas de souvenir récent qu’il y ait déjà eu un tel exploit de découvert), cela signifiait pour nous tous un risque non négligeable de hacking pour nos hyperviseurs hébergeant des VMs exposées au 4 vents.

Heureusement, cette faille présente dans le stack vmxnet3 n’a pas été rendue publique, elle a au contraire été transmise directement à VMware pour patch ASAP. Celui-ci est donc disponible pour les 3 Hyperviseurs de la société, ESXi, Workstation et Fusion et je vous encourage bien entendu à le passer sans attendre et en priorité sur vos hyperviseurs les plus exposés.

Merci à Antoine “Yoltie” (un des membres émérites de notre équipe de production), pour avoir relayé l’info sur Twitter !

Le post sur le blog VMware, ici.
Vous pouvez consulter le security advisory chez VMware, ici.
Le bulletin français du CERT-FR est disponible ici.

IMG_3687

ESXi/ARM : Retour sur le portage vers Raspberry Pi

Rappelez-vous, en Août dernier, VMware annonçait le portage de ESXi sur ARM64 (voir mon billet ici). A l’époque, la plateforme avait été présentée lors du keynote comme fonctionnant sur du matériel “server-grade” et disposant déjà de la plupart des fonctions standards comme vMotion.

Entre temps, l’équipe en charge de ce projet nous a concocté une petite surprise, une prouesse en fait, en l’état du développement de ESXi/ARM : son adaptation à la plateforme RaspBerry Pi (version 3) ! Assez incroyable, quand on pense aux capacités très modestes de cette plateforme, alimentée par son port USB ^^

J’ai eu l’occasion de discuter avec Régis Duchesne, membre de l’équipe en charge de ce projet et qui était présent au stand IoT/Edge computing hier. Voici un petit compte-rendu de cette super rencontre.

Lire la suite …

IMG_3618

IBM Cloud : big blue is back ?

Petite update du billet à 23h30 : annonce de la GA de vROps for Power Systems

On les avait presque oubliés, après les grandes années 80/90 (IBM36/38, AS400, IBM Global Services etc.), où ils étaient LA référence (toujours très chère, mais référence tout de même) dans le matériel, l’intégration et le consulting. Et puis … petit à petit, IBM s’est fait plus discret, voir confidentiel, en tout cas du point de vue de l’IT de ces 10 dernières années. Il faut dire qu’avec la revente successive à Lenovo de son segment PC/Notebooks et plus tard le reste de sa division x86, big blue a perdu un peu contact avec le monde qu’on appelait encore “Open”.

Pour autant, à défaut de faire le buzz, IBM, comme souvent, a continué à se moderniser et suivre les grandes tendances du marché, notamment autour du Cloud. A tel point qu’aujourd’hui, grâce à un partenariat visiblement très fort, IBM revient sous le feu des projecteurs avec son offre IBM Cloud …

Lire la suite …

IMG_3490

VMworld 2018 : retour sur la General Session

Bonjour à tous ! Me voici de nouveau au VMworld, pour une année de plus ! Comme twitté ce matin, les années défilent à vitesse grand-V, à tel point que présentement, j’en suis à ma septième, rien que ça ! Sept ans pendant lesquels le discours de VMware a évolué, s’est consolidé autour d’une idée maîtresse qui est parfaitement résumée par Pat Gelsinger, lors de la general Session de ce matin, par “Any cloud, Any application, Any device”.

Le fait est qu’aujourd’hui, pour fêter les 10 ans d’existence du salon en Europe, VMware porte aujourd’hui une offre quasi complète dans tous les domaines de l’IT.

Retour sur la grand-messe d’ouverture…

Lire la suite …

IMG_1988

Mise à jour VxRail 4.5.225 : récit d’une épopée

Rappelez-vous (voir ici), il y a 7 mois environ, nous lancions notre chantier de mise en oeuvre de notre nouveau cluster VxRail généraliste, dit “le monstre”. En l’espace d’environ 2 mois, l’ensemble de l’environnement passait en production et la migration d’un peu plus de 500 VMs pouvait commencer. A l’époque, les machines tournaient sur ESXi 6.5 patch 02 / VSAN 6.6 pour un ensemble VxRail en 4.5.152. Même si le cluster a, depuis, été parfaitement stable coté service (c’est l’essentiel), nous avons encore souffert de certains bugs de jeunesse sur la partie purement management et supervision hardware de nos serveurs PowerEdge P570F, malgré une nette amélioration depuis nos gros ennuis de fin d’année dernière (voir mes nombreux billets sur VxRail … allez, je vous laissez cliquer sur la section en haut au centre ^^).

Pour autant, le tremblement de terre provoqué par le récent bug VSAN de corruption potentielle (dont j’ai longuement parlé aussi entre fin septembre et début octobre) nous a contraint à anticiper quelque peu la mise à jour de notre VxRail pour passer de la “152” à la toute dernière version disposant du patch critique, la “225”. Je vous propose le récit de cette épopée, qui, sans trop anticiper sur mes conclusions, s’est globalement très bien déroulée, même si nous n’avions pas du tout anticipé sa durée réelle…

Lire la suite …

IMG_3029

vSphere 6.7 update 1 est disponible !

Après son annonce en grande pompe lors du VMworld de Las Vegas cet été 2018, la nouvelle itération de vSphere 6.7 dite “Update 1” est enfin sortie ! On va pouvoir tester ça en long, large et travers. ESXi 6.7U1 et vCenter 6.7U1 sont donc disponibles au téléchargement dans votre “My VMware”. Je reviendrai plus en détail sur ces versions dans un prochain billet, promis !

Bon, je retourne à ma mise à jour VxRail en 4.5.225. Je vous raconterai ça aussi… laborieux mais intéressant !

Les release notes d’ESXi 6.7u1, de la lecture ici, et son téléchargement par .
Les release notes de vCenter 6.7u1 à lire ici, les téléchargements associés sont par .

IMG_2769

Point de situation sur le bug resync/extend/resync de VSAN 6.6+

EDIT du 16/10/2018 : on vient d’avoir la confirmation que les corruptions peuvent aussi survenir lors que l’on réalisé un expand sans que celui ne déclenche l’ajout d’un component.

Mon précédent billet sur le sujet faisait état d’un bug sur les dernières versions de VSAN à partir de la 6.6.0 pouvant, dans certaines conditions, mener à des corruptions de données sur certaines VMs “à risque”. L’heure est venue, je pense de faire le tour de la question après pas mal de rebondissement depuis quelques jours.

Il a été difficile d’arriver à obtenir des informations claires pendant cette période et le caractère éminemment critique de ce bug (la corruption de données étant, sans doute, le pire scénario pour un constructeur ou un éditeur de solutions de stockage quel qu’il soit) a forcément généré pas mal d’anxiété parmi les clients de VMware et Dell EMC ayant des productions sur ces versions. la récente communauté VMUG France a été particulièrement active à cette occasion et a d’ores et déjà prouvé, s’il en était encore besoin, tout son intérêt, notamment pendant ces périodes tendues.

Je vous propose donc un nouveau billet précis et donnant des informations vérifiées et confirmées par le support VMware.

Lire la suite …

IMG_3160

VSAN 6.6/6.7 : attention aux extensions de vmdk sur vos VM (maj)

EDIT5 du 27/09/2018 : J’ai créé un autre article qui fait un point de situation global.

Bonsoir à tous !

Ca fait plaisir de vous retrouver après plus de 15 jours d’absence. La cause : un début de rentrée assez dingue pour ce qui me concerne. Cela explique, sans l’excuser, le désert de news sur vBlog, alors que l’actualité est pourtant riche en ce moment (VMUGFR, retour sur les annonces du VMworld 2018 de Las Vegas, quelques REX sur des gros incidents récents sur notre prod etc. …).

Je rouvre les vannes techniquement en vous faisant part d’une alerte sur laquelle tous les admins VSAN devraient être vigilants. A l’occasion du reboot VMUG France qui s’est tenu hier matin à Paris (c’était génial, mais je vous ferai un billet spécial ce week-end), j’ai eu l’occasion d’échanger avec des éminents collègues au sujet de nos productions respectives et ils m’ont fait part d’un bug bien inquiétant rencontré depuis plusieurs semaines chez eux. Il porte sur des cas spécifiques de corruption de données sur leurs environnements Exchange tournant sur VSAN, précisément. VMware est bien entendu sollicité et en cours de qualification/caractérisation actuellement.

Oops, même si ce n’est pas une généralité (cela n’a rien de systématique), la corruption de données n’est jamais à prendre à la légère sur un support de stockage, quel qu’il soit. Voici quelques détails des conditions particulières pouvant conduire à cette extrémité.

Lire la suite …

DFC2C31C-39EA-4FAB-AFC2-3F2EE704E0B0

Le manuel du parfait plombier VSAN (maj continue)

Dernière mise à jour : 24/09/2018

Depuis que VSAN est arrivé sur nos infrastructures de production et que, par le truchement de quelques incidents, nous avons un peu progressé dans la connaissance et la maîtrise de cette technologies je vous propose de recenser les différentes infos et commandes utiles qui nous servent de plus en plus au quotidien. Je ferai évoluer ce billet spécifique au fur et à mesure de nos découvertes ! Evidemment, si vous avez des hints & tips à rajouter, n’hésitez pas non plus à me contacter directement ou a ajouter des commentaires à ce billet.

La liste des mises à jour se trouve en fin de billet. Ajoutez-le à vos favoris, au cas où !

Lire la suite …

Gouffre_Twitter

Faille Intel Foreshadow/L1TF : adieu l’hyperthreading …

EDIT du 31/08/2018: J’ai réécris l’introduction de ce billet décrivant la faille. Merci à Fabien pour m’avoir poussé à creuser un peu plus, car j’ai dit quelques bêtises auparavant ! Ceci étant, je ne suis pas à l’abris d’avoir laissé quelques coquilles, donc je vous conseille, pour plus d’infos au sujet de Foreshadow, d’ailler consulter les sites officiels.

Vous avez sans doute tous entendu parler récemment de la nouvelle faille hardware, dite “Foreshadow”, sur les processeurs Intel. Cette faille concerne en fait quasi tous les processeurs produits par la société depuis la deuxième génération de processeurs Core iX. Derrière Foreshadow se cache en fait 3 failles différentes mais utilisant les mêmes méthodes et ayant les mêmes effets : l’accès potentiel d’un processus non privilégié à des portions de mémoire protégées. La faille regroupe en fait trois CVE, CVE-2018-3615, CVE-2018-3620 et CVE-2018-3646. La méthode reste la même que pour Meltdown, trouver des failles dans le code du processeur afin de pouvoir avoir accès à des données en principe inaccessibles, présentes sur le cache L1. Foreshadow exploite encore le talon d’Achille des processeurs, très exposé en ce moment, le “Speculative Branch Execution”, mais aussi le système de gestion de pages mémoire (à la base des fonctions de swap de nos O.S.), d’où son nom technique “L1TF”. Allez voir la petite vidéo très intéressante chez RedHat qui explique ça assez clairement et simplement ici.

Cette nouvelle faille concerne aussi, pour les processeurs les plus récents, les enclaves sécurisés par SGX. La SGX est un jeu d’instructions spécifiques permettant à un programme non privilégié (User Level) de déclarer et exploiter une portion de la mémoire dans un mode protégé appelé enclave, impossible à lire par tout autre processus, y compris privilégié (Mode Kernel). Typiquement, les fonction SGX sont particulièrement utiles pour travailler sur des données cryptographiques dont on veut garantir la confidentialité. On comprend ici pourquoi c’est particulièrement sensible …

Ne nous laissons pas abattre et continuons …

Lire la suite …