vMotion SDPS madness

Nous profitons de la coincidence d’un problème rencontré récemment chez un client et d’un excellent post de Niels Hagoort, le co-auteur du célèbrissime VMware vSphere 6.5 Host Resources Deep Dive, pour vous parler d’une fonctionnalité de vMotion apparu dans ESX 5.0 : Stun During Page Send (SDPS).

vSphere 5 introduces a new enhancement that ensures vMotion will not fail due to memory copy convergence issues. As noted in the “Architecture” section, transfer of the virtual machine’s memory contents during the vMotion process involves an iterative precopy procedure. In most cases, a precopy iteration should take less time to complete than the previous iteration. However, a pathological case where the virtual machine modifies memory faster than it can be transferred—due to workload characteristics or network infrastructure limitations—results in aborting vMotion in vSphere 4.1 and prior releases, because precopy fails to make forward progress. The enhancement in vSphere 5 slows down the virtual machine during such pathological cases and ensures that the memory modification rate is slower than the precopy transfer rate, thereby preventing any possible vMotion failures.

Vous l’aurez compris, si l’ESX source n’arrive pas à “dépiler” la vram suffisamment vite lors d’un vMotion, l’execution de la VM en question est ralentie jusqu’à ce qu’une convergence soit possible, dans la limite des timeout par défaut.

Cette fonctionnalité semble parfaite pour les monster VM qu’on a du mal à évacuer lors d’un passage en maintenance mode mais elle est aussi très “problématique” lorsque l’infrastructure réseau n’est pas ou plus adaptée. D’où le très discret “network infrastructure limitations” dans le descriptif.

En l’occurence, le client en question mène une campagne de “refresh” de son parc afin de remplacer des machines ayant largement dépassé leur date de péremption technique. Mais sans faire évoluer son réseau. Il se retrouve donc avec machine de 2To de RAM sur un réseau 1GbE.

Evidement, à mesure que des VM de plus en plus grosses sont provisionnées sur ces environnements, les fenêtres de maintenance sont de plus en plus grande mais surtout des ralentissements apparaissent lors des mise en maintenance ou simplement quand DRS déplace de VM :

018-12-13T16:32:29.378Z cpu18:74031)VMotion: 4943: 7811810961774337297 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 693298, prev 461605, cur 497489, network bandwidth ~28.619 MB/s, 94% t2d)
2018-12-13T16:38:32.426Z cpu188:72874)VMotion: 4943: 7811810962073701659 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 126959, prev 18467, cur 15909, network bandwidth ~60.158 MB/s, 103% t2d)

SDPS fait son boulot et il le fait bien alors évidement pour faire passer des VM de 256Go qui bossent fort dans du 1GbE ca pique… Donc la prochaine fois qu’on vous dit que la bande passante de vmotion peut être sacrifiée, vous saurez quoi répondre.

Evidement, il y a un (mauvais) plan B :

To work around this issue, the Stun During Page Send (SDPS) feature can be disabled on a per-host basis.
[...]
Change the value of Migrate.SdpsEnabled to 0.

Nous en profitons pour souligner un autre “petit” détail du texte au sujet du Page Tracing :

During the pre-copy phase, the vCPU’s, in use by the virtual machine, are briefly stunned to install the page tracers.

ppp

Tags: , ,

#vExpert10 & #Web30

Time flies. Ce qu’il y a de génial avec cette expression anglaise américaine c’est qu’on visualise tout de suite un avion de chasse passer à mach 5 avec votre todo list. En tout cas, cela résume bien le silence d’un an entre ce post et le précédent qui avait pour vocation, lui  aussi, de célébrer l’anniversaire de ce blog. Et de 11 !

On va en profiter pour remercier VMware, Veeam et toute la communauté pour les nominations de vExpert, vExpert vSAN et Veeam Vanguard de cette année, c’est toujours un honneur. 10 étoiles ca commence à faire :)

Nous avons même eu droit à une “honorable mention” dans un des vSpeaking Podcast de VMware pour SexiGraf. La classe Cool

Et puisque c’est les 30 ans du World Wide Web ET de/du la/le Game Boy, nous nous sommes permis :

Tags:

Hypervisor.fr X

Aujourd’hui, Hypervisor.fr a 10 ans.

Je sais qu’on ne vous offre plus autant de contenu qu’avant (même si on va faire en sorte que ça change), qu’on aurait du faire évoluer la charte graphique et refresh les section ZFS, Tools, Presse, etc… (même si on va faire en sorte que ça change) mais sachez qu’on est toujours là et pour vous le prouver, on vous offre la dernière version de SexiGraf avec plein de nouvelles feature sympa et un petit teasing de notre prochain projet (toujours avec vmdude) :

Merci à ceux qui se souviennent encore de nous et qui continue à nous soutenir !

VCSA to NextCloud

Lors d’une update d’une VSCA 6.7 de lab, nous avons été amusé par l’étape de backup que VMware à ajouté au workflow d’update de la VAMI (sublime HTML5 Clarity d’ailleurs). Il faut à présent certifier que l’on a bien backupé l’appliance avant de se lancer dans une update :

la VCSA 6.7 introduit le backup automatique programmé mais toujours pas le support du SMB (raison pour laquelle nous avions boudé la feature en 6.5). En fouillant dans la doc, nous nous sommes aperçu que le protocole webdav était supporté, c’est certainement ce que VMware sous-entend par http et https bien que ce ne soit pas extrêmement clair.

En grand fan et utilisateur intensif de NextCloud que nous sommes, nous avons testé le backup en secure webdav (https) vers un nextcloud avec succès et ce très facilement (on s’attendait à des histoires d’url comme c’est souvent le cas avec le webdav) :

Reste plus qu’à tester le restore maintenant Cool

Tags: , , ,

TLBleed : Seeing double?

Les plus vieux d’entres nous se souviennent surement encore des débuts chaotiques (en environment serveur) de l’Hyper-Threading en 2002, cet artifice qui permettait de compenser les problèmes de l’architecture NetBurst d’Intel.

Compte tenu de son implementation de l’époque (très bien décrite, en Francais, par nos amis d’x86-secret), il était souvent recommandé de désactiver l’HT. Au fil des évolutions des CPU mais aussi des versions d’ESX, la situation a fini par s’inverser et le grand débat de l’HT pouvait prendre fin…

Internal testing shows that the recent generation of HT processors displays a higher performance gain from utilizing both logical processors. This means that the potential performance loss by letting some hyper-threads idle for a fairness reason becomes non trivial.

[...]

On vSphere 5.x, such a benefit is recognized and more CPU time is charged when both logical processors are busy. The implication of this newer charging model on HT is that a vCPU which is lagging behind can catch up more quickly even on a partial core, making it less necessary to use only the whole core.

…Ou pas, car comme l’a décrit x86-secret il y a 16 ans (!) :

Avec l’HT, ce sont désormais deux flux d’instructions qui arrivent à l’entrée du pipeline. A noter que seule la partie en amont du pipeline est, d’une certaine façon, “consciente” de la présence de ces deux flux provenant de deux threads différents, et le reste du traitement s’effectue comme s’il s’agissait d’un unique flux d’instruction. Ainsi, les deux threads se partagent les unités de calcul et les mémoires caches.

Et guess what, une équipe d’un centre de recherche hollandais dit avoir été capable d’exploiter cette faiblesse connue depuis de années (mais c’était avant AWS & Co) maintenant baptisée TLBleed. En pleine “crise” Spectre/Meltdown, Intel semble ne pas avoir l’intention d’adresser cette faille mais les choses pourraient bien changer au moment de la publication d’ici le mois d’Août. Et oui, AMD est potentiellement impacté aussi :)

Et surprise, l’équipe des devs du projet OpenBSD (“As of February 2018, only two remote vulnerabilities have ever been found in the default install, in a period of almost 22 years) a décidé de désactiver l’HT dans les nouvelles releases. Et c’est d’ailleurs pour ca que toute l’histoire est remonté à la surface.

On notera au passage que l’ANSSI recommandait déjà de désactiver l’HT depuis 2015 au moins, pour les mêmes raisons.

C’est donc le moment de sortir les popcorn’s. Quand on se souvient de l’affaire du salage de TPS pour des histoires de differences de latences de cache en environnement contrôlé, on se régale de la com VMware qui justifiera la désactivation d’HT dans ESX.