Aspects intégration :
UML est intégré dans le noyau Vanilla de Linus Torvalds, à l'exception du patch skas (qui optimise pas mal UML). Xen n'est pas encore intégré en tant qu'archi, ni complètement VServer. Donc patienter ou être actif quant à l'intégration dans les distros.
Aspects techniques :
VServer est un « isolateur », donc les processus tournent directement sur l'OS hôte qui tourne en natif sur le matériel. Optimal en terme de perfs, ce sont les environnements utilisateurs qui sont isolés, un seul OS est installé directement sur la matos. Très utilisé dans le monde de l'hébergement mutualisé, et je crois sur LinuxFr.org.
UML est un vrai noyau Linux recompilé pour « l'architecture » UML : il va tourner en user-space et va pouvoir se lancer comme une appli de l'OS installé directement en natif sur le matériel. Chaque UML lancé va pouvoir lancer et gérer ses applis dans son propre « espace-utilisateur ». Les applis dans chaque UML tournent donc au dessus du l'OS hôte ET au dessus de son UML (qui tourne en parallèle aux autres UML). Pas vraiment optimal en terme de conso de ressources. Très utilisé pour le test et déboggage du noyau Linux, et pas mal utilisé en hébergement mutualisé également.
Une machine virtuelle comme Bochs/Plex86, QEMU ou PearPC (VMWare, VirtualPC ou Guest PC mais c'est proprio) est une appli qui s'installe dans l'OS hôte. Il simule/émule une machine complète. Les OS invités installés dedans n'y voient que du feu. Chaque appli lancée dans son OS invité tourne au dessus de son OS, la machine virtuelle, ET l'OS hôte (et en parallèle aux autres OS invités), donc sub-sub-optimal. Pour faire des tests d'OS complets sans avoir à fricotter avec le matériel et sans besoin fort en perfs. Pas besoin d'adaptation de l'OS invité.
Xen est un mini-OS, une couche fine qui s'installe directement sur le matériel. Les OS invités « voient » Xen et non le matériel, il va falloir donc adapter les OS invités pour les faire tourner sur Xen. Les OS invités sont donc très proches du matériel donc solution quasiment optimale en terme de performances. Des acteurs industriels se sont engagés dans Xen : Fedora/RedHat mais également SUSE/Novell dans leurs prochaines distros respectives, puis AMD dans ses processeurs, HP en contributeur, et des investisseurs dans XenSource, la boîte montée par le team leader de Xen pour développer, supporter et promouvoir Xen.
[^] # Re: XEN vs le reste du monde??
Posté par Nÿco (site web personnel) . En réponse à la dépêche Ouverture de XENfr.org. Évalué à 8.
Aspects intégration :
UML est intégré dans le noyau Vanilla de Linus Torvalds, à l'exception du patch skas (qui optimise pas mal UML). Xen n'est pas encore intégré en tant qu'archi, ni complètement VServer. Donc patienter ou être actif quant à l'intégration dans les distros.
Aspects techniques :
VServer est un « isolateur », donc les processus tournent directement sur l'OS hôte qui tourne en natif sur le matériel. Optimal en terme de perfs, ce sont les environnements utilisateurs qui sont isolés, un seul OS est installé directement sur la matos. Très utilisé dans le monde de l'hébergement mutualisé, et je crois sur LinuxFr.org.
UML est un vrai noyau Linux recompilé pour « l'architecture » UML : il va tourner en user-space et va pouvoir se lancer comme une appli de l'OS installé directement en natif sur le matériel. Chaque UML lancé va pouvoir lancer et gérer ses applis dans son propre « espace-utilisateur ». Les applis dans chaque UML tournent donc au dessus du l'OS hôte ET au dessus de son UML (qui tourne en parallèle aux autres UML). Pas vraiment optimal en terme de conso de ressources. Très utilisé pour le test et déboggage du noyau Linux, et pas mal utilisé en hébergement mutualisé également.
Une machine virtuelle comme Bochs/Plex86, QEMU ou PearPC (VMWare, VirtualPC ou Guest PC mais c'est proprio) est une appli qui s'installe dans l'OS hôte. Il simule/émule une machine complète. Les OS invités installés dedans n'y voient que du feu. Chaque appli lancée dans son OS invité tourne au dessus de son OS, la machine virtuelle, ET l'OS hôte (et en parallèle aux autres OS invités), donc sub-sub-optimal. Pour faire des tests d'OS complets sans avoir à fricotter avec le matériel et sans besoin fort en perfs. Pas besoin d'adaptation de l'OS invité.
Xen est un mini-OS, une couche fine qui s'installe directement sur le matériel. Les OS invités « voient » Xen et non le matériel, il va falloir donc adapter les OS invités pour les faire tourner sur Xen. Les OS invités sont donc très proches du matériel donc solution quasiment optimale en terme de performances. Des acteurs industriels se sont engagés dans Xen : Fedora/RedHat mais également SUSE/Novell dans leurs prochaines distros respectives, puis AMD dans ses processeurs, HP en contributeur, et des investisseurs dans XenSource, la boîte montée par le team leader de Xen pour développer, supporter et promouvoir Xen.