Heu ben oui il est surtout censé s'occuper de la glibc :)
Le problème, c'est qu'il a des avis très tranchés sur les questions de glibc, et il se moque éperduement que la glibc puisse être utilisé avec d'autres noyaux que Linux par exemple, ou qu'on s'amuse à remplacer la libpthread par une libpthread de son cru. De même pour la virtualisation, c'est tout...
> Le niveau de performance devient alors très important. Si t'as une solutions générique mais qui tourne 20 % plus lentement, ça veut dire qu'un serveur ne peut avoir que 40 guests.
Heu, le lien que tu donnes indique plutôt 9% de ralentissement en mode paravirtualisé, mais bref, dans le cas d'une solution Linuxo/Linux, KVM est tout à fait adapté en effet.
> Donc une solutions qui est "lourdingue" n'est généralement pas appréciée.
Lourdingue en maintenance tu veux dire ? Oui, bien sûr, porter le patch Xen c'est lourdingue.
> Bref, no futur pour XenSource dans le marché Linux.
Dans le marché Linux/Linux, oui, et c'est normal: comme je l'ai dit, à chaque situation ses solutions. C'est justement un défaut commun que de vouloir que "sa" solution fasse tout y compris le café. Il vaut mieux se concentrer sur ce pour quoi on est bon.
Par contre, dans le contexte de l'embarqué Linux par exemple, Xen a tout à fait sa place, on a eu un exposé sur ARM au Summit.
> > Maintenant, acheter Xen permet de faire tourner ces windows (ou tout autre OS) sur du matos géré par Linux, ce n'est pas rien.
> Pareil pour KVM/qemu depuis au moins 6 mois (si t'as du hardware assez récent et très commun aujourd'hui).
Sauf que Citrix ne peut pas "acheter" les compétences KVM/qemu (Je disais bien "acheter Xen" pour Citrix). En ce moment, on est en train d'intégrer Xen aux solutions Citrix, ç'aurait été bien plus dur avec des solutions KVM/qemu. La différence avec Xen, c'est qu'on peut faire la même chose avec Solaris, NetBSD, ...
> Mais juste une petit exemple, il me semble que le patch Xen s'applique à Linux 2.6.16 seulement !
Faux, 2.6.18.8 ! ;)
Maintenant, troll à part, c'est un problème, oui, et ça justement a été évoqué au Xen Summit: plutôt que faire des efforts pour porter Xen sur les versions ultérieures (ce qu'a fait RedHat), il vaut mieux faire intégrer ça upstream, ce qui a été réalisé pour domU déjà, et est en cours pour dom0 (Non, XenSource ne refuse pas de se synchroniser avec upstream, c'est juste que la branche principale préfère rester avec un noyau connu pour être stable).
> > À noter, je ne me souviens pas avoir rencontré de gens de Microsoft au Xen Summit...
>
> Je n'ai pas voulu sous-entendre que Citrix était à la botte de MS.
Ce n'était pas ce que je voulais dire.
Je voulais dire que si XenSource/Citrix était vraiment focalisé sur Windows, il aurait été "normal" de voir pas mal apparaître Microsoft au Xen Summit. Cela n'a absolument pas été le cas.
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . En réponse au journal Fedora abandonne Xen. Évalué à 3.
Heu ben oui il est surtout censé s'occuper de la glibc :)
Le problème, c'est qu'il a des avis très tranchés sur les questions de glibc, et il se moque éperduement que la glibc puisse être utilisé avec d'autres noyaux que Linux par exemple, ou qu'on s'amuse à remplacer la libpthread par une libpthread de son cru. De même pour la virtualisation, c'est tout...
> Le niveau de performance devient alors très important. Si t'as une solutions générique mais qui tourne 20 % plus lentement, ça veut dire qu'un serveur ne peut avoir que 40 guests.
Heu, le lien que tu donnes indique plutôt 9% de ralentissement en mode paravirtualisé, mais bref, dans le cas d'une solution Linuxo/Linux, KVM est tout à fait adapté en effet.
> Donc une solutions qui est "lourdingue" n'est généralement pas appréciée.
Lourdingue en maintenance tu veux dire ? Oui, bien sûr, porter le patch Xen c'est lourdingue.
> Bref, no futur pour XenSource dans le marché Linux.
Dans le marché Linux/Linux, oui, et c'est normal: comme je l'ai dit, à chaque situation ses solutions. C'est justement un défaut commun que de vouloir que "sa" solution fasse tout y compris le café. Il vaut mieux se concentrer sur ce pour quoi on est bon.
Par contre, dans le contexte de l'embarqué Linux par exemple, Xen a tout à fait sa place, on a eu un exposé sur ARM au Summit.
> > Maintenant, acheter Xen permet de faire tourner ces windows (ou tout autre OS) sur du matos géré par Linux, ce n'est pas rien.
> Pareil pour KVM/qemu depuis au moins 6 mois (si t'as du hardware assez récent et très commun aujourd'hui).
Sauf que Citrix ne peut pas "acheter" les compétences KVM/qemu (Je disais bien "acheter Xen" pour Citrix). En ce moment, on est en train d'intégrer Xen aux solutions Citrix, ç'aurait été bien plus dur avec des solutions KVM/qemu. La différence avec Xen, c'est qu'on peut faire la même chose avec Solaris, NetBSD, ...
> Mais juste une petit exemple, il me semble que le patch Xen s'applique à Linux 2.6.16 seulement !
Faux, 2.6.18.8 ! ;)
Maintenant, troll à part, c'est un problème, oui, et ça justement a été évoqué au Xen Summit: plutôt que faire des efforts pour porter Xen sur les versions ultérieures (ce qu'a fait RedHat), il vaut mieux faire intégrer ça upstream, ce qui a été réalisé pour domU déjà, et est en cours pour dom0 (Non, XenSource ne refuse pas de se synchroniser avec upstream, c'est juste que la branche principale préfère rester avec un noyau connu pour être stable).
> > À noter, je ne me souviens pas avoir rencontré de gens de Microsoft au Xen Summit...
>
> Je n'ai pas voulu sous-entendre que Citrix était à la botte de MS.
Ce n'était pas ce que je voulais dire.
Je voulais dire que si XenSource/Citrix était vraiment focalisé sur Windows, il aurait été "normal" de voir pas mal apparaître Microsoft au Xen Summit. Cela n'a absolument pas été le cas.