> 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.
[^] # 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.