> Oui, bien sûr, porter le patch Xen c'est lourdingue.
Mais pour d'autres projets, on ne porte pas. C'est toujours synchro avec la version upstream (les exemples ne manquent pas même si ça n'a pas été accèpté upstream).
Xen est un gros problème dans le cas d'un développement communautaire. Prends Fedora, les développeurs bouffent énormément de temps avec ça.
Qu'il y ait une banche stable/produit, ont comprend tous. Red Hat et le fait par exemple (RHEL 5 c'est linux 2.6.18 et seulement le 2.6.18).
La situation est si "misérable" avec Xen, que VirtualBox est rapidement devenu populaire dans les distributions communautaires (proche upstream). C'est un signe fort.
> dans le cas d'une solution Linuxo/Linux
Marrant la récurence de ce vrai faux argument.
Xen est un solution Xeno/Xen.
Pour la partie serveur (dom0), c'est 100 % Linux ou 100 % Windows etc. Ce n'est pas 50 % Linux, 25 % BSD et 25 % Windows.
Pour la partie client, Linux/paravirt_ops supporte Xen et aussi la virtualisation hardware. Donc pour le client (domU), c'est tout ce que tu veux. C'est ça le plus important.
Et pour info, Windows ne voulait pas (et ne veut peut-être toujours pas) que Xen en mode paravirtualisation soit utilisé avec Linux (s'il fait dom0).
Enfin, comme le fait remarquer Drepper, Xen est quasiment dans la même logique que vmware. C'est-à-dire "dicter" ce que doit être la partie de plus bas niveau d'un OS. Idée insupportable pour beaucoup de développeur Linux.
Alors les Linux centric me font un peu rire quand en face il y a du Xen centric.
> dans le cas d'une solution Linuxo/Linux, KVM est tout à fait adapté en effet.
Red Hat/Fedora est "linux centric", c'est son business. Mais où est la dépendance avec Linux ? C'est ça la bonne question. Fedora utilise libvirt qui marche avec Xen, KVM/qemu, OpenVZ etc... Ce n'est pas du KVM centric ni du Linux centric (d'ailleurs ça marche aussi sous Windows).
La dépendance n'est qu'au très bas niveau et pour des raisons de performance, de développement communautaire, etc.
Si Sun veut utiliser libvirt avec Solaris afin de "draguer" les clients Red Hat, il n'y a pas de problème. Et pour ça Sun n'est pas obligé de se limiter à Xen. Sun peut le faire qu'il utilise Xen ou OpenVZ ou n'importe quoi.
On doit donc pouvoir migrer facilement et rapidement un serveur dom0 Linux vers n'importe grace à libvirt. libvirt qui n'est pas Linux centric ni KVM centric.
> La différence avec Xen, c'est qu'on peut faire la même chose avec Solaris, NetBSD, ...
Pense libvirt. Tu vas voir que la différence disparait.
Aujourd'hui Fedora fait : Linux->Xen->libvirt->virt-manager
Demain : Linux->KVM->libvirt->virt-manager
Solaris fera peut-être : Solaris->OpenVZ->libvirt->virt-manager
Les développeurs d'applis voient libvirt. Les utilisateurs voient virt-manager.
Ils sont indépendants de l'OS et de la solution bas niveau de virtualisation. Tu peux dire que c'est c'est libvirt centric :-)
Pour finir. Je ne pense pas que Xen c'est "le mal". Xen a été pionier, Xen c'est fabuleux.
[^] # Re: Réponses en vrac
Posté par IsNotGood . En réponse au journal Fedora abandonne Xen. Évalué à 1.
Mais pour d'autres projets, on ne porte pas. C'est toujours synchro avec la version upstream (les exemples ne manquent pas même si ça n'a pas été accèpté upstream).
Xen est un gros problème dans le cas d'un développement communautaire. Prends Fedora, les développeurs bouffent énormément de temps avec ça.
Qu'il y ait une banche stable/produit, ont comprend tous. Red Hat et le fait par exemple (RHEL 5 c'est linux 2.6.18 et seulement le 2.6.18).
La situation est si "misérable" avec Xen, que VirtualBox est rapidement devenu populaire dans les distributions communautaires (proche upstream). C'est un signe fort.
> dans le cas d'une solution Linuxo/Linux
Marrant la récurence de ce vrai faux argument.
Xen est un solution Xeno/Xen.
Pour la partie serveur (dom0), c'est 100 % Linux ou 100 % Windows etc. Ce n'est pas 50 % Linux, 25 % BSD et 25 % Windows.
Pour la partie client, Linux/paravirt_ops supporte Xen et aussi la virtualisation hardware. Donc pour le client (domU), c'est tout ce que tu veux. C'est ça le plus important.
Et pour info, Windows ne voulait pas (et ne veut peut-être toujours pas) que Xen en mode paravirtualisation soit utilisé avec Linux (s'il fait dom0).
Enfin, comme le fait remarquer Drepper, Xen est quasiment dans la même logique que vmware. C'est-à-dire "dicter" ce que doit être la partie de plus bas niveau d'un OS. Idée insupportable pour beaucoup de développeur Linux.
Alors les Linux centric me font un peu rire quand en face il y a du Xen centric.
> dans le cas d'une solution Linuxo/Linux, KVM est tout à fait adapté en effet.
Red Hat/Fedora est "linux centric", c'est son business. Mais où est la dépendance avec Linux ? C'est ça la bonne question. Fedora utilise libvirt qui marche avec Xen, KVM/qemu, OpenVZ etc... Ce n'est pas du KVM centric ni du Linux centric (d'ailleurs ça marche aussi sous Windows).
La dépendance n'est qu'au très bas niveau et pour des raisons de performance, de développement communautaire, etc.
Si Sun veut utiliser libvirt avec Solaris afin de "draguer" les clients Red Hat, il n'y a pas de problème. Et pour ça Sun n'est pas obligé de se limiter à Xen. Sun peut le faire qu'il utilise Xen ou OpenVZ ou n'importe quoi.
On doit donc pouvoir migrer facilement et rapidement un serveur dom0 Linux vers n'importe grace à libvirt. libvirt qui n'est pas Linux centric ni KVM centric.
> La différence avec Xen, c'est qu'on peut faire la même chose avec Solaris, NetBSD, ...
Pense libvirt. Tu vas voir que la différence disparait.
Aujourd'hui Fedora fait : Linux->Xen->libvirt->virt-manager
Demain : Linux->KVM->libvirt->virt-manager
Solaris fera peut-être : Solaris->OpenVZ->libvirt->virt-manager
Les développeurs d'applis voient libvirt. Les utilisateurs voient virt-manager.
Ils sont indépendants de l'OS et de la solution bas niveau de virtualisation. Tu peux dire que c'est c'est libvirt centric :-)
Pour finir. Je ne pense pas que Xen c'est "le mal". Xen a été pionier, Xen c'est fabuleux.