Donc en mode Xen (j'y reviens plus loins).
C'est actuellement quasiment la même chose. Les différences entre Xen et KVM sont génées par libvirt (utilisé par virt-manager). Actuellement RHEL 5.x n'utilise que Xen. Les dernières versions de Fedora utilise KVM par défaut, non car actuellement KVM est forcément mieux que Xen, mais seulement car KVM (et paravirt_ops) est vu comme l'avenir de la virtualisation et Fedora est principalement dédié à la communauté des développeurs. Bien que Red Hat ne communique pas sur ça, il y a fort à parier que RHEL 6 va passer à KVM (au moins par défaut).
> Après c'est peut-etre juste les tutoriaux qui sont de mauvaise foi.
Peut-être mais je ne crois pas. Il ne doivent pas être à jour.
Le problème de l'installation en mode paravirtualisation est que l'installeur (qui est sur le CD par exemple) doit reconnaitre le matos qu'on lui propose. Tous les installeurs n'était pas au fait de Xen à ses début. Autre problème, c'est l'affichage, etc... Au début de Xen, il n'y avait pas de périphérique pour faire l'affichage. Donc on ne pouvait utiliser l'installeur et il fallait utiliser des "hacks". On pouvait faire tourner une installation de Linux mais pas son installeur.
J'imagine que les "debootstraop ou rpmstrap" sont (ou étaient) là principalement pour contourner ce problème.
> Parce que ton exemple montre l'utilisation dans un cadre 'support hardware'.
Certes, mais ça va devenir hypra commun dans quelques années et la paravirtualisation de Xen va devenir obsolète (au moins pour les serveurs).
Notons que la transition va se faire dans la douceur (plus ou moins). Fedora va mettre les bouchées doubles pour que paravirt_ops de F9 (qui n'aura pas XenSource) supporte Xen dom0 et domU. Donc si tu as une machine virtuelle qui tourne sous Xen (domU), elle tournera aussi sur une serveur qui n'utilise pas XenSource.
Le plan sur la virtualisation pour F9 (jugé très ambitieux pour ne pas dire risqué) : http://fedoraproject.org/wiki/Features/XenPvops
[^] # Re: Ca bouge !
Posté par IsNotGood . En réponse à la dépêche Sortie de NetBSD 4.0. Évalué à 1.
Donc en mode Xen (j'y reviens plus loins).
C'est actuellement quasiment la même chose. Les différences entre Xen et KVM sont génées par libvirt (utilisé par virt-manager). Actuellement RHEL 5.x n'utilise que Xen. Les dernières versions de Fedora utilise KVM par défaut, non car actuellement KVM est forcément mieux que Xen, mais seulement car KVM (et paravirt_ops) est vu comme l'avenir de la virtualisation et Fedora est principalement dédié à la communauté des développeurs. Bien que Red Hat ne communique pas sur ça, il y a fort à parier que RHEL 6 va passer à KVM (au moins par défaut).
> Après c'est peut-etre juste les tutoriaux qui sont de mauvaise foi.
Peut-être mais je ne crois pas. Il ne doivent pas être à jour.
Le problème de l'installation en mode paravirtualisation est que l'installeur (qui est sur le CD par exemple) doit reconnaitre le matos qu'on lui propose. Tous les installeurs n'était pas au fait de Xen à ses début. Autre problème, c'est l'affichage, etc... Au début de Xen, il n'y avait pas de périphérique pour faire l'affichage. Donc on ne pouvait utiliser l'installeur et il fallait utiliser des "hacks". On pouvait faire tourner une installation de Linux mais pas son installeur.
J'imagine que les "debootstraop ou rpmstrap" sont (ou étaient) là principalement pour contourner ce problème.
> Parce que ton exemple montre l'utilisation dans un cadre 'support hardware'.
Certes, mais ça va devenir hypra commun dans quelques années et la paravirtualisation de Xen va devenir obsolète (au moins pour les serveurs).
Notons que la transition va se faire dans la douceur (plus ou moins). Fedora va mettre les bouchées doubles pour que paravirt_ops de F9 (qui n'aura pas XenSource) supporte Xen dom0 et domU. Donc si tu as une machine virtuelle qui tourne sous Xen (domU), elle tournera aussi sur une serveur qui n'utilise pas XenSource.
Le plan sur la virtualisation pour F9 (jugé très ambitieux pour ne pas dire risqué) :
http://fedoraproject.org/wiki/Features/XenPvops