> je pense qu'un peu de notion d'histoire de libvirt ne ferait pas de mal; a la base libvirt ce n'est pas du tout une lib multi-hypervisor. a la base c'est la reponse redhat pour permettre de controller Xen (API haut niveau), pendant que d'autre essayait de mettre en place une solution native dans xend (a base de xmlrpc).
C'est vrai, mais dès l'origine libvirt était prévu pour être multi-hyperviseur.
> Seulement arrive KVM (et les autres solutions de virt), et redhat changeant de fusil d'epaule
Mouais... Red Hat propose à ses clients ce qu'il lui semble le mieux (dans le logiciel libre). Tout le monde ou presque va faire pareil où est déjà en train de le faire.
En passant, c'est aussi un choix upstream.
> en une lib multi hypervisor.
C'était dès l'origine une lib multi-hyperviseur.
> Quant a la contribution des gens de libvirt dans qemu/kvm elle est relativement minimal,
Je ne vois pas le problème. Les développeurs de libvirt développent libvirt. S'ils font plus, tant mieux.
> Par example les gens de libvirt se sont interfacé avec la console qemu qui n'est pas sensé etre scripté, mais est une interface humaine. Presque a chaque changement de messages d'erreurs ou de format, on se retrouve avec les gens de libvirt se plaignant que ca va tout casser.. au lieu d'avoir designe une "console" scriptable en parallele (retournant un format qui puisse etre parser) avec la console humaine.
Si tu veux critiquer qemu, critique qemu mais pas libvirt. Libvirt n'est pas responsable de tous les maux de la terre.
Globalement je trouve rigolo ceux qui descendent une solution alors qu'il n'y a pratiquement rien d'autre...
[^] # Re: Libvirt ?
Posté par IsNotGood . En réponse à la dépêche Première publication de la plate-forme libre de HaaS (Hardware as a service) NiftyName. Évalué à 2.
C'est vrai, mais dès l'origine libvirt était prévu pour être multi-hyperviseur.
> Seulement arrive KVM (et les autres solutions de virt), et redhat changeant de fusil d'epaule
Mouais... Red Hat propose à ses clients ce qu'il lui semble le mieux (dans le logiciel libre). Tout le monde ou presque va faire pareil où est déjà en train de le faire.
En passant, c'est aussi un choix upstream.
> en une lib multi hypervisor.
C'était dès l'origine une lib multi-hyperviseur.
> Quant a la contribution des gens de libvirt dans qemu/kvm elle est relativement minimal,
Je ne vois pas le problème. Les développeurs de libvirt développent libvirt. S'ils font plus, tant mieux.
> Par example les gens de libvirt se sont interfacé avec la console qemu qui n'est pas sensé etre scripté, mais est une interface humaine. Presque a chaque changement de messages d'erreurs ou de format, on se retrouve avec les gens de libvirt se plaignant que ca va tout casser.. au lieu d'avoir designe une "console" scriptable en parallele (retournant un format qui puisse etre parser) avec la console humaine.
Si tu veux critiquer qemu, critique qemu mais pas libvirt. Libvirt n'est pas responsable de tous les maux de la terre.
Globalement je trouve rigolo ceux qui descendent une solution alors qu'il n'y a pratiquement rien d'autre...