Pour notre part on est sous OpenStack donc KVM. J'ai pratiqué Xen y a 10 ans je valide que Xen n'avait pas la main sur la gestion avancée de la mémoire dans les guests malgré l'agent, je n'ai pas regardé depuis longtemps Xen s'ils ont évolués sur ce point.

VMWare fait aussi cela, on peut dire dans vsphere à ce que les swap des vms soient sur les disques locaux alors que la vm a un seul disque avec le swap dans une partition, je suppose que c'est l'agent vmware qui fait le lien avec l'hyperviseur pour lui dire attention ces écritures sont du swap pour éviter de les mettre sur les datastores.

Dans nos cas d'utilisation, la virtualisation répond aux besoins aussi bien de vms classiques (web, applis métiers, db) qu'aux besoins de calculs en masse où les vms vont connaître une vie assez courte de quelques heures à semaines et seront à 100% cpu tout le long. C'est du bigdata et de l'IA sans besoin de grande vitesse qui tourne dessus. On va déployer des instances gpu pour l'IA plus rapide.

Pour revenir au swap je ne sais pas comment KVM gère cela j'ai pas regardé les sources mais quand tu n'a pas de swap ça marche et ça peut être puissant sur le compute tant qu'on sature pas trop l'IO wait et quand on ajoute les disques swap on a un step de plus avant d'arriver à un décollage de l'iowait et une utilisation du swap qui est assez conséquente.

On a la main système sur 99% des vms de nos clusters, c'est que du Debian avec swapiness entre 1 et 5 en fonction des applications qui tournent, des pressions un peu élevées donc les vms ne swappent que très peu, on garde du swap avec un max à 1/3 de la ram et max 8Go principalement pour éviter l'OOM killer ou lorsque les clients tardent à donner l'accord pour augmenter les ressources.

Et malgré tout cela le swap des hyperviseurs travaillent énormément. Ca se voit beaucoup sur les métrics des IO wait cpu et le temps cpu system qui est très bas.

Ben oui la ram en 2020 c'est encore utilisé, pas pour le dépassement de

.../...> hyperviseurs diskless c'est finit depuis 10 ans quand on veut
de la perf.

Manifestement on n'utilise pas la même techno et on n'a pas le même
use-case.

Sur un hyperviseur Xen, la mémoire est utilisée pour l'hyperviseur, pas
pour les VM. Le seul endroit où la swap est accessible est
l'hyperviseur. Les VM n'ont pas, par définition de swap.

La swap est un arrangement qui fut utile et qui est désormais obsolète,
tout du moins dans mon use-case. Je dimensionne mes VM en fonction de ce
que je fais dessus, additionne la ram et obtient la capa souhaitée du
serveur.

Dans ton use-case, il est probable que ta techno permette aux VM de
/mutualiser/ de la mémoire surnuméraire de l'hyperviseur (et donc
mobiliser la swap), ce que Xen permet mais qui n'est absolument pas
(pour Xen tout du moins) une pratique efficiente.

Devoir swapper sur 128 Gb en flash et en raid 0 me semble démontrer que
nos use-case sont trop divergents.

Si c'est pas confidentiel, un exemple de use-case et nommer ton
hyperviseur me permettrait de comprendre, et donc d'apprendre encore des
choses.

De notre coté, nos bécanes roxent et sont stables. On a passé du temps à
tout optimiser et valider. Je suis un dinosaure et compte les GB, Mbps,
ns et Iops :) Mais ma solution est celle de mon use-case. Elle ne
prétend pas à être universelle.