Samuel Thibault a écrit 190 commentaires

Avoir un matériel qui marche sans avoir à insérer un CD pour chaque matériel, ça change la vie...

En fait si, depuis que Marcus a ajouté une console, qui a un pilote VGA.

À propos de KVM: « Il n'y a pas de ralentissement des OS invités. »

C'est à modérer fortement. Certes le processeur exécute en natif la plupart du code de l'OS invité. Mais dès que l'OS veut faire des entrées/sorties, on a une trappe pour les passer à qemu, et ça c'est très très lent par rapport à une exécution native (µs vs ns...)

Qu'appelles-tu "un truc fini" ?

Il y a presque 60% des packages Debian qui compilent, Xorg et le bureau
gnome fonctionnent...

Il est intéressant de noter que ce genre de tendance dépend des pays.
IIRC En Italie, les gens ne connaissent juste pas MSN, et utilisent ICQ...
Question de premier implanté, je suppose :(

Heu, ben pour le coup... Je viens de répondre à ce sondage avec w3m,
sous Hurd... (flemme de lancer Xorg...)

Je complete encore: pouvoir fournir de l'hebergement de "machine" dont on peut choisir la quantite de RAM au Mo pres (qui a besoin de plus de 64 Mo pour se faire tourner son petit serveur web perso ?)

C'est justement en cours de développement :)

Il n'y a pas que du n'importe quoi dans ce post, donc j'y reponds :)

> Dites, Xen ne sera pas également géré au travers de kvm, (bientôt) par hasard ?

Non.

> Dites, VmWare n' utilise t il pas kvm, (maintenant) par hasard ?

Pas a ma connaissance, et ca m'etonnerait.

> Dites, kvm n' est pas basé sur le travail fait sur kqemu, par hasard ?

Non, c'est fait a cote dans qemu.

> Dites enfin, kqemu ce n' est pas l' accélérateur de Qemu ?

Si !

> vmware donnant dans l' hyperviseur,

Oui.

> xen évitant de modifier les guest.

Oui.

> Vmware poussant kvm,

Uh ?! Je ne suis pas au courant d'un truc comme ca.

> xen racheté par citrix),

Oui, mais c'est en fait un prolongement logique de la strategie XenSource (qui lui donne acces a des milliers de clients). Le projet xen.org, lui, continue comme avant.

> finalement kvm intégré upstream au noyau.

Oui.

> tout ça pour dire : MERCI Mr Fabrice BELLARD

Oui ! qemu reste un element central de la plupart des solutions opensource, grace a la plethore de peripheriques virtuels qu'il sait emuler. A quand une libqemu ?

`son inclusion fait encore l'objet de discussion - voire d'un rejet pur et simple par certaines distributions (11).'

?!?!?!

Man lire.

Ne PAS lire ce que dit is-not-good, deja, et plutot aller lire le lien chez Fedora: pour fedora 6-8, ils ne feront pas d'effort de portage, mais pour fedora 9, oui:

`Since people seeem to use Xen, we have decided not to drop it :-)

So the plan is to re-focus 100% of all Xen kernel efforts onto paravirt_ops.'

Ah OK.

En fait, Drepper avait envisagé du N:M pour la NPTL, et vu la complexité, a laissé tomber, considérant que les appels système, de nos jours, c'est peanut.

Heu, je devrais plutôt dire "même si dans LinuxThread, il y a tout un bazar de gestion qui est maintenant délégué au noyau"

> Le passage du threading M:N au 1:1 par défaut est similaire a celui qui a été fait par Linux.

Heu, je ne comprends pas. Sous Linux les deux librairies de threads couramment utilisées ont été LinuxThread et NPTL, toutes deux 1:1 (même si dans NPTL une grosse partie du boulot est déléguée au noyau)...

Mort de rire :)

Au fait, les slides du Xen Summit sont désormais disponibles sur http://www.xen.org/xensummit/xensummit_fall_2007.html

> Pense-tu qu'une des petites solutions « outsiders » comme Virtualbox, OpenVZ/Virtuozzo ou Parallels peut percer et changer la donne ?

Pour tout dire, je ne connaissais que de nom ces solutions, c'est pourquoi je n'en ai pas parlé :)

VirtualBox est intéressant parce qu'il fournit une version libre de ce que VmWare fait: de la virtualisation complète. OpenVZ/Virtuozzo est la version étendue de lguest, je pense qu'elle a toutes ses chances en solution Linuxo/Linux. Je n'ai pas encore regardé Parallels.

> Et le gros travail fait sur les containers (je crois que la virtualisation des PIDs a été intégrée dans le 2.6.24, bientôt peut-être le réseau), ça pourrai favoriser une solution plutôt qu'une autre ?

Pour moi ce n'est ni plus ni moins que l'intégration dans Linux de Vserver :)

Ça ne favorise pas pour autant dans l'absolu cette solution, ça permet juste sa mise en ½uvre effective bien plus aisée.

> Alors, à moyen terme, que va pouvoir vendre XenSource/Citrix ?

Heu, ça, le marketting, désolé, ce n'est pas de mon ressort :)

L'impression que j'ai, c'est que XenSource pourra continuer à vendre des solutions toutes prêtes à l'emploi pour les entreprises.

> Et enfin : est-ce que XenSource/Citrix a vraiment intéret à ce que le support dom0 soit bien et rapidement intégré dans le noyau vanilla (ce qui signifie faciliter la tache aux concurrents que sont RH et SuSE, mais signifie aussi ne pas prendre plus de retard par rapport aux concurrents comme kvm) ?

En tout cas c'est la volonté clairement affichée au Xen Summit: asseoir la base de Xen pour rassembler des efforts potentiels dessus. À charge à XenSource de trouver son modèle économique ensuite.

En fait, l'achat de XenSource par Citrix tombe sans doute bien: oui, l'intégration dans linux permet à la concurrence de s'installer. Mais avec le potentiel de diffusion que Citrix apporte par son achat, ce n'est pas un problème je pense.

Heu, Xen s'appuie aussi sur QEMU, avec la même souplesse des fichiers rootfs & co

On peut aussi plus simplement utiliser l'option offset de mount

> C'est faire une sorte de mini-OS ou micro-noyau. Plein de gens croit en "ces trucs". Je n'en fais pas parti.

OK :)

> M'enfin, si BSD ou autres peuvent, par exemple, accéder au driver de Linux ou Windows avec ce type de technologie, c'est un gros tant mieux, un bravo. Évidemment.

C'est bien pour ça que j'ai porté GNU Mach pour Xen ;)

> Peut-être que les solutions "alternatives" à Xen ne rattraperont jamais Xen, peut-être, etc.

Justement, pour moi ça n'a pas de sens: les autres solutions prennent d'autres chemins et c'est normal. Il y a des fonctionnalités qui font qu'on peut effectivement comparer la maturité des solutions, mais à maturité complète a priori chacune des solutions libres existantes a son intérêt propre pour un certain type d'utilisation, et il n'y a plus vraiment lieu de comparer.

En effet, j'ai l'impression que tu comprends de travers tout ce que j'essaie d'expliquer :)

> Tu crois que Red Hat doit rester à Xen car Xen (dom0) tourne sous Solaris, Windows, etc ? Ça apporte quoi aux clients de Red Hat ?

Je suis d'accord (je répète), RedHat peut très bien se contenter de KVM, je n'ai rien contre ça.

> Mais moi, utilisateur Linux et notamment de distributions communautaire, j'en ai rien à foutre que le dom0 tourne partout.

Si tu n'utilises que Linux et que tu es content du support qu'il fournit, KVM ira très bien, oui.

> Dis que Xen fait la migration de machine virtuelle, etc ce que ne fait pas KVM encore, etc. Ça ce sont de bons arguments.

Non, ce ne sont que des arguments actuels, et quand KVM sera prêt, ils tomberont.

> rester à Xen seulement car Xen (dom0) tourne sous d'autres OS est "ridicule".

Non. C'est se cantonner à Linux qui peut être ridicule. Il est notoire que certains BSD sont plus sûrs, donc avoir une solution qui permet de faire coopérer cette sûreté (en dom0) avec le support du matériel de Linux (en domD) a tout à fait du sens, et KVM, _à la base_, n'est pas prévu pour ça, tandis que Xen, oui.

Encore une fois, ceci n'a effectivement rien à voir avec RedHat, donc je suis éventuellement hors-sujet. J'essaie juste d'expliquer dans quel cadre Xen se situe.

> Sinon en suivant ta logique on pourrait aussi abandonner Linux pour Windows car Windows est dans 97 % des PC.

Dans ma logique, on pourrait utiliser Windows comme source non-sûre de drivers, i.e. on le met dans son domD et on passe par lui pour gérer le matériel sans pour autant lui faire confiance pour le reste. C'est ce genre de choses que les gens de l'embarqué sont en train de faire.

Un driver spécial dans les deux OS, oui. Dans l'hyperviseur il n'y a besoin que du moyen de communication entre les deux (qui existe déjà pour les autres types de périphériques)

> Mais pour d'autres projets, on ne porte pas. C'est toujours synchro avec la version upstream

Quels autres projets ? Le problème ici c'est qu'on touche à pas mal de composants sensibles de Linux (MM notamment).

> Xen est un solution Xeno/Xen.

Et alors ?

> Pour la partie serveur (dom0), c'est 100 % Linux ou 100 % Windows etc. Ce n'est pas 50
> % Linux, 25 % BSD et 25 % Windows.

Heu, je ne suis pas sûr de comprendre. Tu parles d'un serveur donné, confier des droits dom0 à différents OS ? C'est justement un des axes de développement actuels: avoir des doms dédiés au support du matériel (ça accroit la sécurité en plus). L'idée pourrait être par exemple d'utiliser un BSD comme dom0 pour avoir un truc bien sécurisé, et un Linux en domDriver pour le support du matériel (ou éventuellement plusieurs domD si différentes versions marchent mieux pour les différents matériels utilisés).

Ce que Drepper dit ("they want to add the drivers back into the hypervisor", "have their own mini-OS in the hypervisor"), notamment, est complètement faux. L'utilisation de qemu pour faire l'émulation du matériel est l'exemple même qui montre qu'il n'est pas question de réimplémenter quoi que ce soit.

> Et pour info, Windows ne voulait pas (et ne veut peut-être toujours pas) que Xen en mode paravirtualisation soit utilisé avec Linux (s'il fait dom0).

"il" = ?

> Les développeurs d'applis voient libvirt. Les utilisateurs voient virt-manager. Ils sont indépendants de l'OS et de la solution bas niveau de virtualisation. Tu peux dire que c'est c'est libvirt centric :-)

Oui, ça c'est très bien, moi je parle du morceau avant:

Linux ->Xen->libvirt->virt-manager
Solaris->OpenVZ->libvirt->virt-manager
Linux ->KVM->libvirt->virt-manager

mais aussi
Solaris ->Xen->libvirt->virt-manager
FreeBSD ->Xen->libvirt->virt-manager
...

KVM reste un bout de code qui n'est pas prévu pour être utilisé pour d'autres noyaux.

> OK, Drepper ne se consacre pas qu'au noyau.

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.

J'oubliais de préciser: oui, je bosse chez XenSource depuis 2 mois, donc forcément j'ai sans doute du mal à être impartial :) . J'espère au moins avoir éclairci les choses.

Pour lguest j'ai été ambigü: lguest permet de fait tourner plusieurs instances de Linux, mais ces instances doivent être de la même version de Linux configurée de la même manière (bref, le même noyau quoi). Les distributions peuvent par contre bien sûr être différentes.