Les tests ont été fait sur un serveur lame IBM LS42 (Opteron 8376 HE / 32Go), nous y avons démarré 30 VM identiques (W2K3EE) à 10sec d’intervalle, avec le paramètre de vMMU forcé. On voit clairement sur le graphique que le TPS “récupère” beaucoup plus de mémoire en swMMU qu’en hwMMU.

Halesh (VMware R&D) nous a confirmé que dans cette situation, le TPS n’agissait que sur les pages “zeroed” au boot de la VM. Seongbeom Kim (VMware) nous en dis plus par mail :

On EPT/RVI platform, large pages are used to back guest memory request for better performance. This delays page sharing until the host goes into memory overcommitted situation.
In more recent updates to ESX4.0 (including build 219382), zero pages are shared in 4K granularity while guestOS boot-process zeros all guest memory.
This approach provides early sharing and can be beneficial for guests that do not access all the configured memory.
Whenever the shared page is broken, we try to back it with large page to achieve better performance.

Mais le plus fort c’est que le vMMU peut être changé à chaud grâce à VMotion (en changeant le paramètre avant le VMotion bien-sur) ! Pour illustrer cette prouesse purement futile, nous avons superposé les 2 graphiques mémoire des 2 hosts :

Nous attendons d’en savoir plus sur la “légitimité” de cette “feature”…

Selon Halesh, le fonctionnement de VMotion explique cet effet :

For VMotion we need common CPUs across source & destination. But as you said during vmotion, vMMU worlds are restarted/newly created on destination this might be supporting.