>> Nous avons renoncé à utiliser libvirt qui pose de nombreux problèmes dans un
>> environnement de production. De plus, libvirt supporte principalement Xen,
>> que nous avons écarté aussi, trouvant KVM plus prometteur.
>
>Ca c'est balot, parce qu'en ce moment, tout converge vers libvirt. RH emploi du beau
>linge pour travailler dessus, mais c'est aussi le seul gestionnaire de vm descent des
>dernières Debian, ... bref ce n'est plus l'affaire de quelques mois avant que libvirt
>soit l'outil de base/quasi standard pour les sysadmins. Autant dire que les autres
>solutions resteront... très confidentielles.
Le fait que cela soit repandu ou standard ne prejuge en rien de sa qualite.
Je suis rassure que les gens de Ielo aient ecarte libvirt, ca montre qu'ils savent voir au dela du hype.
La grande force de libvirt est effectivement d'etre capable de s'interfacer avec plusieurs plateformes de virtualisation. C'etait une piece importante de la strategie de RH et lui a permis de changer de solution de virtualisation sous-jacente (de xen a kvm).
Mais cela reste amha une usine a gaz fragile qui n'exploite que le plus petit commun denominateur. Un design clean a partir de zero pour un produit qui ne tente pas d'utiliser plusieurs hyperviseurs ne me parait pas idiot. A remarquer qu'il y a des outils simples fait par des admins pour des admins qui marchent bien (genre kvmctl de finntux).
>D'autre part les devs de libvirt contribuent fortement à Qemu/KVM (et un peu à Xen)
> : ce sont donc eux qui infléchirons la direction qui leur convient en ce qui concerne
>la gestion ; ils ont déjà implémenté le support d'auth par certificat X.509 sur le VNC
>de Qemu, ainsi que le support des multiples sorties graphiques simultanées, de
>l'auth SASL, ils travaillent sur le design de l'interface stdio de Qemu, l'intégration
>avec func (un projet RH aussi), FreeIPA, Cobbler, Puppet, ...
C'est vrai que le groupe Emerging Technologies de RH contribue pas mal a Qemu.
Cela dit, comme le nom de leur groupe l'indique, ce sont surtout des gens qui font des prototypes qui passent ensuite souvent en prod tels quels (voir les ProtoTry de http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns ). Ce faisant, ils ont tendance a privilegier le quick and dirty et non un design propre/sain.
Un exemple est le fait qu'ils aient choisis de lancer tout en root, ou encore de se mapper sur la console qemu plutot que de pousser dans qemu une lib qui aurait permis de s'interfacer de facon propre et robuste (avec bindings dans plusieurs langages).
Il est dommage egalement qu'ils n'aient pas commence par rajouter l'auth sasl/pam avant de mettre en place l'usine a gaz pour les certificats et les changements de mots de passe.
Cela dit, il aurait ete plus fute de coder un broker de connections vnc qui effectue le controle/l'authentification en amont de qemu, sur la base de "user/group policies", via sasl/pam. Cela aurait permis d'avoir un acces sur un port unique pour toutes les vms situees sur une machine, et de permettre l'authentification dynamique contre toutes sortes de backends.
Alors, oui, ils contribuent, mais leurs choix ne sont pas forcement les meilleurs.
D'autre part, ils n'ont pas la main-mise sur qemu (ils n'ont meme pas d'acces en ecriture au repo pour l'instant) donc rien n'empeche les gens de Ielo/LO ou des contributeurs externes de rajouter des fonctionnalites.
>Un peu de concurrence et d'émulation ne feront pas de mal, mais j'ai l'impression
>que c'est une cause perdue d'avance :(
Non pas forcement. Ce qui compte, c'est comme tu l'as implicitement fait remarquer, c'est le code commite.
Mais oui bien sûr, après tout qu'importe que leurs définitions et l'approche pseudo-historique choisie nous fasse passer des vessies pour des lanternes ou nous classe les baleines dans la famille des poissons! Qu'importe si des oublis de solutions techniques montrent qu'ils n'ont finalement pas fait beaucoup de recherches. Demain, moi aussi je me bombarde expert d'un sujet et je ponds une news, puisque c'est ce qui est le plus important, n'est-ce-pas?
Désolé, moi je n'adhère pas.
Si l'article est de tellement mauvaise qualité qu'il faut lire la totalité des commentaires, puis les vérifier pour arriver à se faire une idée de l'état de l'art, alors il aurait mieux fallu qu'il ne soit pas publié. Sur des sujets aussi "hype" que la virtualisation, le marketing fait déjà des ravages et il est bien difficile de se faire une idée des réalites _techniques_, voire, sous les descriptions de haut-niveau, de comprendre comment ça marche, tout simplement.
PS: lezard breton as surement envie de regarder à nouveau les différentes définitions de clientélisme.
Désolé Samuel, mais le seul mot qui me vient à l'esprit c'est "bullshit".
C'est surtout pour ca que RH a lancé le projet Xenner [1]qui permet de faire tourner des kernels "xen-isés" sur du kvm, pour pouvoir se débarrasser de Xen tout en continuant a supporter la base installée.
Et puis ca serait sympa de préciser que tu bosses pour Citrix/XenSource!
(Ne le prends pas mal, j'apprécie énormément le boulot que tu fais, notamment sur qemu).
>> des clusters HPC existants tournent sur du linux
>Le HPC est tres loin de se limiter aux clusters Linux. Par exemple environ la moitie des 10 machines le plus puissantes du top500 n'executent pas Linux sur les noeuds de calcul (BlueGene -> CNK, Cray -> Catamount). C'est a mon avis une erreur de limiter le HPC aux clusters Linux, pour cela que ldans mes posts precedents j'ai pris la peine de citer ces plate-formes. Je pense d'ailleur que c'est _le_ point qui fait que l'on se soit pas totalement d'accord car ton analyse est tres pertinente et en dehors de ce point, je suis globalement d'accord avec toi.
OK, disons que mon approche se voulait pragmatique et que je me cantonnais à des clusters Linux sur x86. Pourquoi? Parce que même s'il est vrai que sur le papier il existe des solutions bien plus performantes, la réalité est que d'un point de vue pragmatique, elles ne sont que peu viables (je pourrais revenir là dessus si ça t'intéresse mais ça risque d'être long :)).
(et oui, je met de côté MS WCCS)
>> des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
>Quand tu n'as pas de Linux, ca ne marche plus. Et il est clair que ces cas la m'interessent. Et meme si les BlueGene et les Cray vont bientot offrir du Linux sur les noeuds de calcul, vu que c'est une version de Linux "epuree", toutes ces solutions ne fonctionneront clairement pas.
Perso je préfère les "sweet spots" :)
>> Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware
>Heu la non, pas tout a fait. Personnellement je ne peux pas justifier n'importe quoi sans prouver que la degradation en terme de perf n'est pas trop importante. Et dans ce contexte, clairement la nature de l'hyperviseur est important. Avec un type-I, on peut faire un domaine hote petit (dans les solutions actuelles ce n'est pas le cas par defaut) et un hyperviseur avec un comportement predictible (pas le cas de Xen dans certains cas) pour l'execution d'applications paralleles. Je ne pense vraiment pas que tu puisse faire la meme chose avec une solution de type-II (et en fait pas non plus avec les solutions de type-II actuellement dispo!).
Je suppose que tu voulais dire "les solutions de type-I actuellement dispo". Si c'est le cas, c'est bien mon avis également.
> Dans mon cas, je ne peux justifier qu'au maximum 10% de penalite avec un vrai apport en terme de fonctionnalites. Si tu passes d'un micro-noyau a Linux + virtualisation, c'est quasiment impossible (deja le passage a Linux meme apres optimisation donne une penalite d'environ 25% dans les all-to-all avec des applications MPI lorsque l'on compare a un micro-noyau).
Mmmh je reste très circonspect sur le calcul des % de pénalité, etc... Les benchmarks c'est un domaine TRES difficile. que ce soit en micro analyse ou macro analyse.
(je ne resiste pas à l'envie de dire à ce sujet que les "near natives performances" de Xen étaient vraies pour Xen 2 avec du paravirtualisé et que sur du Xen 3 avec HVM je pense qu'il y aura des décus)
>> Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0.
>Pour le HPC sur une machine type Cray, non, impossible actuellement. Sur un cluster deja Linux je suis d'accord avec toi. Mais a nouveau ca sort du HPC strict, ca devient "HPC avec cluster Linux", ce qui je te l'accorde concerne beaucoup de gens, mais pas tout le monde. :-)
Oui, de la même façon que tout le monde ne conduit pas de Formule 1 pour aller au travail
> Et puis meme avec Linux je demande a voir. Mes premiers tests avec KVM n'ont pas montres d'interets reels.
On en reparle dans 1 an? ;)
>> Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
> Egalement d'accord a 200% avec toi (ce que meme des gens faisant de l'OS oublient parfoit) mais je pousse l'analyse un poil plus loin : Linux est bien trop complexe (desole mais l'architecture de systeme de fichier, je la trouve vraiment trop complexe :-). Pour cela que je prefere "naturellement" les solutions de type-I : ca t'ouvre les portes pour mettre ce que tu veux dans les VMs mais aussi dans le domaine hote; les differents "composants" de la solution de virtualisation sont bien separes; avec une solution de type-II c'est bien plus complexe (imbrications et dependences).
Je pense que sur le papier tu as raison, dans la "vraie vie" la tendance risque de s'inverser :o)
>> La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
>Dans l'absolu je suis bien d'accord. As-tu jeter un coup d'oeil aux projets finances par la NSF autour de la virtualisation? Il y a des idees interessantes (meme si a mon avis il manque des choses parfois). L'un des projets est le suivant, impossible de remettre le main sur le deuxieme (qui est pourtant plus interessant a mon sens car fonde sur l'idee d'un framework pour le developpement de nouvelles solutions de virtualisation) : http://www.nsf.gov/news/news_summ.jsp?cntn_id=110606&org(...)
Chouette de la lecture! Non je ne connaissais pas, j'y jetterais un oeil demain.
>> La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux
>Justement, pourquoi ne pas reprendre des microkernels existant pour mettre en oeuvre une nouvelle solution (un peu l'idee de L4) ? Bien sur ca sera tres specialise pour une plate-forme donnee (toujours le probleme des drivers) mais je pense que cette approche serait bien plus interessante.
Parce qu'on va tomber dans un débat micro- vs. macro- ?
> Je recupere des resultats de profiling tous les jours en ce moment en utilisant Xen et oprofile, ca marche plutot bien. Par contre, c'est sur que si tu veux debugger ta VM seule, une solution de type-II est bien meilleure (ce que j'ai deja dis auparavant).
Intéressant, cela a donc notablement avancé depuis que j'ai arretté de lire les MLs de xen et de lire les papiers!
> A noter que la simplicite dont tu parles est perdue des que tu veux faire ca au sein d'un cluster de taille assez importante (d'un autre cote, une solution open-source qui apporte un bout de solution pour ca devrait bientot etre mise a disposition, permettant aux utilisateurs de passer tres simplement de VMs sur un cluster a un cluster "normal").
Un truc sur lequel tu bosses?
> Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
> Non je ne suis pas tout a fait d'accord, il est possible d'avoir un hyperviseur petit et modulaire (donc pas Xen), un hostOS petit (donc pas Linux avec les configurations associees aux solutions de virtualisation actuelles), et des VMs avec ce que l'on veut dedans. Avec Linux+KVM, tu t'eloignes tout de suite de ca (overhead de Linux par rapport a des micro-noyaus specialises).
C'est vrai, mais tu y gagnes sur le fait que ça existe déjà et c'est déjà bien répandu et donc qu'il est plus facile d'obtenir du support.
> Mais bon, je pense aussi que de toute facon, avec les solutions actuelles, des que tu passes a une plate-forme distribuee (e.g., cluster), tu te prends la tete et pas qu'un peu.
Ca va tout à fait dans le sens de ce que je disais dans mon autre réponse (dur de suivre vu que nos réponses se croisent :))
> Pour conclure ton analyse est vraiment pertinente, merci pour ca (ca faisait longtemps que je n'avais pas eu une discussion interessante sur LinuxFr!). Le seul bemol que je me permets est que dans mon cas je ne me limite pas a du tout Linux. :-) Ce qui bien sur n'interessera que peu de personnes ici.
Je ne me limite pas qu'à Linux pour ce qui est de comprendre/suivre les tendances, mais par contre j'ai une approche plus pragmatique/orientée production que toi, ce qui est bien normal étant donné nos métiers différents!
> L'article de Anthoney Liguori touche un point interessant : "The most common definition of "type-1" and "type-2" seem to be that "type-1" hypervisors do not require a host Operating System", ce qui est totalement faux bien sur. Quand je parle de type-I vs. type-II et comme je le dis auparavant, je parle de la definition donnee par Goldberg avec le modele qui y est associe. Cette definition est tres claire, ne colle pas avec ce qui se dit un peu partout mais comme souvent les gens deforment une definition claire pour ensuite dire qu'elle n'a pas de sens.
"les gens" ici égale mon "marketing" :) Il n'était pas évident dans ta contribution que tu te référais bien au sens original, même si bien sûr j'aurais du m'en douter venant de toi. Cela dit, le fait que toi tu utilises ces termes correctement n'enlève rien à ma remarque, qui ne t'était pas forcément adressée.
> A noter aussi qu'il met Xen dans les micro-kernel, ce qui est faux! Ca n'est pas parce que Xen est petit (quoique sur ca aussi il y a discuter), qu'il est un micro-kernel. Un micro-kernel, c'est par exemple L4 et Xen est tres loin d'une architecture de micro-kernel (Xen a un design tres monolithique).
Donc au final, je ne suis pas d'accord avec l'analyse de Anthony Liguori qui a mon avis melange beaucoup de chose dans cet article et oublie les definitions exactes et initiales.
> Ensuite et pour finir, je ne veux pas prouver que ce qui a ete dit est faux, je souhaite juste souligner que la question de la virtualisation n'est pas simple et que les conclusions demandent totalement du contexte.
Je suis parfaitement d'accord avec toi! Je tentais de souligner cette difficulté, qui commence par une utilisation incorrecte de notion précises.
C'est aussi pour cela que l'article d'Anthony est intéressant car oui, il contient des erreurs et approximations, et pourtant il est écrit par quelqu'un qui travaille pour IBM et contribue de près à 3-4 solutions de virtualisations open source.
Que dire de quelqu'un qui n'en a qu'une vue de loin, surtout quand le hype (ou des contraintes mercantiles) s'en mèle?
> Je tente juste d'expliquer mon point du vue dans le contexte qui m'interesse (recherche en OS pour resumer).
Pour ma part, même si l'aspect conceptuel m'intéresse (obviously), j'ai un lourd passif de sysadmin, donc l'aspect production/pragmatisme m'interpelle également!
> D'ailleur il le dit bien : "Many people think the terms "type-1" and "type-2" originated from this paper but that is simply not the case. The paper does mention the concept of recursive virtualization and briefly discusses the requirements to allow one virtual machine to run within another virtual machine." Forcement c'est dans l'autre papier! Il cite le papier de Popek et Goldberg, pas celui de Goldberg seul (celui de sa these). C'est le papier de Goldberg qui presente la classification de maniere precise. Mais c'est une erreur commune que l'on retrouve meme dans les publications scientifiques sur le sujet.
Intéressant, je n'avais pour ma part jamais vu la référence à sa thèse. Il faut dire que je n'avais que survolé les références du papier écrit avec Popek à l'époque où j'avais la possibilité d'accéder aux documents de l'ACM.
Je pense que malheureusement le fait qu'un grand nombre de papiers de références en informatique ne sont disponibles que via des subscriptions est une des raisons pour lesquelles la roue est sans cesse réinventée et les termes galvaudés.
> Il dit ensuite " like VMware Workstation, Parallels, VirtualPC, and KVM all rely on kernel modules which means they do have direct access to hardware" et c'est bien ce qui est important : le module _doit_ avoir un systeme hote pour fonctionner, initialiser la memoire et compagnie. Pour une solution de type-I, le VMM boot en premier. Du coup, si tu n'as pas besoin de drivers particulier, tu n'as pas besoin du systeme hote. C'est pourquoi lorsque tu regardes le cycle de vie d'une VM, il n'y a absolument pas besoin d'acceder au domaine hote au moins dans les premiers instants de vie de la VM. Quel interet si on ne peut utiliser de drivers? et bien tu es libre d'utiliser ce que tu veux comme domaine hote plus tard, et non pas seulement Linux (pourquoi pas un OS specialise parfaitement adapte a ta plate-forme, e.g., CNK des BlueGene). C'est completement impossible avec une solution de type-II. Bon d'accord on parle ici de recherche mais comme je l'ai dis des le debut, c'est le contexte qui m'interesse.
Hum là je dois avouer que tu m'as perdu entre les considérations liées au démarrage du VMM et celles liées au démarrage de la VM. Je serais interessé par un complément d'information/de la clarification!
> Pour ce qui est de savoir qui est le plus performant, a mon avis la question a peu de sens, il faut preciser avec quelle application et surtout quelle plateforme materielle.
Tout à fait d'accord, je mettais d'ailleurs l'accent sur l'importance de cet aspect même en ne considérant uniquement que le monde du HPC, dans lequel il y a déjà une énorme variabilité dans la nature des applications/workload : CPU bound/memory bound/IO bound, sensible à la latence, embarrasingly parallel, massively parallel, etc ...
Personellement, après avoir passé 1 an en temps que sysadmin dans une équipe gérant un cluster de 1500 coeurs faisant tourner des applications "embarrassingly parrallel", je ne suis pas convaincu de l'utilité de la virtualisation sur de telles échelles, à part lorsque la plateforme est partagée (genre planetlab). Et le problèmatiques qui se posent pour des architectures basées sur des images (façon cloud) sont celles du déploiement des images, du stateless etc... Pas si simple!
> A noter egalement que le HVM a priori n'ameliore pas les performances (surtout dans le cas d'une solution de Type-I initialement implementee par de la para-virtualisation). Ca simplifie les choses et ouvre des portes, c'est tout.
Il me semble que le HVM s'améliore de génération en génération (arrivée du NPT par exemple pour les derniers CPU) et il est probable que cela changera la donne. Une fois encore, on en arrive à une situation de type balance entre logique cablée/software.
> PS : ce fut en tout cas une discussion agreable qui m'a permi de lire des articles/blogs que je n'avais pas lu. Toujours interessant de voir des avis differents lorsque c'est argumente, ce qui devient un peu trop rare a mon gout sur ce site. :-)
Merci du compliment :) Je pense que l'essentiel de nos différences viennent du bout de la lorgnette par lequel nous regardons les choses, recherche pour toi, production info pour moi. Effectivement, ça n'enlève rien à la qualité de tes arguments.
Je me rends compte que dans ma prose pourtant prolixte, j'ai oublié de répondre à ta question sur le type I vs. type II.
En fait, le gros problème à ce niveau est la définition de ce que l'on entends par type I et type II. C'est pour cela que je parlais de la version marketing, parce que pour moi les différences pourtant claires à la lecture des quelques articles fondateurs sur la virtualisations sont devenues très floues au fur et à mesure que j'en apprenais plus sur les solutions existantes.
Voilà, le point important pour moi a ce sujet c'est que finalement, bien malin est celui qui peut dire lequel est le plus performant entre I et II, surtout maintenant que les CPU "grand public" ont des instructions HVM. C'est ce que je résume (peut être maladroitement) en appelant ça un argument marketing.
Pardon, j'avais débordé largement du cadre du HPC pour parler de la virtualisation d'une manière générale.
Si tu te cantonnes au HPC, déjà, clairement la solution dépendra du type de contentions créées par le workload (c'est d'ailleurs une des raisons pour laquelle je doute de l'intérêt d'une solution de type SSI, mais tu le dis toi-même en réponse à un autre post, son marché de niche ce sont des applis non optimisées HPC sur des tout petits clusters).
Sur un cluster HPC dont le workload est tel que les contentions se font sur le CPU ou la mémoire, je ne suis pas forcément certain de l'intérêt de la virtualisation, et comme la majeure partie des clusters HPC existants tournent sur du linux, des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
> avec une solution de virtualisation, type KVM, le domaine hote doit absoluement etre un Linux. Or si tu prends les plate-forme HPC actuelles type BlueGene ou Cray, c'est rarement le cas. Tu vas me dire que dans ce cas, la solution de type-I ne fonctionne pas plus car le domaine hote doit etre un Linux. C'est vrai mais cela devrait changer dans un avenir proche si tout va bien
Je ne vois pas en quoi la nature de l'hyperviseur intervient. Les points pertinents à mon avis sont:
- est-ce qu'il est opensource (dans le cas où c'est un prérequis, il y a plein de gens qui s'en foutent, que ce soit heureux ou malheureux)
- est-ce qu'il fait bien son boulot et notamment est-ce qu'il utilise une quantité de ressources négligeable (overhead mais aussi taille occupée etc)
- est-ce qu'il est facile à débugger/faire évoluer/manager
Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware (et là, malheureusement, j'ai tous les jours la preuve que le déploiement de VMs ne se fait pas toujours pour des raisons pragmatiques).
La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux (cf. ma remarque sur ESX dans mon précédent post). Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0. Les seuls vrais concurrents que je verrais seraient les projets a base de L4 réutilisant les drivers linux en les isolant. Mais Linux+KVM a AMHA une longueur d'avance sur eux, sans compter une base de développeurs et d'utilisateurs bien supérieure.
Si on sort du domaine du HPC et qu'on s'intéresse à des clusters composés de noeuds faisant tourner des VMs de type appliances applicatives, alors ESX est la seule solution vraiment de niveau production à l'heure actuelle AMHA.
Ce type de user case est celui de "la consolidation de serveurs". C'est le cas dans lequel l'overcommit de mémoire est important et dans lequel il est impératif de pouvoir faire tourner un guest "non modifié".
Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
Cela dit, pour déterminer où ça coince, on a également besoin d'instrumentation, de familiarité avec la plateforme. Et pour cela, encore une fois, plus c'est simple mieux c'est. Encore une fois je pense que c'est un aspect sur lequel Linux+KVM est plus intéressant que Xen. Rien qu'un exemple : on peut facilement tester sans KVM en gardant le reste de l'environnement à l'identique : il suffit de lancer l'émulation avec l'option -no-kvm.
D'autre part, l'instrumentation du "kernel" Xen est à ma connaissance encore très limitée, et de toutes façon il faut encore pouvoir effectuer les diagnostics en tenant compte de ce qui se passe dans Xen mais aussi dans le Dom0. Les niveaux d'encapsulation font que ça revient au même que le débuggage d'une servlet sur un serveur d'application java, et crois moi, je connais beaucoup de sysadmin qui en frémissent (même si sur ce front là il y a eu des progrès).
D'autre part, pour revenir à la problématique de l'hôte, quelque soit son type, oui, à niveau de maturité de code égal et d'effort de développement égal, plus c'est petit et simple (en nombre de LoC) mieux c'est. Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
Moui...
Alors je comprends bien que la comparaison type1/type2 est très à la mode (surtout dans les équipes marketing), mais elle devient obsolète, un peu comme la différence RISC/CISC il y a quelques années. Les solutions actuelles sont devenues hybrides.
Pour ma part, je pense que KVM va très rapidement enfoncer Xen niveau performances sur la partie HVM, dès que les drivers réseaux/disques paravirtualisés seront terminés. KVM est plus "lean" que Xen et il n'y a pas les A/R entre l'hyperviseur et le Dom0 pour les accès au hardware. Sans compter que des fonctionnalités telles que l'overcommit de mémoire (déjà présentes dans KVM) seront difficiles à intégrer dans Xen afaik.
VMWare ESX a la possibillité d'optimiser cela puisqu'ils ont décidé d'intégrer les drivers dans l'hyperviseur. Bien entendu, cela revient a réinventer la roue et a un coup énorme en matière d'effort de développement/support, mais une société commerciale faisant du closed source n'a pas vraiment d'autre possibilité.
Effectivement, pour le support de VM complètement paravirtualisées (à la Xen sans HVM donc), lguest (aussi appellé KVM-lite par Rusty) est bien plus propre que Xen.
Un serveur samba doit etre integré au domaine de la meme facon qu'un poste windows : par un administrateur du domaine.
Je te conseille la lecture (voire l'achat) de l'excellent "samba par l'exemple" :
http://us1.samba.org/samba/docs/man/Samba-Guide/unixclients.html#adssdm
Sinon, un extrait de ma doc perso :
--
vérification du bon fonctionnement de Kerberos
* smbpasswd root et rentrer le mot de passe de l'administrateur du domaine ADS <- *** C EST ICI QU ILS INTERVIENNENT ***
* net ads join -U administrateur : un message doit indiquer que l'on a été rajouté avec succès à MYDOMAIN.AD
* /etc/init.d/samba restart && /etc/init.d/winbind restart puis tester que l'on arrive bien à se connecter aux controleurs ADS via wbinfo -u et wbinfo -g (utiliser wbinfo -p pour voir si on arrive bien à communiquer avec winbindd, le cas échéant)
* net groupmap modify ntgroup="Domain Users" unixgroup=users <- Euh là il me semble que c'est plutôt "Utilisa. du domaine" si t'as un domaine français
* net groupmap modify ntgroup="Domain Guests" unixgroup=nogroup
* net groupmap modify ntgroup="Domain Admins" unixgroup=root
* net groupmap list : on doit obtenir la liste des comptes pour lesquels une correspondance entre compte local et compte ADS a été forcée.
[^] # Re: Libvirt ?
Posté par entr0p1e . En réponse à la dépêche Première publication de la plate-forme libre de HaaS (Hardware as a service) NiftyName. Évalué à 2.
>> environnement de production. De plus, libvirt supporte principalement Xen,
>> que nous avons écarté aussi, trouvant KVM plus prometteur.
>
>Ca c'est balot, parce qu'en ce moment, tout converge vers libvirt. RH emploi du beau
>linge pour travailler dessus, mais c'est aussi le seul gestionnaire de vm descent des
>dernières Debian, ... bref ce n'est plus l'affaire de quelques mois avant que libvirt
>soit l'outil de base/quasi standard pour les sysadmins. Autant dire que les autres
>solutions resteront... très confidentielles.
Le fait que cela soit repandu ou standard ne prejuge en rien de sa qualite.
Je suis rassure que les gens de Ielo aient ecarte libvirt, ca montre qu'ils savent voir au dela du hype.
La grande force de libvirt est effectivement d'etre capable de s'interfacer avec plusieurs plateformes de virtualisation. C'etait une piece importante de la strategie de RH et lui a permis de changer de solution de virtualisation sous-jacente (de xen a kvm).
Mais cela reste amha une usine a gaz fragile qui n'exploite que le plus petit commun denominateur. Un design clean a partir de zero pour un produit qui ne tente pas d'utiliser plusieurs hyperviseurs ne me parait pas idiot. A remarquer qu'il y a des outils simples fait par des admins pour des admins qui marchent bien (genre kvmctl de finntux).
>D'autre part les devs de libvirt contribuent fortement à Qemu/KVM (et un peu à Xen)
> : ce sont donc eux qui infléchirons la direction qui leur convient en ce qui concerne
>la gestion ; ils ont déjà implémenté le support d'auth par certificat X.509 sur le VNC
>de Qemu, ainsi que le support des multiples sorties graphiques simultanées, de
>l'auth SASL, ils travaillent sur le design de l'interface stdio de Qemu, l'intégration
>avec func (un projet RH aussi), FreeIPA, Cobbler, Puppet, ...
C'est vrai que le groupe Emerging Technologies de RH contribue pas mal a Qemu.
Cela dit, comme le nom de leur groupe l'indique, ce sont surtout des gens qui font des prototypes qui passent ensuite souvent en prod tels quels (voir les ProtoTry de http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns ). Ce faisant, ils ont tendance a privilegier le quick and dirty et non un design propre/sain.
Un exemple est le fait qu'ils aient choisis de lancer tout en root, ou encore de se mapper sur la console qemu plutot que de pousser dans qemu une lib qui aurait permis de s'interfacer de facon propre et robuste (avec bindings dans plusieurs langages).
Il est dommage egalement qu'ils n'aient pas commence par rajouter l'auth sasl/pam avant de mettre en place l'usine a gaz pour les certificats et les changements de mots de passe.
Cela dit, il aurait ete plus fute de coder un broker de connections vnc qui effectue le controle/l'authentification en amont de qemu, sur la base de "user/group policies", via sasl/pam. Cela aurait permis d'avoir un acces sur un port unique pour toutes les vms situees sur une machine, et de permettre l'authentification dynamique contre toutes sortes de backends.
Alors, oui, ils contribuent, mais leurs choix ne sont pas forcement les meilleurs.
D'autre part, ils n'ont pas la main-mise sur qemu (ils n'ont meme pas d'acces en ecriture au repo pour l'instant) donc rien n'empeche les gens de Ielo/LO ou des contributeurs externes de rajouter des fonctionnalites.
>Un peu de concurrence et d'émulation ne feront pas de mal, mais j'ai l'impression
>que c'est une cause perdue d'avance :(
Non pas forcement. Ce qui compte, c'est comme tu l'as implicitement fait remarquer, c'est le code commite.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par entr0p1e . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 0.
Désolé, moi je n'adhère pas.
Si l'article est de tellement mauvaise qualité qu'il faut lire la totalité des commentaires, puis les vérifier pour arriver à se faire une idée de l'état de l'art, alors il aurait mieux fallu qu'il ne soit pas publié. Sur des sujets aussi "hype" que la virtualisation, le marketing fait déjà des ravages et il est bien difficile de se faire une idée des réalites _techniques_, voire, sous les descriptions de haut-niveau, de comprendre comment ça marche, tout simplement.
PS: lezard breton as surement envie de regarder à nouveau les différentes définitions de clientélisme.
# article avec bien trop d'erreurs ou d'inexactitudes
Posté par entr0p1e . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à -5.
Sérieux, il mélange tellement tout que je pense qu'il faudrait le supprimer.
Tout ce que je peux conseiller, c'est de ne pas s'y fier pour vous faire une opinion sur quelle techno fait quoi et quel est l'état de l'art.
[^] # Re: Niieeee??
Posté par entr0p1e . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 3.
C'est surtout pour ca que RH a lancé le projet Xenner [1]qui permet de faire tourner des kernels "xen-isés" sur du kvm, pour pouvoir se débarrasser de Xen tout en continuant a supporter la base installée.
Et puis ca serait sympa de préciser que tu bosses pour Citrix/XenSource!
(Ne le prends pas mal, j'apprécie énormément le boulot que tu fais, notamment sur qemu).
Gildas, partie prenante pour kvm.
[1] http://kraxel.fedorapeople.org/xenner/
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 5.
>Le HPC est tres loin de se limiter aux clusters Linux. Par exemple environ la moitie des 10 machines le plus puissantes du top500 n'executent pas Linux sur les noeuds de calcul (BlueGene -> CNK, Cray -> Catamount). C'est a mon avis une erreur de limiter le HPC aux clusters Linux, pour cela que ldans mes posts precedents j'ai pris la peine de citer ces plate-formes. Je pense d'ailleur que c'est _le_ point qui fait que l'on se soit pas totalement d'accord car ton analyse est tres pertinente et en dehors de ce point, je suis globalement d'accord avec toi.
OK, disons que mon approche se voulait pragmatique et que je me cantonnais à des clusters Linux sur x86. Pourquoi? Parce que même s'il est vrai que sur le papier il existe des solutions bien plus performantes, la réalité est que d'un point de vue pragmatique, elles ne sont que peu viables (je pourrais revenir là dessus si ça t'intéresse mais ça risque d'être long :)).
(et oui, je met de côté MS WCCS)
>> des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
>Quand tu n'as pas de Linux, ca ne marche plus. Et il est clair que ces cas la m'interessent. Et meme si les BlueGene et les Cray vont bientot offrir du Linux sur les noeuds de calcul, vu que c'est une version de Linux "epuree", toutes ces solutions ne fonctionneront clairement pas.
Perso je préfère les "sweet spots" :)
>> Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware
>Heu la non, pas tout a fait. Personnellement je ne peux pas justifier n'importe quoi sans prouver que la degradation en terme de perf n'est pas trop importante. Et dans ce contexte, clairement la nature de l'hyperviseur est important. Avec un type-I, on peut faire un domaine hote petit (dans les solutions actuelles ce n'est pas le cas par defaut) et un hyperviseur avec un comportement predictible (pas le cas de Xen dans certains cas) pour l'execution d'applications paralleles. Je ne pense vraiment pas que tu puisse faire la meme chose avec une solution de type-II (et en fait pas non plus avec les solutions de type-II actuellement dispo!).
Je suppose que tu voulais dire "les solutions de type-I actuellement dispo". Si c'est le cas, c'est bien mon avis également.
> Dans mon cas, je ne peux justifier qu'au maximum 10% de penalite avec un vrai apport en terme de fonctionnalites. Si tu passes d'un micro-noyau a Linux + virtualisation, c'est quasiment impossible (deja le passage a Linux meme apres optimisation donne une penalite d'environ 25% dans les all-to-all avec des applications MPI lorsque l'on compare a un micro-noyau).
Mmmh je reste très circonspect sur le calcul des % de pénalité, etc... Les benchmarks c'est un domaine TRES difficile. que ce soit en micro analyse ou macro analyse.
(je ne resiste pas à l'envie de dire à ce sujet que les "near natives performances" de Xen étaient vraies pour Xen 2 avec du paravirtualisé et que sur du Xen 3 avec HVM je pense qu'il y aura des décus)
>> Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0.
>Pour le HPC sur une machine type Cray, non, impossible actuellement. Sur un cluster deja Linux je suis d'accord avec toi. Mais a nouveau ca sort du HPC strict, ca devient "HPC avec cluster Linux", ce qui je te l'accorde concerne beaucoup de gens, mais pas tout le monde. :-)
Oui, de la même façon que tout le monde ne conduit pas de Formule 1 pour aller au travail
> Et puis meme avec Linux je demande a voir. Mes premiers tests avec KVM n'ont pas montres d'interets reels.
On en reparle dans 1 an? ;)
>> Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
> Egalement d'accord a 200% avec toi (ce que meme des gens faisant de l'OS oublient parfoit) mais je pousse l'analyse un poil plus loin : Linux est bien trop complexe (desole mais l'architecture de systeme de fichier, je la trouve vraiment trop complexe :-). Pour cela que je prefere "naturellement" les solutions de type-I : ca t'ouvre les portes pour mettre ce que tu veux dans les VMs mais aussi dans le domaine hote; les differents "composants" de la solution de virtualisation sont bien separes; avec une solution de type-II c'est bien plus complexe (imbrications et dependences).
Je pense que sur le papier tu as raison, dans la "vraie vie" la tendance risque de s'inverser :o)
>> La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
>Dans l'absolu je suis bien d'accord. As-tu jeter un coup d'oeil aux projets finances par la NSF autour de la virtualisation? Il y a des idees interessantes (meme si a mon avis il manque des choses parfois). L'un des projets est le suivant, impossible de remettre le main sur le deuxieme (qui est pourtant plus interessant a mon sens car fonde sur l'idee d'un framework pour le developpement de nouvelles solutions de virtualisation) :
http://www.nsf.gov/news/news_summ.jsp?cntn_id=110606&org(...)
Chouette de la lecture! Non je ne connaissais pas, j'y jetterais un oeil demain.
>> La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux
>Justement, pourquoi ne pas reprendre des microkernels existant pour mettre en oeuvre une nouvelle solution (un peu l'idee de L4) ? Bien sur ca sera tres specialise pour une plate-forme donnee (toujours le probleme des drivers) mais je pense que cette approche serait bien plus interessante.
Parce qu'on va tomber dans un débat micro- vs. macro- ?
> Je recupere des resultats de profiling tous les jours en ce moment en utilisant Xen et oprofile, ca marche plutot bien. Par contre, c'est sur que si tu veux debugger ta VM seule, une solution de type-II est bien meilleure (ce que j'ai deja dis auparavant).
Intéressant, cela a donc notablement avancé depuis que j'ai arretté de lire les MLs de xen et de lire les papiers!
> A noter que la simplicite dont tu parles est perdue des que tu veux faire ca au sein d'un cluster de taille assez importante (d'un autre cote, une solution open-source qui apporte un bout de solution pour ca devrait bientot etre mise a disposition, permettant aux utilisateurs de passer tres simplement de VMs sur un cluster a un cluster "normal").
Un truc sur lequel tu bosses?
> Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
> Non je ne suis pas tout a fait d'accord, il est possible d'avoir un hyperviseur petit et modulaire (donc pas Xen), un hostOS petit (donc pas Linux avec les configurations associees aux solutions de virtualisation actuelles), et des VMs avec ce que l'on veut dedans. Avec Linux+KVM, tu t'eloignes tout de suite de ca (overhead de Linux par rapport a des micro-noyaus specialises).
C'est vrai, mais tu y gagnes sur le fait que ça existe déjà et c'est déjà bien répandu et donc qu'il est plus facile d'obtenir du support.
> Mais bon, je pense aussi que de toute facon, avec les solutions actuelles, des que tu passes a une plate-forme distribuee (e.g., cluster), tu te prends la tete et pas qu'un peu.
Ca va tout à fait dans le sens de ce que je disais dans mon autre réponse (dur de suivre vu que nos réponses se croisent :))
> Pour conclure ton analyse est vraiment pertinente, merci pour ca (ca faisait longtemps que je n'avais pas eu une discussion interessante sur LinuxFr!). Le seul bemol que je me permets est que dans mon cas je ne me limite pas a du tout Linux. :-) Ce qui bien sur n'interessera que peu de personnes ici.
Je ne me limite pas qu'à Linux pour ce qui est de comprendre/suivre les tendances, mais par contre j'ai une approche plus pragmatique/orientée production que toi, ce qui est bien normal étant donné nos métiers différents!
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 2.
"les gens" ici égale mon "marketing" :) Il n'était pas évident dans ta contribution que tu te référais bien au sens original, même si bien sûr j'aurais du m'en douter venant de toi. Cela dit, le fait que toi tu utilises ces termes correctement n'enlève rien à ma remarque, qui ne t'était pas forcément adressée.
> A noter aussi qu'il met Xen dans les micro-kernel, ce qui est faux! Ca n'est pas parce que Xen est petit (quoique sur ca aussi il y a discuter), qu'il est un micro-kernel. Un micro-kernel, c'est par exemple L4 et Xen est tres loin d'une architecture de micro-kernel (Xen a un design tres monolithique).
Donc au final, je ne suis pas d'accord avec l'analyse de Anthony Liguori qui a mon avis melange beaucoup de chose dans cet article et oublie les definitions exactes et initiales.
> Ensuite et pour finir, je ne veux pas prouver que ce qui a ete dit est faux, je souhaite juste souligner que la question de la virtualisation n'est pas simple et que les conclusions demandent totalement du contexte.
Je suis parfaitement d'accord avec toi! Je tentais de souligner cette difficulté, qui commence par une utilisation incorrecte de notion précises.
C'est aussi pour cela que l'article d'Anthony est intéressant car oui, il contient des erreurs et approximations, et pourtant il est écrit par quelqu'un qui travaille pour IBM et contribue de près à 3-4 solutions de virtualisations open source.
Que dire de quelqu'un qui n'en a qu'une vue de loin, surtout quand le hype (ou des contraintes mercantiles) s'en mèle?
> Je tente juste d'expliquer mon point du vue dans le contexte qui m'interesse (recherche en OS pour resumer).
Pour ma part, même si l'aspect conceptuel m'intéresse (obviously), j'ai un lourd passif de sysadmin, donc l'aspect production/pragmatisme m'interpelle également!
> D'ailleur il le dit bien : "Many people think the terms "type-1" and "type-2" originated from this paper but that is simply not the case. The paper does mention the concept of recursive virtualization and briefly discusses the requirements to allow one virtual machine to run within another virtual machine." Forcement c'est dans l'autre papier! Il cite le papier de Popek et Goldberg, pas celui de Goldberg seul (celui de sa these). C'est le papier de Goldberg qui presente la classification de maniere precise. Mais c'est une erreur commune que l'on retrouve meme dans les publications scientifiques sur le sujet.
Intéressant, je n'avais pour ma part jamais vu la référence à sa thèse. Il faut dire que je n'avais que survolé les références du papier écrit avec Popek à l'époque où j'avais la possibilité d'accéder aux documents de l'ACM.
Je pense que malheureusement le fait qu'un grand nombre de papiers de références en informatique ne sont disponibles que via des subscriptions est une des raisons pour lesquelles la roue est sans cesse réinventée et les termes galvaudés.
> Il dit ensuite " like VMware Workstation, Parallels, VirtualPC, and KVM all rely on kernel modules which means they do have direct access to hardware" et c'est bien ce qui est important : le module _doit_ avoir un systeme hote pour fonctionner, initialiser la memoire et compagnie. Pour une solution de type-I, le VMM boot en premier. Du coup, si tu n'as pas besoin de drivers particulier, tu n'as pas besoin du systeme hote. C'est pourquoi lorsque tu regardes le cycle de vie d'une VM, il n'y a absolument pas besoin d'acceder au domaine hote au moins dans les premiers instants de vie de la VM. Quel interet si on ne peut utiliser de drivers? et bien tu es libre d'utiliser ce que tu veux comme domaine hote plus tard, et non pas seulement Linux (pourquoi pas un OS specialise parfaitement adapte a ta plate-forme, e.g., CNK des BlueGene). C'est completement impossible avec une solution de type-II. Bon d'accord on parle ici de recherche mais comme je l'ai dis des le debut, c'est le contexte qui m'interesse.
Hum là je dois avouer que tu m'as perdu entre les considérations liées au démarrage du VMM et celles liées au démarrage de la VM. Je serais interessé par un complément d'information/de la clarification!
> Pour ce qui est de savoir qui est le plus performant, a mon avis la question a peu de sens, il faut preciser avec quelle application et surtout quelle plateforme materielle.
Tout à fait d'accord, je mettais d'ailleurs l'accent sur l'importance de cet aspect même en ne considérant uniquement que le monde du HPC, dans lequel il y a déjà une énorme variabilité dans la nature des applications/workload : CPU bound/memory bound/IO bound, sensible à la latence, embarrasingly parallel, massively parallel, etc ...
Personellement, après avoir passé 1 an en temps que sysadmin dans une équipe gérant un cluster de 1500 coeurs faisant tourner des applications "embarrassingly parrallel", je ne suis pas convaincu de l'utilité de la virtualisation sur de telles échelles, à part lorsque la plateforme est partagée (genre planetlab). Et le problèmatiques qui se posent pour des architectures basées sur des images (façon cloud) sont celles du déploiement des images, du stateless etc... Pas si simple!
> A noter egalement que le HVM a priori n'ameliore pas les performances (surtout dans le cas d'une solution de Type-I initialement implementee par de la para-virtualisation). Ca simplifie les choses et ouvre des portes, c'est tout.
Oui, il y a d'ailleurs eu le papier d'ingénieurs de VMWare a ce propos http://www.vmware.com/pdf/asplos235_adams.pdf
Il me semble que le HVM s'améliore de génération en génération (arrivée du NPT par exemple pour les derniers CPU) et il est probable que cela changera la donne. Une fois encore, on en arrive à une situation de type balance entre logique cablée/software.
> PS : ce fut en tout cas une discussion agreable qui m'a permi de lire des articles/blogs que je n'avais pas lu. Toujours interessant de voir des avis differents lorsque c'est argumente, ce qui devient un peu trop rare a mon gout sur ce site. :-)
Merci du compliment :) Je pense que l'essentiel de nos différences viennent du bout de la lorgnette par lequel nous regardons les choses, recherche pour toi, production info pour moi. Effectivement, ça n'enlève rien à la qualité de tes arguments.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 2.
En fait, le gros problème à ce niveau est la définition de ce que l'on entends par type I et type II. C'est pour cela que je parlais de la version marketing, parce que pour moi les différences pourtant claires à la lecture des quelques articles fondateurs sur la virtualisations sont devenues très floues au fur et à mesure que j'en apprenais plus sur les solutions existantes.
Anthony Liguori (qui a notamment contribué à Xen, Qemu et KVM), a écrit un article là dessus et en parlera bien mieux que moi :
http://blog.codemonkey.ws/2007/10/myth-of-type-i-and-type-ii(...)
A noter que la page wikipedia http://en.wikipedia.org/wiki/Hypervisor classe KVM en type I également.
Voilà, le point important pour moi a ce sujet c'est que finalement, bien malin est celui qui peut dire lequel est le plus performant entre I et II, surtout maintenant que les CPU "grand public" ont des instructions HVM. C'est ce que je résume (peut être maladroitement) en appelant ça un argument marketing.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 4.
Si tu te cantonnes au HPC, déjà, clairement la solution dépendra du type de contentions créées par le workload (c'est d'ailleurs une des raisons pour laquelle je doute de l'intérêt d'une solution de type SSI, mais tu le dis toi-même en réponse à un autre post, son marché de niche ce sont des applis non optimisées HPC sur des tout petits clusters).
Sur un cluster HPC dont le workload est tel que les contentions se font sur le CPU ou la mémoire, je ne suis pas forcément certain de l'intérêt de la virtualisation, et comme la majeure partie des clusters HPC existants tournent sur du linux, des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
> avec une solution de virtualisation, type KVM, le domaine hote doit absoluement etre un Linux. Or si tu prends les plate-forme HPC actuelles type BlueGene ou Cray, c'est rarement le cas. Tu vas me dire que dans ce cas, la solution de type-I ne fonctionne pas plus car le domaine hote doit etre un Linux. C'est vrai mais cela devrait changer dans un avenir proche si tout va bien
Je ne vois pas en quoi la nature de l'hyperviseur intervient. Les points pertinents à mon avis sont:
- est-ce qu'il est opensource (dans le cas où c'est un prérequis, il y a plein de gens qui s'en foutent, que ce soit heureux ou malheureux)
- est-ce qu'il fait bien son boulot et notamment est-ce qu'il utilise une quantité de ressources négligeable (overhead mais aussi taille occupée etc)
- est-ce qu'il est facile à débugger/faire évoluer/manager
Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware (et là, malheureusement, j'ai tous les jours la preuve que le déploiement de VMs ne se fait pas toujours pour des raisons pragmatiques).
La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux (cf. ma remarque sur ESX dans mon précédent post). Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0. Les seuls vrais concurrents que je verrais seraient les projets a base de L4 réutilisant les drivers linux en les isolant. Mais Linux+KVM a AMHA une longueur d'avance sur eux, sans compter une base de développeurs et d'utilisateurs bien supérieure.
Si on sort du domaine du HPC et qu'on s'intéresse à des clusters composés de noeuds faisant tourner des VMs de type appliances applicatives, alors ESX est la seule solution vraiment de niveau production à l'heure actuelle AMHA.
Ce type de user case est celui de "la consolidation de serveurs". C'est le cas dans lequel l'overcommit de mémoire est important et dans lequel il est impératif de pouvoir faire tourner un guest "non modifié".
Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
Cela dit, pour déterminer où ça coince, on a également besoin d'instrumentation, de familiarité avec la plateforme. Et pour cela, encore une fois, plus c'est simple mieux c'est. Encore une fois je pense que c'est un aspect sur lequel Linux+KVM est plus intéressant que Xen. Rien qu'un exemple : on peut facilement tester sans KVM en gardant le reste de l'environnement à l'identique : il suffit de lancer l'émulation avec l'option -no-kvm.
D'autre part, l'instrumentation du "kernel" Xen est à ma connaissance encore très limitée, et de toutes façon il faut encore pouvoir effectuer les diagnostics en tenant compte de ce qui se passe dans Xen mais aussi dans le Dom0. Les niveaux d'encapsulation font que ça revient au même que le débuggage d'une servlet sur un serveur d'application java, et crois moi, je connais beaucoup de sysadmin qui en frémissent (même si sur ce front là il y a eu des progrès).
D'autre part, pour revenir à la problématique de l'hôte, quelque soit son type, oui, à niveau de maturité de code égal et d'effort de développement égal, plus c'est petit et simple (en nombre de LoC) mieux c'est. Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 2.
Alors je comprends bien que la comparaison type1/type2 est très à la mode (surtout dans les équipes marketing), mais elle devient obsolète, un peu comme la différence RISC/CISC il y a quelques années. Les solutions actuelles sont devenues hybrides.
Pour ma part, je pense que KVM va très rapidement enfoncer Xen niveau performances sur la partie HVM, dès que les drivers réseaux/disques paravirtualisés seront terminés. KVM est plus "lean" que Xen et il n'y a pas les A/R entre l'hyperviseur et le Dom0 pour les accès au hardware. Sans compter que des fonctionnalités telles que l'overcommit de mémoire (déjà présentes dans KVM) seront difficiles à intégrer dans Xen afaik.
VMWare ESX a la possibillité d'optimiser cela puisqu'ils ont décidé d'intégrer les drivers dans l'hyperviseur. Bien entendu, cela revient a réinventer la roue et a un coup énorme en matière d'effort de développement/support, mais une société commerciale faisant du closed source n'a pas vraiment d'autre possibilité.
Effectivement, pour le support de VM complètement paravirtualisées (à la Xen sans HVM donc), lguest (aussi appellé KVM-lite par Rusty) est bien plus propre que Xen.
Mes 2 cents.
# c'est bien cela
Posté par entr0p1e . En réponse au message Samba et Active Directory. Évalué à 1.
Je te conseille la lecture (voire l'achat) de l'excellent "samba par l'exemple" :
http://us1.samba.org/samba/docs/man/Samba-Guide/unixclients.html#adssdm
Sinon, un extrait de ma doc perso :
--
vérification du bon fonctionnement de Kerberos
* kinit username@MYDOMAIN.AD
* klist
* smbclient -k //adserver1.mydomain.ad/shareontadserver1
* kdestroy
intégration au domaine ADS
* smbpasswd root et rentrer le mot de passe de l'administrateur du domaine ADS <- *** C EST ICI QU ILS INTERVIENNENT ***
* net ads join -U administrateur : un message doit indiquer que l'on a été rajouté avec succès à MYDOMAIN.AD
* /etc/init.d/samba restart && /etc/init.d/winbind restart puis tester que l'on arrive bien à se connecter aux controleurs ADS via wbinfo -u et wbinfo -g (utiliser wbinfo -p pour voir si on arrive bien à communiquer avec winbindd, le cas échéant)
* net groupmap modify ntgroup="Domain Users" unixgroup=users <- Euh là il me semble que c'est plutôt "Utilisa. du domaine" si t'as un domaine français
* net groupmap modify ntgroup="Domain Guests" unixgroup=nogroup
* net groupmap modify ntgroup="Domain Admins" unixgroup=root
* net groupmap list : on doit obtenir la liste des comptes pour lesquels une correspondance entre compte local et compte ADS a été forcée.