> 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.
Au moins pour ce qui se passe actuellement au niveau recherche, je pense le contraire : la difference entre type-I et type-II a toujours beaucoup de sens et doit etre preservee car les deux approches ne repondent pas aux meme besoins. Pour justifier le type-I, il est par exemple possible d'analyser les besoins associes a l'execution des applications scientifiques et le HPC. Dans ce cas, dire que la distinction type-I et type-II est avant tout marketing est totalement deplace (je donne quelques points plus bas pour illustrer cela).
De plus tu dis que les solutions actuelles sont hybrides, je crois que c'est vraiment faux. Uniquement _quelques_ solutions sont hybrides, ou alors peux-tu me citer ces solutions SVP, car j'ai besoin d'etre eduque sur le sujet si c'est le cas.
> 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.
Pour eviter les A/R entre l'hyperviseur et le Dom0, on sait deja que la notion de "sidecore" est une solution efficace : tu places l'hyperviseur sur un core et tu executes les VMs et le domaine hote sur d'autres cores. C'est simple et tu gagnes beaucoup en performance. Tu peux te reporter aux travaux fait a GATech pour plus de details (entre autre). Ensuite pour l'overcommit de la memoire, tout d'abord je ne vois pas pourquoi tu veux faire ca (au moins dans le cadre des applications scientifiques/HPC) et ensuite la manipulation de la memoire avec une solution de type-I est tres proche du cout de la gestion memoire dans un systeme normal. J'ai fais des tests avec Xen, le cout est entre 0 et 2 %. Le probleme se situe principalement au niveau des entrees/sorties et la, le type-II n'apporte pas forcement quelque chose de plus. A chaque fois, quelque soit la techno selectionnee, il faut acceder au materiel de maniere directe depuis les VMs, avec le partage entre les VMs.
D'un autre cote, si tu vises le HPC, tu tombes sur les problemes suivant : 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 (plusieurs projets de recherche sur le sujet). :-) L'autre point interessant est de savoir pourquoi l'hyperviseur devrait etre un module du noyau Linux pour faire des choses simples, i.e., seulement manipuler de la memoire. L'inclusion dans le noyau impose de suivre les evolutions du noyau alors que si tu assumes que l'hyperviseur tourne directement sur le materiel, tu devrais tres peu le modifier dans le temps. Du coup, tu peux garder une architecture simple avec un hyperviseur minimal, une interface claire et simple pour les VMs et le domaine hote. Si tu regardes ce qui se fait dans KVM, on commence a etre loin de cette simplicite.
Pour conclure je vais aller dans ton sens : ce qui est actuellement disponible ne pousse pas a faire la distinction entre type-I et type-II _mais_ les projets de recherche autour de la virtualisation et du HPC notamment devrait aboutir a des solutions ou la distinction est importante.
Et au final, chaque solution a son utilite : le type-II est bien plus interessant pour le developpement et le type-I semblent plus interessant pour l'execution efficace d'applications, notamment les applications scientifiques. Mais bon la on touche clairement la recherche alors l'avenir montera peut-etre que j'ai tord.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 3.
Au moins pour ce qui se passe actuellement au niveau recherche, je pense le contraire : la difference entre type-I et type-II a toujours beaucoup de sens et doit etre preservee car les deux approches ne repondent pas aux meme besoins. Pour justifier le type-I, il est par exemple possible d'analyser les besoins associes a l'execution des applications scientifiques et le HPC. Dans ce cas, dire que la distinction type-I et type-II est avant tout marketing est totalement deplace (je donne quelques points plus bas pour illustrer cela).
De plus tu dis que les solutions actuelles sont hybrides, je crois que c'est vraiment faux. Uniquement _quelques_ solutions sont hybrides, ou alors peux-tu me citer ces solutions SVP, car j'ai besoin d'etre eduque sur le sujet si c'est le cas.
> 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.
Pour eviter les A/R entre l'hyperviseur et le Dom0, on sait deja que la notion de "sidecore" est une solution efficace : tu places l'hyperviseur sur un core et tu executes les VMs et le domaine hote sur d'autres cores. C'est simple et tu gagnes beaucoup en performance. Tu peux te reporter aux travaux fait a GATech pour plus de details (entre autre). Ensuite pour l'overcommit de la memoire, tout d'abord je ne vois pas pourquoi tu veux faire ca (au moins dans le cadre des applications scientifiques/HPC) et ensuite la manipulation de la memoire avec une solution de type-I est tres proche du cout de la gestion memoire dans un systeme normal. J'ai fais des tests avec Xen, le cout est entre 0 et 2 %. Le probleme se situe principalement au niveau des entrees/sorties et la, le type-II n'apporte pas forcement quelque chose de plus. A chaque fois, quelque soit la techno selectionnee, il faut acceder au materiel de maniere directe depuis les VMs, avec le partage entre les VMs.
D'un autre cote, si tu vises le HPC, tu tombes sur les problemes suivant : 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 (plusieurs projets de recherche sur le sujet). :-) L'autre point interessant est de savoir pourquoi l'hyperviseur devrait etre un module du noyau Linux pour faire des choses simples, i.e., seulement manipuler de la memoire. L'inclusion dans le noyau impose de suivre les evolutions du noyau alors que si tu assumes que l'hyperviseur tourne directement sur le materiel, tu devrais tres peu le modifier dans le temps. Du coup, tu peux garder une architecture simple avec un hyperviseur minimal, une interface claire et simple pour les VMs et le domaine hote. Si tu regardes ce qui se fait dans KVM, on commence a etre loin de cette simplicite.
Pour conclure je vais aller dans ton sens : ce qui est actuellement disponible ne pousse pas a faire la distinction entre type-I et type-II _mais_ les projets de recherche autour de la virtualisation et du HPC notamment devrait aboutir a des solutions ou la distinction est importante.
Et au final, chaque solution a son utilite : le type-II est bien plus interessant pour le developpement et le type-I semblent plus interessant pour l'execution efficace d'applications, notamment les applications scientifiques. Mais bon la on touche clairement la recherche alors l'avenir montera peut-etre que j'ai tord.