Xen n'est pas complètement abandonné pour F9 (la prchaine Fedora) car il y a encore une grosse demande pour Xen.
Par contre les efforts vont se concentrer sur paravirt_ops et grosso-modo ajouter Xen à paravirt_ops (je ne m'y connais pas assez pour donner plus d'info).
Plus ici :
http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
Perso, je voyais ça arriver plus tôt. Depuis longtemps Fedora/Red Hat se plaind du boulot de maintenir Xen.
Le projet pour F9 est jugé très ambitieux et demandera beaucoup de boulot :
Getting all this done for Fedora 9 is seriously ambitiousIl faut juger ça avec de la distance. Red Hat est depuis longtemps le plus gros contributeur à Linux (le noyau). Le désengagement aura des conséquences que je pense négative sur Xen à long terme. Mais il y aura des conséquences positives pour les autres solutions.
[...]
We do not intend to continue trying to rebase the kernel-xen in existing Fedora releases. It will be essentially important bug-fix mode only. This is neccessary to enable maximum resources to be focused on the critical Fedora 9 Xen work.
Pour RHEL (et ses clones) Red Hat fournit Xen pour RHEL 4 (client) et RHEL 5. Pour RHEL 6 (qui ne devrait probablement pas sortir avant une bonne année à mon avis) Xen sera supporté à minima et c'est paravirt_ops qui sera mis en avant.
Notons que Red Hat l'avait prévu depuis longtemps puisque Red Hat utilise libvirt http://libvirt.org/ (et virt-manager). Donc l'"abandon" de Xen se fera sans trop de douleur.
Tout ceci n'est pas une grosse surprise. M'enfin, ça sent de plus en plus le sapin pour Xen.
# euhhh
Posté par manatlan (site web personnel) . Évalué à 3.
le problème de xen n'est il pas ailleurs ...
est-ce que qqu'un ici a déjà réussi à faire, ou a vu tourner xen ? (dans le sens, est ce utilisable, simplement, out of the box)
(c'est naïf comme question, mais c'est vraiment pour savoir)
[^] # Re: euhhh
Posté par IsNotGood . Évalué à 2.
J'ai "réussi" à faire tourner Xen les doigts dans le nez. Idem pour KVM.
Xen a actuellement des fonctionnalités que n'ont pas les autres solutions. Mais ça devrait changer.
[^] # Re: euhhh
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: euhhh
Posté par IsNotGood . Évalué à 1.
Il parait que XenSource (ou Cytrix) que se consacre maintenant quasi exclusivement à Windows.
Ça sent le sapin pour Xen sous Linux au moins.
[^] # Re: euhhh
Posté par B16F4RV4RD1N . Évalué à 0.
Sinon Xen j'avais seulement pu l'utiliser "dehors de la boîte" lorsque j'avais testé le livecd, sinon chez moi j'avais trouvé cela très fastidieux (mais peut-être est-ce parce que je n'utilise pas fedora / RH), déjà il faut utiliser un noyau spécial, ensuite il n'y a pas d'interface graphique (sous Debian), enfin je crois que cela ne fait tourner que linux et pas windows, bref virtualbox fait aussi bien l'affaire. Après, je ne connais pas réellement la différence de performances (peut-être pour un serveur mutualisé xen ou similaire c'est plus intéressant), mais pour faire tourner windows ou linux en bureau (pour travailler sur mon livecd esclinux), je trouve virtualbox ou vmware très satisfaisant.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: euhhh
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Ensuite vmware n'est pas libre...
Enfin, Xen est bien plus performant car on est en mode paravirtualisé et non virtualisé. Les OS invité ne passe pas par exemple par un BIOS. Il n'y a pas de changement de contexte au niveau du microprocessuers. /a priori/, c'est plus sécurisé d'après cet article :
http://taviso.decsystem.org/virtsec.pdf
En gros, si mes souvenirs sont bons, l'OS invité n'accède pas au matériel (le bus PCI n'est pas virtualisé) et les échanges entre l'OS invité et le dom0 sont limités à un petit nombre d'appel qui sont bien écrit sous Xen.
[^] # Re: euhhh
Posté par patrick_g (site web personnel) . Évalué à 2.
Et l'alternative c'est KVM ?
[^] # Re: euhhh
Posté par M . Évalué à 2.
Cf l'avis d'un développeur redhat qui n'est pas tendre avec Xen : http://udrepper.livejournal.com/tag/virtualization
[^] # Re: euhhh
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Certes, la paravistualisation n'est pas la panacée mais il est /a priori/ plus difficile aujourd'hui de sortir d'un environnement paravirtualisé que virtualisé.
Dans l'avenir, on va aller vers un architecture matériel qui sera je l'espère virtualisable, mais par exemple, au niveau de la carte graphique, pour le moment, il n'y a rien à l'horizon.
Au niveau serveur, le système vserver s'améliore petit à petit et on va arriver au final à un modèle proche de Xen à mon avis.
[^] # Re: euhhh
Posté par thedidouille . Évalué à -1.
Si qq1 sait comment ça peut marcher, j'aimerais vraiment bien comprendre. à mon avis, il faut des drivers spéciaux dans les deux OS et un driver minimal dans l'hyperviseur (quoi de plus simple...). Surtout, à quoi ça sert ?
[^] # Re: euhhh
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
# Euh et les autres systèmes d'exploitation ?
Posté par zul (site web personnel) . Évalué à 3.
Perso, je trouve ca assez triste. Le design est globalement bon. Des armées de gens ont bossés dessus (et je ne parle pas de que Linux). NetBSD a un support xen2/xen3 x86/amd64, des gens ont bossé sur le support domU (dom0) pour OpenBSD. Pareil pour FreeBSD.
Et pan, un petit coup de politique, et tout disparait. Il va falloir subir la dictature linuxienne et faire du kvm (super le choix du nom en plus, y'a une interface qui s'appelle kvm sous *BSD depuis plus de 10 ans).
Quels sont les avantages de kvm par rapport à Xen ?
PS : Xen ca marche out of the box en soit. Après j'ai vu des tutos pour l'installation de Debian dans Xen c'etait pas joli, joli mais bon mauvais système -> changer système. Sous NetBSD, tu monte un cd x86 normale, et tu dis à xen de booter sur un noyau spéciale et c'est une install classique ...
PPS : qu'on me parle pas de la difficulté d'integration dans le système, un developpeur NetBSD l'a fait tout seul et n'a modifié aucune partie du systeme autre que "arch/sys/xen" (minus les bugs revelés par Xen).
[^] # Re: Euh et les autres systèmes d'exploitation ?
Posté par IsNotGood . Évalué à 2.
Regarde dans la lkml.
> Et pan, un petit coup de politique
Où tu vois un coup de politique ?
C'était quasi sûr que Xen n'allait plus être upstream. D'autres solutions (paravirt_ops, kvm,etc) sont/seront upstream tout simplement car meilleures que Xen. Il n'y a rien de politique ici.
Que Red Hat se retire aujourd'hui de Xen est peut-être politico-marketeux-commercialo-stratégique.
> et tout disparait
Rien ne disparait. En plus il est clairement annoncé la volonté de supporter les clients xen.
> Il va falloir subir la dictature linuxienne
Change de dictature et passe à celle de XenSource/Cytrix si c'est ton kiff.
En passant, dans l'annonce Cytrix du rachat de XenSource, il y a 10 fois le mot Windows et 0 fois le mot Linux (et évidemment encore moins BSD).
Quelle dictature alors qu'il y a du choix sous Linux ?
> kvm (super le choix du nom en plus, y'a une interface qui s'appelle kvm sous *BSD depuis plus de 10 ans)
C'est un détail.
*BSD aurait dû déposé le nom. Mais ce n'est pas fait (volantairement ou pas).
> PS : Xen ca marche out of the box en soit.
Les autres aussi, il n'y a qu'un petit retard en fonctionnalité qui va être vite rattrapé.
> PPS : qu'on me parle pas de la difficulté d'integration dans le système, un developpeur NetBSD l'a fait tout seul et n'a modifié aucune partie du systeme autre que "arch/sys/xen" (minus les bugs revelés par Xen).
Doués comme ils sont, ils n'auront aucune difficultée à passer à paravirt_ops.
Où est le problème alors ?
[^] # Re: Euh et les autres systèmes d'exploitation ?
Posté par zul (site web personnel) . Évalué à 3.
> Change de dictature et passe à celle de XenSource/Cytrix si c'est ton kiff.
En passant, dans l'annonce Cytrix du rachat de XenSource, il y a 10 fois le mot Windows et 0 fois le mot Linux (et évidemment encore moins BSD).
Quelle dictature alors qu'il y a du choix sous Linux ?
Toi pas comprendre ce que moi dire. Moi parler simplement. Linux choisir, les autres doivent se faire à ces choix. Si tu utilise Linux, ca te pose pas de problème. Les autres n'ont donc pas le droit de faire d'autres choix.
La différence entre Xen et kvm/paravirt_ops, c'est que l'un n'est pas Linux Centric et l'autre Si. D'ou la difficulté de porter l'un par rapport à l'autre. Et c'est surement pour ça que Xen n'a pas été retenu pour être inclus dans le mainstream.
Quand au nom kvm, ce n'est pas une question de propriété. Je dis juste que le choix aurait été plus heureux. Genre ne pas appeller deux choses différentes du même nom. Mais bon, pour ça, il faudrait regarder l'environnement extérieur.
Enfin c'est vrai que Linux n'est qu'Open Source dans l'esprit. On ne peut pas trop lui en demander...
[^] # Re: Euh et les autres systèmes d'exploitation ?
Posté par IsNotGood . Évalué à 1.
De ce que JE peux en dire (NB: j'ai déjà dit ne pas être un spécialiste du domaine).
Pour l'utilisateur final kvm n'est pas mieux que Xen.
Mais les développeurs trouvent que Xen c'est la "chianlie".
Tu peux toujours dire à juste titre que chez toi ça marche et ça roxe des ours, et que tu aimes Xen, mais si les développeurs veulent passer à autre chose et bien ils passeront à autre chose.
> Linux choisir, les autres doivent se faire à ces choix.
Moi ça pas comprendre.
> Les autres n'ont donc pas le droit de faire d'autres choix.
Moi ça pas comprendre.
> La différence entre Xen et kvm/paravirt_ops, c'est que l'un n'est pas Linux Centric et l'autre Si.
Et ext3 est linux centric, et la pile tcp/ip linux est linux centric, et selinux est linux centric, etc...
Je ne vois absolument pas où tu veux en venir.
Si tu veux faire toujours l'OS bidule sous Linux (avec la virtualisation), si t'as le hardware qui va bien, l'OS bidule n'a rien à connaitre de Linux. Sinon il y a la paravirtualisation dont l'implémentation Xen. Ben pour la partie "cliente", il y aura Xen dans paravirt_ops (c'est partiellement upstream). Donc ton OS bidule qui peut toujours sous Xen tournera sous Xen (pléonasme). Mais seulement la partie DomU sera Xen dans ce cas (le cas F9 par exemple).
> Et c'est surement pour ça que Xen n'a pas été retenu pour être inclus dans le mainstream.
C'est ton interprétation. Mais il y a aussi des arguments techniques à la non inclusion de Xen. Si paravirt_ops a été créé, ce n'est pas pour rien. Si Xen était fabuleux, même si XenSource ne contribue plus, il y aurait du monde pour maintenir Xen entre autre car des boites importantes en dépendante (Red Hat et Novell notamment dans le monde Linux).
> Enfin c'est vrai que Linux n'est qu'Open Source dans l'esprit.
J'ai les source de Linux et ils sont sous GPL. Ce n'est pas qu'une vue de l'esprit.
[^] # Re: Euh et les autres systèmes d'exploitation ?
Posté par IsNotGood . Évalué à 1.
"s/toujours/tourner/"
[^] # Re: Euh et les autres systèmes d'exploitation ?
Posté par kowalsky . Évalué à 3.
> Linux choisir, les autres doivent se faire à ces choix.
Moi ça pas comprendre.
> Les autres n'ont donc pas le droit de faire d'autres choix.
Moi ça pas comprendre.
http://netbsd.org
http://freebsd.org
http://openbsd.org
http://dragonflybsd.org
Il y a d'autre OS que linux, vraiment.
Et ce que tu, je l'espère, fais exprès de ne pas comprendre, c'est que
chez NetBSD, par exemple, il y a eu pleiiiiiiiiin de boulot, de code, de
communication, etc, autour de XEN.
Et si demain, les gens qui utilisent Linux tout le temps, decide que XEN,
c'est pas bien, mais qu'en fait un truc qui compile que sous Linux, c'est
mieux, ba les gens de NetBSD, ils vont pas dire 'Hourra', encore plein
de ligne à coder pour porter ça sous les 10 ou 15 archi reelement utilisé !
Ils aiment coder, tu verrait, ils font que ça ! mais je pense pas qu'ils
seraient content sur un coup comme ça...
[^] # Re: Euh et les autres systèmes d'exploitation ?
Posté par patrick_g (site web personnel) . Évalué à 1.
Visiblement cela n'a rien de politique.
Le lien a été donné plus haut mais je te le recolle : http://udrepper.livejournal.com/tag/virtualization
Drepper se base sur des considérations techniques pour dire que Xen c'est de la merde et il explique pourquoi kvm est mieux.
[^] # Re: Euh et les autres systèmes d'exploitation ?
Posté par zul (site web personnel) . Évalué à 6.
Drepper est un peu à GNU/Linux et à la GLIBC ce que Theo est à OpenBSD.Un leader / grand hacker peut-etre mais aussi un gros troll qui dit 'que le reste du monde' c'est mal.
Dans son premier article, il parle quand même de Xen pre v2, du futur hypothétique de XenSource ( j'aurai plus tendance à croire à un mec qui bosse pour XenSource que lui). Quand aux modifs de l'ensemble entre la v1 et la v2, on pourrait surement dire de même de Linux. Combien de changement entre 2.4 et 2.6. Linux est complètement broken by design ?
Sur ce thread, on a déjà parlé d'essayer de jouer avec la glibc sur autre chose que linux (cause perdue). Je ne parlerai pas de son refus d'intégrer strl{cat,cpy} ... tout ça parce que ce n'est pas lui qui les a imaginé (ah non, c'est parce que tous les développeurs savent exactement combien ils restent de place dans leur buffer (il devrait se rendre compte sur n'importe quel site référécant les failles de sécurité pour se rendre compte de cet état de fait ..).
Mr Drepper est un homme Linuxo-Linux qui n'en a rien à peter des autres systèmes libres disponibles. Qu'il soit convaincu que KVM soit une meilleur solution pour son problème (faire regner son système sur le monde :D), je n'en doute pas. Mais son argumentation me semble pas mal biaisé (entre les attaques sur des versions 'prehistoriques' de xen, et le futur hypothétique à la fois de XenSource, et de kvm).
Xen a un gros avantage dont il ne parle pas. Ca ne marche pas que sous Linux. Mais je pense qu'il s'en contrefout :). C'est la seule chose que j'ai pointé.
# ...
Posté par gaston . Évalué à 4.
En général c'est le moment ou qqn intervient pour dire "quand on sait pas de quoi on parle, on FERME SA G******", ce coup ci c'est moi.
Plutot que poser des jugements a l'emporte pièce sur des rumeurs utilisées par des marketeux fumeux, et tout voir du coté de Fedora, ouvre un peu yeux, regarde ce qu'il se passe en dehors de linux, lis un peu de code et de docs, et arrète de nous pourrir LinuxFr avec tes journaux et commentaires fedoralotrollesques du niveau de Gala/Voici.
Xen marche très bien sur des plateformes d'envergure (oui, mais c'est dans le monde réel, pas dans le monde ou il n'existe que RHEL....), et c'est loin de sentir le sapin pour eux.
voila, fallait que ca sorte, merci de votre attention.
[^] # Re: ...
Posté par iMil (site web personnel) . Évalué à 7.
[^] # Re: ...
Posté par IsNotGood . Évalué à 1.
> Xen marche très bien sur des plateformes d'envergure (oui, mais c'est dans le monde réel, pas dans le monde ou il n'existe que RHEL....), et c'est loin de sentir le sapin pour eux.
Quel puissant argumentaire. M'enfin, va savoir pourquoi, je ne suis pas convaincu.
En passant, Red Hat utilise énormement Xen. Ça a été LA feature de RHEL 5 (RHEL 5.1 est aussi principalement une mise à jour de la virtualisation). Que ça marche chez Red Hat ou dans ton monde réel sans Red Hat, ne m'empêche pas de penser que Xen est une voie sans avenir à long terme.
Tiens, dans mon monde (virtual selon toi) Red Hat va proposer RHEL pour Amazon EC2 (ça utilise Xen) :
http://www.redhat.com/about/news/prarchive/2007/amazon.html
M'enfin, ça ne concerne pas ton monde réel.
# Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 10.
Il y a une pléthore de solutions de virtualisation, et c'est _normal_ parce qu'elles ont chacune une approche différente, et du coup leurs utilisations différentes aussi:
- uml recompile simplement linux en tant que processus tout à fait ordinaire. Un des défauts est que le noyau guest est exposé à ses processus, ce qui pose des problèmes de sécurité. Il existe un patch pour ajouter au Linux hôte pour permettre à UML d'échapper à ce problème. Ça reste quand même rudement pratique pour faire du développement noyau Linux sans être administrateur système.
- qemu et vmware émulent une machine complète, on peut donc faire tourner n'importe quoi. Les performances peuvent être relativement bonnes grâce à l'utilisation de modules noyau qui permettent de laisser le code tourner en natif la plupart du temps (un while(1); ira donc aussi vite qu'en réel). Par contre, on constate un net ralentissement sur les opérations d'entrées/sorties.
- bochs émule tout et n'a pas d'accélérateur, il va donc plutôt lentement. Mais il a un très bon débogueur
- vserver ne fait pas tourner d'autre noyau, il divise "simplement" l'espace de pid des processus, ce qui permet donc de faire tourner plusieurs distributions avec le même noyau, ce qui permet d'excellentes performances (d'autant plus si l'on partage les fichiers entre les distributions), mais ce noyau étant partagé, s'il foire c'est tout qui foire.
- lguest est une solution voulue comme étant la plus simple possible pour faire de la virtualisation, mais elle est du coup limitée à Linux, et surtout, au même noyau: il n'est pas possible de faire tourner différents noyaux Linux.
- KVM utilise les fonctionnalités de virtualisation des processeurs récents (VMX, SVM, VT-D/I) pour émuler une machine complète de manière plus efficace que qemu et vmware. Pas besoin de rebooter la machine, il suffit de faire modprobe kvm et c'est parti.
- Xen utilise un hyperviseur le plus simple possible, boote ensuite un dom0 (Linux, Solaris ou NetBSD) qui s'occupe de gérer le matériel & co, puis on peut lancer des domU qui peuvent être des OS complètement différents. Si les OS lancés dans les domU sont para-virtualisés (c'est le cas de tous les Linux depuis 2.6.23), on obtient d'excellentes performances: le code s'exécute en natif, les entrées/sorties se font directement en relation avec les drivers dans dom0 (ce qui est éventuellement un tout petit peu plus lent que KVM, mais vraiment très peu). Si les OS lancés dans les domU ne sont pas para-virtualisés, il faut disposer d'une machine avec support VMX, SVM, VT-D/I. Le code s'exécute alors aussi en natif, mais dès qu'il touche au matériel, une exception est levée, et un qemu est utilisé dans dom0 pour émuler ledit matériel (il est en projet d'exécuter ce qemu directement dans un petit domU à côté du domU de l'OS, pour améliorer grandement les performances).
Bref, il y a le choix, et c'est normal: si on peut se permettre d'utiliser exactement le même Linux, lguest va bien. Sinon, il faut au moins KVM. Si on ne veut pas seulement du Linux, Xen est tout à fait logique. Oui, pour Xen il faut rebooter avec un hyperviseur, ce qui peut être embêtant. D'autres trouvent au contraire que c'est un plus: si le Linux du dom0 plante, l'hyperviseur peut éventuellement aider à savoir pourquoi, et ce genre de choses. De plus, en configurant bien, on peut avoir en quelque sorte plusieurs dom0, qui se partagent le support du matériel, des fois qu'un OS (ou même version d'OS) soit meilleur qu'un autre pour supporter telle ou telle carte PCI, et ce pour _aucun_ surcoût par rapport à la situation actuelle, et il n'y a pas besoin d'IOMMU (j'y reviens plus loin). Ce genre de scénario n'est pas du tout prévu par KVM.
> Au niveau serveur, le système vserver s'améliore petit à petit et on va arriver au final à un modèle proche de Xen à mon avis.
Techniquement, pas du tout, ce sont des approches très différentes.
Pour ce qui est des commentaires de Drepper, il faut savoir que c'est un gars qui est assez exclusivement focalisé sur les solutions Linuxo-Linux.
Pour ce qui est de l'intégration de Xen à Linux, elle a besoin de se faire de deux manières:
- domU, i.e. guest, i.e. pour faire tourner une distrib Linux en virtualisé avec un hyperviseur Xen. Ça, c'est intégré sur kernel.org depuis la version 2.6.23, les distribs n'auront plus besoin de s'en soucier.
- dom0, i.e. host, i.e. pour fournir le support d'administration & co de Xen. Ça c'est en cours, et au Xen Summit de cet automne, il en a justement été question.
> Du coup, si tu laisses un OS invité avoir accès au matériel via le BUS PCI, il est possible pour elle de prendre le contrôle de la machine physique !
Oui. Par contre, les constructeurs sont en train de développer des solutions à cela: IOMMU, qui permet d'isoler ce qu'un OS fait avec une carte.
> PPS : qu'on me parle pas de la difficulté d'integration dans le système, un developpeur NetBSD l'a fait tout seul et n'a modifié aucune partie du systeme autre que "arch/sys/xen" (minus les bugs revelés par Xen).
Tout à fait d'accord :)
> En passant, dans l'annonce Cytrix du rachat de XenSource, il y a 10 fois le mot Windows et 0 fois le mot Linux (et évidemment encore moins BSD).
> Il parait que XenSource (ou Cytrix) que se consacre maintenant quasi exclusivement à Windows.
Déjà, on dit "Citrix" ;)
Ensuite, il faut savoir que Citrix est très spécialisé dans la fourniture de solutions windows, ce n'est donc pas étonnant. Maintenant, acheter Xen permet de faire tourner ces windows (ou tout autre OS) sur du matos géré par Linux, ce n'est pas rien.
Maintenant, il est complètement faux que XenSource se consacre quasi exclusivement à Windows, même s'il est vrai que ça fait partie des demandes importantes (pas seulement de Citrix, aussi de la communauté). À noter, je ne me souviens pas avoir rencontré de gens de Microsoft au Xen Summit...
Histoire de résumer un peu la position de XenSource par rapport au libre (évoquée par Ian Pratt au Xen Summit): xen.org (hébergé par XenSource/Citrix) sert de plate-forme pour une communauté libre autour de l'hyperviseur Xen, pas seulement avec Linux, mais aussi avec Solaris, BSD, ou tout autre OS paravirtualisé (il y a des drivers libre pour windows en cours de développement)... Les corrections que XenSource fait en interne pour ses produits sont a priori reversées dans la version libre. Ensuite, chacun peut faire sa tambouille. XenSource, par exemple, produit ce qu'il faut pour une intégration en entreprise: GUI toute jolie pour lancer des domU, etc.
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
[^] # Re: Réponses en vrac
Posté par herodiade . Évalué à 5.
> (bien sûr, n'hésitez pas à demander toute précision)
Bon alors je ne vais pas me géner, tu semble si bien connaitre le sujet !, profitons-en ;)
Pense-tu qu'une des petites solutions « outsiders » comme Virtualbox, OpenVZ/Virtuozzo ou Parallels peut percer et changer la donne ? Et le gros travail fait sur les containers (je crois que la virtualisation des PIDs a été intégrée dans le 2.6.24, bientôt peut-être le réseau), ça pourrai favoriser une solution plutôt qu'une autre ?
Sur le plan « politique » ou marketing, j'ai aussi beaucoup de mal à comprendre la stratégie et les possibilités restantes pour Citrix. XenSource/Citrix semble coincé entre la solution Microsfto-microsoftienne à venir prochainement (Hyper-V/Viridian je crois, pas encore sortie) d'un coté (qui sera sans doute favorisée par les gens qui veulent un bon support officiel pour cet OS), vmware d'un autre coté (qui semble dominer totalement le marché, en termes de ventes aux entreprises, et comment lui piquer son marché ?), Xen sous Red Hat et SuSE de l'autre (qui bénéficient des développements libres de XenSource, mais vendent eux-même le support), et le grand potentiel de KVM sous Linux + le fait que les processeurs pour serveurs x86 auront tous à court terme le support HVM intégré, et enfin, la concurrence de libvirt/virt-manager et des divers outils libres pour l'administration de la virtualisation qui ne manqueront pas de se développer rapidement. Même le marché des serveurs Apple semble, si j'ai bien compris saturé et dominé par une autre solution (Parallels).
Alors, à moyen terme, que va pouvoir vendre XenSource/Citrix ?
(du support pour Xen sous Windows ? mais vmware et la virtualisation de MS sont mieux placés (pas pour des raisons techniques, mais...) - du support pour Xen sous Linux ? oui mais RH et SuSE le font aussi, et sont là encore, mieux placés - des outils d'administration ? oui mais libvirt et ses amis ne manqueront pas d'évoluer et d'être bien intégrés dans les distros...).
Et enfin : est-ce que XenSource/Citrix a vraiment intéret à ce que le support dom0 soit bien et rapidement intégré dans le noyau vanilla (ce qui signifie faciliter la tache aux concurrents que sont RH et SuSE, mais signifie aussi ne pas prendre plus de retard par rapport aux concurrents comme kvm) ?
PS : concernant le contenu du journal : je ne comprends absolument pas pourquoi Iznogood écrit (et même titre) « Fedora abandonne Xen », alors que la page qu'il cite en lien écrit noir sur blanc : « Since people seeem to use Xen, we have decided not to drop it ». Pour ce que j'ai compris du lien indiqué, les développeurs Fedora/RH ont simplement décidé de mettre le paquet sur une intégration de Xen de meilleure qualité pour Fedora 9 (pas étonnant, puisque cette Fedora servira de base pour la prochaine RHEL, on ne perds pas le nord...), en évitant de disperser en backports longs et inutiles, et en essayant de merger ce qu'ils peuvent dans le noyau standard (« hopefully even have a lot of this stuff merged in LKML »). Je n'appelerai pas ça « abandon », en ce qui me concerne. En outre, vu que de gros morceaux de Xen sont déjà mergés dans le noyau standard, que SuSE vends aussi du Xen (donc pas seulement RH), je vois mal comment Xen pourrait disparaitre, être abandonné ou « sentir le sapin ».
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
Pour tout dire, je ne connaissais que de nom ces solutions, c'est pourquoi je n'en ai pas parlé :)
VirtualBox est intéressant parce qu'il fournit une version libre de ce que VmWare fait: de la virtualisation complète. OpenVZ/Virtuozzo est la version étendue de lguest, je pense qu'elle a toutes ses chances en solution Linuxo/Linux. Je n'ai pas encore regardé Parallels.
> Et le gros travail fait sur les containers (je crois que la virtualisation des PIDs a été intégrée dans le 2.6.24, bientôt peut-être le réseau), ça pourrai favoriser une solution plutôt qu'une autre ?
Pour moi ce n'est ni plus ni moins que l'intégration dans Linux de Vserver :)
Ça ne favorise pas pour autant dans l'absolu cette solution, ça permet juste sa mise en ½uvre effective bien plus aisée.
> Alors, à moyen terme, que va pouvoir vendre XenSource/Citrix ?
Heu, ça, le marketting, désolé, ce n'est pas de mon ressort :)
L'impression que j'ai, c'est que XenSource pourra continuer à vendre des solutions toutes prêtes à l'emploi pour les entreprises.
> Et enfin : est-ce que XenSource/Citrix a vraiment intéret à ce que le support dom0 soit bien et rapidement intégré dans le noyau vanilla (ce qui signifie faciliter la tache aux concurrents que sont RH et SuSE, mais signifie aussi ne pas prendre plus de retard par rapport aux concurrents comme kvm) ?
En tout cas c'est la volonté clairement affichée au Xen Summit: asseoir la base de Xen pour rassembler des efforts potentiels dessus. À charge à XenSource de trouver son modèle économique ensuite.
En fait, l'achat de XenSource par Citrix tombe sans doute bien: oui, l'intégration dans linux permet à la concurrence de s'installer. Mais avec le potentiel de diffusion que Citrix apporte par son achat, ce n'est pas un problème je pense.
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 3.
[^] # Re: Réponses en vrac
Posté par IsNotGood . Évalué à 2.
> Pour ce qui est des commentaires de Drepper, il faut savoir que c'est un gars qui est assez exclusivement focalisé sur les solutions Linuxo-Linux.
La majorité des développeurs noyaux se consacre quasi exclusivement à un noyau. OK, Drepper ne se consacre pas qu'au noyau.
Enfin il faut mettre le contexte. Drepper bosse pour Red Hat qui fait du pognon dans le segment des serveurs "haut de gamme" et/ou critiques. (ça serait le même problème s'il bossait chez Novell). La virtualisation est utilisée principalement sur serveur et pour des raisons économiques. L'idée est en gros : ne pas avoir 50 serveurs, mais un seul avec 50 guests. Le niveau de performance devient alors très important. Si t'as une solutions générique mais qui tourne 20 % plus lentement, ça veut dire qu'un serveur ne peut avoir que 40 guests.
Par exemple :
http://www.redhatmagazine.com/2007/11/20/red-hat-enterprise-(...)
L'autre problème, est la nature de Linux. Linux est un OS qui évolue beaucoup et qui veut évoluer beaucoup. Donc une solutions qui est "lourdingue" n'est généralement pas appréciée.
> Ensuite, il faut savoir que Citrix est très spécialisé dans la fourniture de solutions windows, ce n'est donc pas étonnant.
Ce n'est pas étonnant. De plus pour le "marché" Linux, XenSource était face à Red Hat/Novell et n'avait, il me semble, aucune chance. Il ne faut pas en conclure que je pense que XenSource n'a que des bras cassés. Mais un distributeur peut fournir une solution bien intégrée ET avec du support/formation. Pour le client, il est évident que la virtualisation fait parti de l'OS et n'est pas un service ou logiciel à part.
Bref, no futur pour XenSource dans le marché Linux.
> Maintenant, acheter Xen permet de faire tourner ces windows (ou tout autre OS) sur du matos géré par Linux, ce n'est pas rien.
Pareil pour KVM/qemu depuis au moins 6 mois (si t'as du hardware assez récent et très commun aujourd'hui).
Exemple : l'installation de divers OS (dont Windows) sur F7 (test 2, même pas la version finale) :
http://www.phoronix.com/scan.php?page=article&item=656&a(...)
> Maintenant, il est complètement faux que XenSource se consacre quasi exclusivement à Windows
C'est sûrement exagéré. Mais XenSource (et Citrix) se consacre principalement à Windows et c'est normal.
Mais juste une petit exemple, il me semble que le patch Xen s'applique à Linux 2.6.16 seulement !
C'est Red Hat/Fedora qui a fait le portable pour 2.6.18 et les versions suivantes. Bien que Red Hat/Fedora ait fait ce boulot, XenSource reste collé à 2.6.16. Désolé, mais pour moi ce n'est pas normal. "Normal" qu'un autre face le boulot, mais pas normal que XenSource refuse de se synchroniser avec Linux upstream.
> À noter, je ne me souviens pas avoir rencontré de gens de Microsoft au Xen Summit...
Je n'ai pas voulu sous-entendre que Citrix était à la botte de MS.
[^] # Re: Réponses en vrac
Posté par IsNotGood . Évalué à 2.
Zut, c'est maintenant 2.6.18.
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 3.
Heu ben oui il est surtout censé s'occuper de la glibc :)
Le problème, c'est qu'il a des avis très tranchés sur les questions de glibc, et il se moque éperduement que la glibc puisse être utilisé avec d'autres noyaux que Linux par exemple, ou qu'on s'amuse à remplacer la libpthread par une libpthread de son cru. De même pour la virtualisation, c'est tout...
> Le niveau de performance devient alors très important. Si t'as une solutions générique mais qui tourne 20 % plus lentement, ça veut dire qu'un serveur ne peut avoir que 40 guests.
Heu, le lien que tu donnes indique plutôt 9% de ralentissement en mode paravirtualisé, mais bref, dans le cas d'une solution Linuxo/Linux, KVM est tout à fait adapté en effet.
> Donc une solutions qui est "lourdingue" n'est généralement pas appréciée.
Lourdingue en maintenance tu veux dire ? Oui, bien sûr, porter le patch Xen c'est lourdingue.
> Bref, no futur pour XenSource dans le marché Linux.
Dans le marché Linux/Linux, oui, et c'est normal: comme je l'ai dit, à chaque situation ses solutions. C'est justement un défaut commun que de vouloir que "sa" solution fasse tout y compris le café. Il vaut mieux se concentrer sur ce pour quoi on est bon.
Par contre, dans le contexte de l'embarqué Linux par exemple, Xen a tout à fait sa place, on a eu un exposé sur ARM au Summit.
> > Maintenant, acheter Xen permet de faire tourner ces windows (ou tout autre OS) sur du matos géré par Linux, ce n'est pas rien.
> Pareil pour KVM/qemu depuis au moins 6 mois (si t'as du hardware assez récent et très commun aujourd'hui).
Sauf que Citrix ne peut pas "acheter" les compétences KVM/qemu (Je disais bien "acheter Xen" pour Citrix). En ce moment, on est en train d'intégrer Xen aux solutions Citrix, ç'aurait été bien plus dur avec des solutions KVM/qemu. La différence avec Xen, c'est qu'on peut faire la même chose avec Solaris, NetBSD, ...
> Mais juste une petit exemple, il me semble que le patch Xen s'applique à Linux 2.6.16 seulement !
Faux, 2.6.18.8 ! ;)
Maintenant, troll à part, c'est un problème, oui, et ça justement a été évoqué au Xen Summit: plutôt que faire des efforts pour porter Xen sur les versions ultérieures (ce qu'a fait RedHat), il vaut mieux faire intégrer ça upstream, ce qui a été réalisé pour domU déjà, et est en cours pour dom0 (Non, XenSource ne refuse pas de se synchroniser avec upstream, c'est juste que la branche principale préfère rester avec un noyau connu pour être stable).
> > À noter, je ne me souviens pas avoir rencontré de gens de Microsoft au Xen Summit...
>
> Je n'ai pas voulu sous-entendre que Citrix était à la botte de MS.
Ce n'était pas ce que je voulais dire.
Je voulais dire que si XenSource/Citrix était vraiment focalisé sur Windows, il aurait été "normal" de voir pas mal apparaître Microsoft au Xen Summit. Cela n'a absolument pas été le cas.
[^] # Re: Réponses en vrac
Posté par IsNotGood . É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.
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
Quels autres projets ? Le problème ici c'est qu'on touche à pas mal de composants sensibles de Linux (MM notamment).
> Xen est un solution Xeno/Xen.
Et alors ?
> Pour la partie serveur (dom0), c'est 100 % Linux ou 100 % Windows etc. Ce n'est pas 50
> % Linux, 25 % BSD et 25 % Windows.
Heu, je ne suis pas sûr de comprendre. Tu parles d'un serveur donné, confier des droits dom0 à différents OS ? C'est justement un des axes de développement actuels: avoir des doms dédiés au support du matériel (ça accroit la sécurité en plus). L'idée pourrait être par exemple d'utiliser un BSD comme dom0 pour avoir un truc bien sécurisé, et un Linux en domDriver pour le support du matériel (ou éventuellement plusieurs domD si différentes versions marchent mieux pour les différents matériels utilisés).
Ce que Drepper dit ("they want to add the drivers back into the hypervisor", "have their own mini-OS in the hypervisor"), notamment, est complètement faux. L'utilisation de qemu pour faire l'émulation du matériel est l'exemple même qui montre qu'il n'est pas question de réimplémenter quoi que ce soit.
> 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).
"il" = ?
> 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 :-)
Oui, ça c'est très bien, moi je parle du morceau avant:
Linux ->Xen->libvirt->virt-manager
Solaris->OpenVZ->libvirt->virt-manager
Linux ->KVM->libvirt->virt-manager
mais aussi
Solaris ->Xen->libvirt->virt-manager
FreeBSD ->Xen->libvirt->virt-manager
...
KVM reste un bout de code qui n'est pas prévu pour être utilisé pour d'autres noyaux.
[^] # Re: Réponses en vrac
Posté par IsNotGood . Évalué à 1.
>
> Et alors ?
Rien.
> "il" = ?
Linux. Mais oublions ça, c'est la politique MS et ça n'a finalement pas grand chose à voir avec Xen.
> mais aussi
> Solaris ->Xen->libvirt->virt-manager
> FreeBSD ->Xen->libvirt->virt-manager
Oui. Et ?
Que pour XenSource il soit important que Xen tourne partout, je comprend très très bien. Que XenSource trouve ça super cool, je comprend ça très très bien.
Mais moi, utilisateur Linux et notamment de distributions communautaire, j'en ai rien à foutre que le dom0 tourne partout.
Mets toi à la place de Red Hat.
Tu crois que Red Hat doit rester à Xen car Xen (dom0) tourne sous Solaris, Windows, etc ?
Ça apporte quoi aux clients de Red Hat ?
Rien.
Donc je ne vois pas où tu veux en venir. Dis que Xen fait la migration de machine virtuelle, etc ce que ne fait pas KVM encore, etc. Ça se sont de bons arguments. Mais rester à Xen seulement car Xen (dom0) tourne sous d'autres OS est "ridicule". Sinon en suivant ta logique on pourrait aussi abandonner Linux pour Windows car Windows est dans 97 % des PC.
> KVM reste un bout de code qui n'est pas prévu pour être utilisé pour d'autres noyaux.
Et alors ? C'est pareil pour la pile tcp/ip, etc. Faut-il abandonner les meilleurs solutions pour l'utilisateur et se précipiter sur les plus portables seulement car c'est portable ?
Désolé, mais c'est ridicule. Et que Linux ait sa propre pile tcp/ip qu'on ne trouve dans aucun autre OS n'a jamais été un problème, n'a jamais pénalisé les utilisateurs de Linux (ni d'autres OS).
Tu (peut-être moi aussi) fais une confusion entre implémentation, portabilité, intéropérabilité. Qu'on trouve un navigateur web sur tous les OS est important. Que ça ne soit pas la même implémentation est sans importance (si les normes sont respectées).
Il y a-t-il un problème d'intéropérabilité entre un OS qui tourne sous Xen et un autre qui tourne sous KVM ? Non. Donc on peut prendre la meilleur solution et basta.
En passant KVM n'a pas l'ancienneté de Xen. Xen a commencé en étant qu'un "bout de code".
> KVM reste un bout de code qui n'est pas prévu pour être utilisé pour d'autres noyaux.
Idem pour la pile tcp/ip, la gestion mémoire, etc. Que ça ne soit pas prévu pour être utilisé par d'autres noyaux n'indique pas que c'est "pourri".
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
> Tu crois que Red Hat doit rester à Xen car Xen (dom0) tourne sous Solaris, Windows, etc ? Ça apporte quoi aux clients de Red Hat ?
Je suis d'accord (je répète), RedHat peut très bien se contenter de KVM, je n'ai rien contre ça.
> Mais moi, utilisateur Linux et notamment de distributions communautaire, j'en ai rien à foutre que le dom0 tourne partout.
Si tu n'utilises que Linux et que tu es content du support qu'il fournit, KVM ira très bien, oui.
> Dis que Xen fait la migration de machine virtuelle, etc ce que ne fait pas KVM encore, etc. Ça ce sont de bons arguments.
Non, ce ne sont que des arguments actuels, et quand KVM sera prêt, ils tomberont.
> rester à Xen seulement car Xen (dom0) tourne sous d'autres OS est "ridicule".
Non. C'est se cantonner à Linux qui peut être ridicule. Il est notoire que certains BSD sont plus sûrs, donc avoir une solution qui permet de faire coopérer cette sûreté (en dom0) avec le support du matériel de Linux (en domD) a tout à fait du sens, et KVM, _à la base_, n'est pas prévu pour ça, tandis que Xen, oui.
Encore une fois, ceci n'a effectivement rien à voir avec RedHat, donc je suis éventuellement hors-sujet. J'essaie juste d'expliquer dans quel cadre Xen se situe.
> Sinon en suivant ta logique on pourrait aussi abandonner Linux pour Windows car Windows est dans 97 % des PC.
Dans ma logique, on pourrait utiliser Windows comme source non-sûre de drivers, i.e. on le met dans son domD et on passe par lui pour gérer le matériel sans pour autant lui faire confiance pour le reste. C'est ce genre de choses que les gens de l'embarqué sont en train de faire.
[^] # Re: Réponses en vrac
Posté par IsNotGood . Évalué à 1.
Mais oui. Surtout pour dom0 où il n'y a rien qui tourne ça peut être ttrrèèss pratique.
> avoir une solution qui permet de faire coopérer cette sûreté (en dom0) avec le support du matériel de Linux (en domD) a tout à fait du sens, et KVM, _à la base_, n'est pas prévu pour ça, tandis que Xen, oui.
Admettons. On peut aussi ajouter une pile tcp/ip qu'on peut changer à la volée et l'avoir en user-mode, ou un dom0 qui construit une OS en premant des bouts de divers OS en domU et en faisant communiquer le tout (OK c'est du délire).
Sur le papier tout ça c'est très bien (comme hurd). Dans la pratique en général ça sucks. En plus c'est très "proprio-friendly". Avoir un OS libre mais qui demande de communiquer avec un OS proprio via un dom0 (libre ou pas) pour avoir tel ou tel drivers, ce n'est pas ma tasse de thé. OK, au cas par cas, ça peut être utile. Indéniablement.
Je vois bien l'idée générale, elle a sa pertinance, mais ce n'est pas ma tasse de thé. C'est faire une sorte de mini-OS ou micro-noyau. Plein de gens croit en "ces trucs". Je n'en fais pas parti. Et désolé, je ne suis pas techniquement suffisament pointu pour faire un argumentaire percutant. Je trouve ces architectures trop contraignantes notamment quand ça concerne du bas niveau où les performances (et donc aussi la souplesse) sont critiques et trop niche à proprio. Si petit à petit on devient de plus en plus dépendant de drivers ou autre qui sont dans Windows, le libre n'aura pas beaucoup avancé.
M'enfin, si BSD ou autres peuvent, par exemple, accéder au driver de Linux ou Windows avec ce type de technologie, c'est un gros tant mieux, un bravo. Évidemment.
> J'essaie juste d'expliquer dans quel cadre Xen se situe.
Compris.
Ceci dit, Xen c'est TRÈS BIEN. Sisi, je le pense. L'apport de Xen à Linux a été énorme et sur de nombreux plans.
En aucun cas je ne veux inciter les gens à quitter Xen. C'est aujourd'hui (et peut-être demain aussi) ce qui se fait de mieux sous Linux pour la virtualisation. Les autres solutions ont un potentiel qui n'est pas encore pleinement traduit dans la pratique.
Mais il y a un "mouvement de fond" dans le cas de Linux et au niveau des développeurs (pas des utilisateurs qui sont satisfaits de Xen). Mouvement qui est d'accentuer les effort sur paravirt_ops/KVM/qemu. C'est mon impression, elle est confirmée par Red Hat. M'enfin, Red Hat se plante peut-être. Peut-être que les solutions "alternatives" à Xen ne rattraperont jamais Xen, peut-être, etc.
L'histoire jugera.
Longue vie à Xen.
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
OK :)
> M'enfin, si BSD ou autres peuvent, par exemple, accéder au driver de Linux ou Windows avec ce type de technologie, c'est un gros tant mieux, un bravo. Évidemment.
C'est bien pour ça que j'ai porté GNU Mach pour Xen ;)
> Peut-être que les solutions "alternatives" à Xen ne rattraperont jamais Xen, peut-être, etc.
Justement, pour moi ça n'a pas de sens: les autres solutions prennent d'autres chemins et c'est normal. Il y a des fonctionnalités qui font qu'on peut effectivement comparer la maturité des solutions, mais à maturité complète a priori chacune des solutions libres existantes a son intérêt propre pour un certain type d'utilisation, et il n'y a plus vraiment lieu de comparer.
[^] # Re: Réponses en vrac
Posté par zul (site web personnel) . Évalué à 3.
Continuez de faire ce boulot formidable et merci :).
[^] # Re: Réponses en vrac
Posté par IsNotGood . Évalué à 2.
Tu vas vite en besogne. Red Hat a comparé par exemple et maintenant Xen est mis dans la catégorie "prochainement obsolète" si je peux permettre.
OK KVM et Xen n'ont pas les même objectifs. KVM ne va pas remplacer partout Xen et même que sous Linux. Mais il faut se méfier des effets boule de neige.
Il n'y aurait pas Red Hat, probablement qu'il serait impossible d'utiliser Xen sous F8 (ou alors ça serait du sport). Par exemple car XenSource est resté à 2.6.18 et F8 est sorti avec un 2.6.23 et utilise libata par défaut. Demain il n'y aura pas Red Hat pour faire tourner Xen sous F9, idem pour RHEL 6, etc. L'effort que faisait Red Hat profitait aux autres distributions. Mais possible que demain il n'y ait plus de Xen dans Ubuntu, etc.
Pour peu que Novell se désengage de Xen et les carottes sont quasi définitivement cuites.
KVM aura donc été un redoutable concurrent de Xen. Si c'est un concurrent, alors on peut comparer. Xen sera passé de solution dominante et de référence sous Linux pour les serveurs à presque rien.
Que XenSource ou Citrix en est rien à foutre d'abandonner ce marché à KVM est une autre histoire. Une histoire de business plan probablement (et assez compréhensible).
[^] # Re: Réponses en vrac
Posté par kowalsky . Évalué à 5.
Il n'y aurait pas Red Hat, probablement qu'il serait impossible d'utiliser Xen sous F8 (ou alors ça serait du sport).
Mais on s'en fou un peu je trouve...
Pourquoi utiliser fedora pour faire ça ?
Vraiment, Fedora, c'est clickaconvitoussa, j'adore, mais j'irai
pas mettre un server 'critique' sous fedora...
[^] # Re: Réponses en vrac
Posté par imalip . Évalué à 10.
Ben, en meme temps, c'est IsNotGood, quoi...
[^] # Re: Réponses en vrac
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.