(Eng) My NPX / VCDX journey and my 2 cents advices

This post follow a previous one where I give a big thank to the vCommunity :


Fouad EL AKKAD, NPX-18, and VCDX-283


For Reminder What are those Certifications ?

They are the highest level on VMware and Nutanix certification program, that refer to the Architect Skills sets.


In the Nutanix Program :


In The VMware Program :



It has been a little while since I had to take the time to write this post, so I am enjoying a trip to Las Vegas. => Casablanca to get me started.

There are several sources on the net, so the idea is not to put a study guide but rather to give you a little feedback with 2 – 3 tips.


First, we have to start with the “WHY” embark yourself on such an adventure.
If it is to earn more money, I will stop you right away it is unlikely that you will go to the end especially that there is another much more effective, but if it is for a challenge and the desire to complete your skills, then I can only encourage you.


For my story, it has been 2 – 3 years (2013 – 2016) with my office colleagues Igor Zecevic (@zecevicigor), Bilel Kamoun (@BILKAM2), and Alban Lecorps (@AlbanLecorps); we were collecting VCP certifications / NPP (Professional) then VCAP (Advanced): DCA (Administration) & DCD (Design).

At that time, I was an engineer at the City Hall of Paris, mainly with my hands in the technique to manage, administer, and ensure high availability, without having a business-oriented view.

I had the chance to attend a Nutanix Bootcamp in September 2016 set up for free (1001 Thanks to Nutanix) in Nutanix’s Amsterdam offices and intimidated into a room with a VCDX-DTM to my right (VDI) Jason Yeo and my left two VCDX-DCV (Datacenter) Derek Seaman and Michael Wilmsen

In addition, for coach Bas Rayman (NPX) and Magnus Anderson (Double VCDX DCV and Cloud).

And, there I discover a new world of IT-architect, or behind every technical decision, there is the “why”.


In short, during this boot camp we went through the different silos of the architecture (Compute, Storage, Network, and BC-DR) these having to meet the requirements of Availability, Management (scalability), Performance, Recovery, and Security, and so-called AMPRS.

We had to work in a group, respond to scenarios covering each of these silos, present them and especially with the “Why” Technical and Business.


A new horizon opened up for me. In IT like other sciences, the more you learn, the more you realize that you do not know that much.

Back at the office, I jump on my friend Igor Zecevic to board it with me. I had to insist on one week and come back to the charge by presenting him with the skeleton of an Index of the future documentation (which was ultimately far from reality) to convince him.

So here, we are on the starting blocks, with a very recent project carried out together that needs to be documented.


It took us about eight months of work about 1H to 2H per day on average to arrive at the final documentation. The idea was to make a documentary based on VMware and Nutanix (Yes it works superbly together) to be able to present it to the VCDX and NPX.


VCDX: 1st in June 2017, superb experience but failed, this is simply the apprehension of the format of the exam, not enough preparation, and technical + soft skills gap to solve.


VCDX: 2nd defense nine months later on April 2018, result which also Failed. However, with the feeling of being passed not very far, the hardest was the big disappointment of failure.


NPX: 1st defense in November 2018, with the experience of my two previous VCDX failures and a good preparation BOOOM, I picked up the NPX-18.
I say it’s a good goal achieved I should move on to something else, but quickly the unfinished feeling comes back with the VCDX still in mind


VCDX: 3rd defense in June 2019 (i.e., two years after my 1st defense) with more experience in soft skills (presentation, oral, objection management) certainly with the experience of my current position as a System engineer (pre-sale) at Nutanix.

And this time Re-BOOOM it has done, I get the VCDX 283.


Here is my story in short, now my advice:


  • Do not be impressed: if I did it, others could do it. It is not just words; I went from a very technical engineer with little business knowledge to a much more complete engineer in terms of soft skills that can conduct advanced discussions with technical teams or more high level with C-Level.
  • Have good time management: especially, be regular in your work progress not to lose the thread.
  • Focus: if you are the type to quickly let go of projects you started yesterday, I am afraid this story is not for you.
  • Community: One of the most important success factors is the great community on Twitter, slack, the people there will be happy to assist you in any way possible
  • Trust on you: I remember in my documentation having made technical choices under the advice of people already VCDX, but in reality, it was not the right option and had to go back to my first choice because I knew the context and the requirements.
  • Mentor: Choose a mentor and hire him from the beginning of your documentation to avoid, a bad methodology, doing an off-topic, or writing too much technical literature that is not necessary.
  • Once the documentation is complete: the ideal thing in my opinion is not to quickly submit your document to Nutanix / VMware because once it is done, it is done.
    I would rather do some mock (defense simulation) which will allow you to readjust your document in case of error, and inconsistency.
  • ENGLISH: For non-Native speakers. Documentation and oral defense are in English, no need to be bilingual but at least be able to manage a technical conversation easily and prepare to respond quickly with pre-constructed sentences to all the questions you had during your mocks.


Small FAQ:


NPX and VCDX , what is the difference?

Very similar in the approach and content, the big difference is:

VCDX: Oral 2 modules on the VMware stack

Defense: 75-minute presentation of the architecture of your documentation

Scenario: this is a 45-minutes session of White Boarding; simulate an architectural consulting meeting with a panel of VCDX playing the role of customers


NPX: Oral 3-module one the Nutanix SDS and 2 Hypervisors

Note that the Nutanix SDS solution is multi-Hypervisor (AHV – ESXi – Hyper-V)

Defense: 125-minutes presentation of the architecture of your documentation with your use case’s hypervisor

Scenario: Just like VCDX 60-minutes simulation with Whiteboarding but under a Hypervisor that differs from the one in your documentation.

Troubleshoot: 45-minutes session where you have to solve a technical or performance problem always under a Hypervisor that differs from the one in your documentation (but the same as the module of the scenario)


  • How many pages minimum?

I would say at least 75/100 pages; for me, the difference comes from your experience. You can be super concise in your writing because you have the experience and technical background to answer any question quickly by justifying even if it is not in your document. If not, you can go further in your documentation to detail more and prepare for panel questions.


  • How long does it take for documentation?

It all depends, but allow at least six months by being regular in the work.


  • Can I have your document to see what it actually represents?

No, without even having to justify for a bunch of obvious reasons


  • Where to start?

My advice would be to prepare and pass the VMware VCAP-DCD Design certification that will allow you to acquire the basics and jargons of design discussions.

Off Course the Blueprints:

NPX : https://www.nutanix.com/go/nutanix-platform-expert-npx

VCDX-DCV : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/certification/vmw-vcdx6-dcv-blueprint.pdf


Then see the summary examples:

Derek Seaman:

NPX: https://www.derekseaman.com/2018/06/nutanix-npx-architecture-guide-how-to-part-1.html

VCDX: https://www.derekseaman.com/2014/10/sample-vcdx-dcv-architecture-outline.html

Gregg Robertson:


And an example of documentation provided by Duncan Epping:


Rene’s blog VCDX133 with a series of extremely useful articles.

VCDX : https://vcdx133.com/2015/01/27/vcdx-series/

NPX: https://vcdx133.com/2015/03/06/nutanix-platform-link-o-rama/

The same goes for Dereck Sieman blog:



 And Read everything you could find on the internet.


  • After VCDX NPX, will I get a new villa and Tesla?

Uh not really do not expect fundamental changes but it all depends on your organization, this can clearly be a lever in some cases.






Thank you for my NPX / VCDX numbers


I have been thinking about this post from the early beginnings of my NPX / VCDX journey, the whole journey took a bit more time than I had planned for but finally, it’s time.

It’s time to be thankful, recognize all the great help that I received during my journey and I know without the vCommunity it wouldn’t have been possible.

Thanks, first of all to my family for the patience and time they gave me to allow me to work on the documentation, the mocks and travel, helping me through the lows of failing and the highs of passing.

My second thanks is for Igor Zecevic @zecevicigor ‏, my partner in crime as we did a joint submission, I owe a great deal to him as he was a large part of my success.

So now here comes a super large list of people, which helped me in various ways with documentation reviews, mocks, advice, blog posts and many many other things!

I don’t want prioritize them as I believe that would be unfair, I mean people that didn’t even know who I was, were willing to give up their free time to help me in various ways and that is a huge deal!!!!!

Now as you see, a load of people were involved in my 2 year journey in getting to this NPX / VCDX and I hope I am not forgetting anyone, but my success is their success too.

Bilal Ahmed @Dark_KnightUK

ShadyElMalatawey @ShadyMalatawey

Bilel Kammoun  @BILKAM2


Magnus Anderson @magander3

Bas Raayman@BasRaayman

Abdullah @do0dzZZ

Manny Sidhu @MannySidhu2

Brett Guarino @Brett_Guarino(before being on panelist path)

Gregg Robertson @GreggRobertson5

Dominik Zorgnotti @vDominikZ(before being on panelist path)

Per Thorn @per_thorn

Jason Gierson @JasonTweet7889

Rebecca Fitzhugh @RebeccaFitzhugh 

Ramandeep Singh @rdsinghc

Sylvain Huguet @vshuguet

Alexandre Arrive @aArriveCornec

Gatien GHEZA @GatienGHEZA

Damien Raynal @DamRay

Kalen Arndt @kalenarndt

Josh Odgers @josh_odgers

Kiran Reid @Apollokre1d 

Scott Bowe @scottrbowe

Chris Porter @uprightvinyl 

Samuel Rothenbühler @bancswissunique

Nabil RIZK @nabsrizk

Kim Bottu @Kim_Bottu

Paul McSharry @pmcsharry (before being a panelist)

vincenthan @vincenthan 

Brian Suhr @bsuhr 

Sylvain Huguet @vshuguet 

Ben Mayer @benediktmayer

Paul Meehan @PaulPMeehan

Simon Long @SimonLong_ 

Eric Fourn @Efourn 

René van den Bedem @vcdx133

Mohammed Salem @vmSalem 

Mike Brown @VirtuallyMikeB

Timo Sugliani @tsugliani 

Simon Z @RockingKeats

Anton Davidovskiy @adavidovskiy



VMware : State mémoire de l’ESXi (High, Clear, Soft, Hard & Low)



Suite à notre article sur l’exploitation de TPS et pour  compléter notre Deep Dive sur la gestion mémoire de l’ESXi.

On va se tourner sur l’exploration des “states”  ESXi sous vSphere 6, car en v5 les seuils ne sont pas les mêmes




Prérequis de lecture






Lors de la montée en charge RAM d’un hôte, celui-ci peut passer par différents états. Je dis “peut” car si  l’Overcommitment  n’est pas votre truc alors l’ESXi sera toujours à l’aise dans ses chaussures.

Si vous le torturez un peu voir beaucoup, vous pourriez obtenir ces 5 états avec leurs actions (Je dis bien pourriez car pas simple à observer).



Memory state
Seuil Actions 
High 400% de minFree Casse les “Larges Pages” en dessous de ce Seuil
Clear 100% de minFree Casse les “Larges Pages” en dessous de ce Seuil et sollicite activement TPS pour Dédup mémoire
Soft 64% de minFree TPS + Balloon
Hard 32% de minFree TPS + Compress + Swap
Low 16% de  minFree Compress + Swap + Block de VM (la CATA)




Qu’est ce que le “minFree”

C’est tout simplement une valeur fixe qui est calculée sur la base de la RAM totale de votre ESXi, qui associée à des seuils permettra de définir sur qu’elle “State” l’ESXi est.



Comment elle est calculée ?

Pour les premiers 28Go RAM, une valeur fixe de 899Mo est définie. Ensuite on ajoute 1% du delta RAM entre RAM total et 28Go.

Pourquoi ces 899Mo pour les premiers 28Go. Tous simplement pour les petits ESXi, cette valeur fixe permet de se garder un seuil minimum de RAM pour faire tourner le kernel.



Exemple :

avec un ESXi de 100Go 

  1. Pour les 28Go => 899Mo
  2. RAM Delta => 100000 M0 – 28000 Mo = 72000 Mo
  3. 1 % de 72000 Mo = 720Mo
  4. minFree = 899 Mo + 720 Mo = 1619 Mo




Un exemple réél

Avec un ESXi de 400Go RAM (indiqué exactement 393.11Go)

Sous votre ESXi, taper “esxtop” puis “m”



  1. Pour les premiers 28Go (28000Mo) => 899Mo
  2. RAM Delta => 393110 Mo – 28000 Mo  = 365110 Mo
  3. 1 % de 365110 Mo ≅ 3651 Mo
  4. minFree = 899 Mo + 3651 Mo  =  4550 Mo (à quelques pouillèmes près on retrouve notre 4541 du Screeshot)





State High

Donc en reprenant notre exemple (minFree de 4541 Mo), tant que la RAM disponible est au dessus des 400% de minFree, soit 18164 Mo nous sommes dans le state High.

Nous avons 357Go de RAM disponible, bien au dessus des 400% de minFree (18Go)



L’ESXi est en mode vitesse de croisière, et n’active que le mécanisme TPS






State Clear

C’est un nouveau State qui n’existait pas sous vSphere 5, il est très similaire au “High” il se déclenche lorsque la RAM libre passe au dessous des 400% du minFree et on passe à un autre state une fois le minFree atteint.


Vu qu’on a atteint un niveau plus poussé de conso RAM l’hôte ne vas plus se baser sur le Schedule TPS, mais il va le pousser à dedup de plus en plus de RAM.

minFree à 13487 en dessous du seuil High (400%minFree = 18164)






Pour les states suivants, nous n’avons pas réussi a générer clairement et surtout de manière fixe chaque state, car les seuils étant très rapprochés les mécanismes ZIP, SWAP & Ballooning s’active très rapidement


State Soft

On ne va pas vous refaire la musique, ce state se déclenche une fois le seuil du minFree atteint et on passe à un autre state une fois 64% du minFree atteint.



On active le TPS + Ballooning




State Hard

Entre 64% minFree et 32% minFree



TPS + Compress + Swap





State Low

Entre 32% minFree et 16% minFree




Si sur de la PROD, on signe la lettre de démission et on se sauve avant que tout implose.

Compression + Swap + Block de VM (la CATA)

Block : indique que toute VM qui sollicitera de la RAM seront bloquées jusqu’au retour du State “Hard”







VMware : Mécanisme mémoire ESXi


Nous dépoussiérons un sujet largement abordé mais malheureusement manquants à notre blog mais aussi pour compléter notre Deep Dive sur la gestion RAM ESXi

On va donc essayer de vous faire un condensé d’informations sur les mécanismes d’optimisations de RAM.

Les mécanismes de récupérations de RAM s’exécutent séquentiellement, selon l’état de l’ESXi (article explicatif prochainement)

  1. TPS : Transparent Sharing
  2. Ballooning
  3. Compression
  4. Swap



Page mémoire

La mémoire vivre est divisée en une multitude de petit bloc allouable. Ainsi une VM qui exécute un processus en mémoire aura allouée une page mémoire physique de l’ESXi

Une page peut être de différentes tailles, selon l’OS et l’application sollicitant la RAM

  • Petite page : 4Kb (OS 32 bits, application non memory-vore)
  • Large pages : 2Mb (OS 64 Bit, Base de données SQL, Oracle,…)


Afficher l'image d'origine



Overcommitment :

Donner plus de mémoire virtuelle à l’ensemble des VMs que l’ESXi peut avoir en mémoire physique




Transparent Page Sharing

TPS est le mécanisme VMware qui permet de mutualiser les pages mémoires générées par les VMs sur le même ESX.

Si plusieurs OS similaires tournent sur le même Host, il est très probable que les VMs aient de nombreuses empreintes mémoires identiques. Au lieu de multiplier les pages mémoires, TPS les scans toutes les 60 secondes et il les fait pointer vers une unique sur la RAM Hardware (Dé duplication de mémoire).

Le TPS n’est actif que sur les pages mémoires standard (4KB)

Les Larges Pages (2 MB) ne peuvent utiliser cette fonctionnalité 





Le ballooning est une fonctionnalité gérée par le pilote vmmemctl, installé avec les VMware Tools.

  • Une VM a besoin d’avantage de mémoire physique
  • La VM lance un appel au Vmkernel (Noyau de l’ESXi)
  • Le VMkernel demande à toutes les VMs (équipées des Tools) d’allouer une partie de leur mémoire non consommée (mais réservée) au pilote vmmemctl
  • Le pilote verrouille la mémoire demandée, signale au VMkernel que ces emplacements sont disponibles
  • Le VMkernel redistribue la mémoire à la VM qui a besoin de mémoire
  • Le pilote vmmemctl peut réserver au maximum 65% de la mémoire allouée.

Afficher l'image d'origine


Compression :

Si le TPS & Balloning n’ont pas réussi à libérer assez de mémoire, le VMkernel se met à scanner les pages zippable. Si une page peut être compressée à plus de 50% elle sera zippée.
Ce mécanisme est mis juste avant le SWAP car il est plus rapide de zipper – dézipper une page mémoire en RAM, que de venir la récupérer sur un disque mécanique.



Swapping :

Si tous les mécanismes précédents n’ont pas permis de libérer assez de mémoire alors l’ESXi se met à swapper, c’est-à-dire à copier les pages mémoires sur disque et la c’est la CATA coté perf







Pour observer les différents états RAM :

Dans les graphes de performances sous le client vSphere :

Petite légende :

  • Shared => TPS
  • Swap Used => la métrique SWAP EXi
  • Swap IN => Quantité de mémoire sortie du Swap (De Disque vers RAM)
  • Swap OUT => Quantité de mémoire Swappé (De la RAM vers Disque)
  • Active : Mémoire réellement utilisé par le vMkernel pour faire tourner le Workload
  • Granted : somme des mémoires VMs configurées
  • Consumed : Toutes les pages mémoires touchés (Très souvent identique à Granted)





Esxtop => Touche « m »

  • PMEM : Mémoire physique
  • PSHARE : Transparent Page Sharing
  • SWAP : .SWAP => Idéalement à 0
  • ZIP : Compression idéalement à 0
  • MEMCTL : Ballooning idéalement à 0



Pour aller plus loin 










VMware : ESXi – Large Page OR NOT Large Page – Telle est la question ?


Prérequis à cette article :




TPS est arrivé aux jours, ou les VMs avaient des OS principalement 32 bits avec des pages mémoires à 4kb (Rappel : TPS ne fonctionne pas avec les larges pages supérieures à 2MB)

C’était révolutionnaire car ceci permettait d’économiser sur de la production jusqu’à 20% de RAM et pour du VDI jusqu’à 50%.

Avant d’aborder le contexte d’aujourd’hui et les OS 64 bits, il est important de définir un des mécanismes de mappage mémoire, le TLB


TLB selon Wikipedia en 1 phrase 

Le translation lookaside buffer, ou TLB, est une mémoire cache du processeur utilisée par l’unité de gestion mémoire (MMU) dans le but d’accélérer la traduction des adresses virtuelles en adresses physiques.

En gros c’est le sommaire, la table d’adressage entre la mémoire virtuelle et la mémoire physique.

C’est un cache de taille très limitée, donc avec des pages mémoires à 4MB vous comprendrez que c’est plus rapide de la traverser.
Mais avec des pages mémoires à 4KB, la table est beaucoup plus importante donc plus coûteuse en cycle CPU afin de la traverser.

Exemple : VM de 2Go RAM

  • 2048MB/4KB=512.000 => entrées pour pages à 4kb
  • 2048MB/2.048MB =1000 => entrés pour pages à 2MB
  • Ratio de 512


Avec les serveurs de plus en plus sizés en RAM, c’est naturellement que les éditeurs se redirigent vers des Larges Pages (2MB) car pour certaines instructions mémoire, c’est plus performant et aussi moins coûteux en cycle CPU dû au “sommaire” moins important.

Donc nos OS d’aujourd’hui fonctionnent majoritairement en page de 2MB mais cela n’arrange pas notre TPS et notre besoin d’Overcommit.

Vous pouvez alors complètement désactiver les Larges pages, mais cela risque de porter atteintes aux performances VM, via l’option “Mem.AllocGuestLargePage

Descriptif VMware : ICI


  • Pour désactiver les Larges Pages => 0
  • Pour activer les Larges Pages => 1





Large Page On Demand

Mais il existe une autre option qui est plus connu sous “Large Page On Demand”, qui permet d’allouer des Larges Pages exclusivement lorsque l’OS et plus précisent l’application en fera la demande.

Ainsi une bonne proportion des pages mémoires allouées seront de 4kb donc admissible au TPS.

Options : 


  • Pour désactiver les Larges Pages => 0
  • Pour activer les Larges Pages => 1








Assez d’explication passons aux Tests

Serveur :

  • Nutanix Supermicro NX-3060-G4
  • 390 Go de RAM
  • Intel Xeon E5-2660 v3 2 x 10 Coeurs à 2.6Ghz



Test 1

On va envoyer une grosse boite de VMs sur un ESXi.

Pour simuler un Workload de Production, on lance la création et démarrage de 300 VMs, merci au Nutanix Fast Clone pour cloner 300 VMs en quelques minutes (Honnêtement moins 10) :

  • 100 x Windows 2012 (OS seul)
    Pour tester sans application 
  • 100 x Windows 2012 + SQL server
    Avec une Application friand des Larges Pages
  • 100 x Debian 7 32 Bits
    Ne travaillant qu’avec des Petites Pages (4KB)


On active le LPage.LPageAlwaysTryForNPT à 0

On démarre le tout, et tout de suite ce que l’on remarque c’est le CPU qui s’emballe. En effet comme vue ensemble le CPU est très sollicité pour les SCAN des pages mémoires


Niveau mémoire, au début qu’une infime partie Shared (Page de démarrage remplit de 0) est dedupliquée, puis on observe le Sharing qui commence à prendre sa place gentillement et gagner du terrain.



On le laisse tourner pour voir enfin une récupération effective au bout de plus d’une heure de Scan et dedup RAM.




Coté CPU la tempête passée, le CPU retrouve une consommation normale.




Résultat du Test 1 :
  • Plus de 300 VMs de config différentes déployées.
  • Plus de 225Go de RAM sauvée (et ça monte, ça monte)
  • 0 SWAP, 0 compression – 0 Ballooning
  • Memory Overcommit de 0.59 et avec 150Go de RAM de dispo on aurait pu pousser bien plus loin




Test 2 

On s’est amusé à déployer 1024 VMs Debian 32Bits (fonctionnant avec des pages de 4kb) de config 1vCPU et 2Go RAM


Résultat Test 2 :
  • 157Go RAM sauvegardé via TPS
  • 0 SWAP – 0 Compression – 0 Ballooning
  • Overcommitment de malade à un ration de plus de 4 et avec encore un boulevard devant nous car 260Go de RAM sont disponible





Test 3 

On a voulu taper dans de la plus grosse VM, donc à cloné 201 vRA 7 appliance 64bits (VMware vRealize Automation). Et la on a le TPS qui monte qui monte.

VM : 1vCPU & 18Go RAM
Notre but était de saturer l’ESXi mais TPS fait trop bien son JOB.

Résultat Test 3 :
  • 322Go RAM sauvegardé via TPS
  • 0 SWAP – 0 Compression – 0 Ballooning 
  • Overcommitment de malade à un ration de plus de 8, mais la sur allocation ne veut rien dire car ce sont des VM de 18Go de RAM configurées et elle ne consomme que 1.5Go)







On reprend l’expression de nos Sensei qui nous on inspiré à faire ces tests Hypervisor.fr

Moralité, TPS c’est bon, mangez-en !





Pour aller plus loin :