En fait j'ai fais un peu de virtualisation avec Xen + Libvirt puis kvm + Libvirt et dans les deux cas je n'ai jamais osé mettre en service plus de VM que je n'ai de cœur logiques dans la machine (et incluant un cœur pour le manager).

Une société que je connais fait de la virtualisation Xen avec des serveurs d'entrée de gamme (1 socket Xeon 4 cœurs 8 threads) et ils attribuent 3 VM (DomU) Windows Server par machine physique, chacun avec 2 VCPU et 1/4 de la RAM. Il reste donc 1/4 de la ram et 2 VCPU pour Xen (Dom0)

J'ai aussi loué une VM sous VMware et quand on m'a dit que j'avais 4VCPU, je pensais que ces 4 VCPU étaient dédiés.

Sur mon ESXi j'ai 2 cœurs et 7 VM actives. Mais clairement c'est ni de la prod', ni des VM qui prennent beaucoup de ressources donc ça gène pas.

Pour moi Google ce n'est pas "la vraie vie", c'est... Google

J'ai des fermes d'ESX, j'ai eu du Citrix XenServer et j'ai de l'OpenVZ qui est proche de ce que tu décris.

Et bien, en terme de souplesse d'utilisation, ESX est loin, très loin, devant. En terme de couts aussi !

Bon on s'éloigne du sujet : quelles applications va-t-on faire tourner sur nos ARMv7 ? A priori, pas quelque chose qu'on sait virtualiser facilement.

L'idée n'est pas vraiment nouvelle. Elle avait été tenté par un projet (hardware) Calxeda, pour promouvoir les proc ARM. L'intérêt principal, pour moi, c'est la conso, et la clim (donc encore la conso.)
Pour exploiter des clusters Esxi, un des problèmes, c'est la consommation électrique. Parce qu'en virtualisation, il faut laisser les processeurs au max. Par exemple, le partage des ressources sur VMware, c'est le ralentissement des cores qui sont surchargés. Et donc de toutes les VM sur le même Esxi.D'ailleurs il n'y a qu'a voir les horloges des VM, s'il n'y a pas de synchro NTP externe.

Il existe du hardware, comme les serveurs Hp Moonshot qui sont dans le même esprit.
La question, c'est effectivement les applications (au delà, de l'OS). Mais c'est déjà possible, des frontaux web, même des bases de données.
Le gros avantage, c'est justement de pouvoir allumer ou éteindre le hardware inutilsé.
 

Hum, je suis plutôt dubitatif

Au niveau souplesse, je pense vraiment qu'un container est plus simple à gérer que plein de petite machines (d'ailleurs, comme les allume-t-on ?)
Au niveau énergie, un gros CPU inutilisé consomme peu (voir les notions de fréquences variables etc), et est bien plus réactif

Parmi les différentes hypothéses avancées :
- pour la parallèlisation: l'algorithmie distribuée est compliquée et est peut fréquente, j'imagine sans soucis que les clients préfèrent une grosse machine à dix petites
- la granularité de l'offre: à mon avis, le prix d'un serveur "classique" est négligeable face aux travaux de gestions (gérer deux serveurs est plus simple que gérer 20 serveurs, et coute donc moins cher)

À mon avis, c'est plutôt :
- pour faire la une!
- pour vendre du "dédié" à des petits besoins (avec la com qui va avec: matériel dédié, garanti etc etc etc)

Sinon, en vrac: BadMax, utilise Ganeti
Vivien: tu peux tout à fait mutualiser le CPU; sur l'un de mes serveurs (16 CPU), j'ai 10VM, avec un total de 30VCPU: au niveau de l'hôte (j'utilise kvm), chaque VM n'est qu'un groupe de n processus, n étant le nombre de VCPUS alloués à la VM: c'est le scheduler qui se charge de faire le reste, en repartissant les ressources parmis ceux qui en ont besoins. Ainsi, si chaque VM demande 100% des VCPUS, ils l'auront, mais la puissance nominale de chaque VCPUS ne sera plus qu'une portion de la puissance du CPU physique.
On peut voir cela comme une limite garantie et une limite "burst" : dans mon cas, une VM qui dispose de 3 VCPUS aura une puissance maximal de 3 CPU, et une puissance garantie de (16/30) * 3 = 1.6 CPU

hum... ca revient pas au meme a la fin ?

comment ca ?

Parmi les différentes hypothéses avancées :
- pour la parallèlisation: l'algorithmie distribuée est compliquée et est peut fréquente, j'imagine sans soucis que les clients préfèrent une grosse machine à dix petites

Il y beaucoup de progrès fait dans ce domaine.
C'est certain qui si on part sur une programmation traditionnelle ca va être complexe de faire tourner ca dans ce type de machines. Dans ce cas, il vaut mieux rester sur du hardware traditionnel.

- la granularité de l'offre: à mon avis, le prix d'un serveur "classique" est négligeable face aux travaux de gestions (gérer deux serveurs est plus simple que gérer 20 serveurs, et coute donc moins cher)

Le rack entier de 228 serveurs doit être vu comme une seul machine 'a gérer' et a comparer a un serveur 'classique'.

Ce qu'on voit actuellement est issue de 2 phénomènes:

- d'un coté les progrès énormes en terme de cout, puissance et conso des CPU pour mobiles (SoC). Ce marché est d'une telle masse (plusieurs milliards d'unité par an ?) que l'idée est d'essayer d'en profiter dans le "monde des serveurs et  DC'.

- d'un autre coté, l'évolution de la programmation distribuée et des langages et outils associés. Depuis un certains temps déjà, on a n'a plus l'habituelle 'loi de Moore' ou la puissance de unité de traitement de base (cpu) doublait tout les 18 mois. On a compenser avec du parallélisme, multi core et autres techniques, ce qui permet de garder 'la loi' mais il faut adapter le code pour exploiter ce parallélisme.
A partir du moment ou on commence a maîtriser ce parallélisme on n'a plus forcement besoin de CPU puissants, gros et complexes. L'évolution va donc vers des CPU plus simples mais nombreux: c'est pile poil ce que propose le monde des SoC mobiles.

Il y une synergie forte exploitable entre ces 2 mondes. Mais il faut les 2 ensemble. Donc pas de code traditionnel sur ces machines ni l'inverse.