> Mais pour d'autres projets, on ne porte pas. C'est toujours synchro avec la version upstream
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 Samuel Thibault (site web personnel) . En réponse au journal Fedora abandonne Xen. É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.