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).
Donc a la creation de la lib, on se retrouve avec un truc immonde basiquement faisant
un mapping presque complet des donnees disponibles par l'interface xend et en mettant du xml autour. 50% des trucs dispo dans xend sont soit tres specifique a Xen (domid, devid, ...), soit trop bas niveau pour etre utile dans une lib d'abstraction.
Seulement arrive KVM (et les autres solutions de virt), et redhat changeant de fusil d'epaule, par necessite se retrouve a adapter une lib mal abstraite au dessus de Xen, en une lib multi hypervisor.
Pour ajouter au post de entr0p1e ci dessus qui pointe plein de details tout a fait correct,
Quant a la contribution des gens de libvirt dans qemu/kvm elle est relativement minimal,
il se contente d'ajouter les fonctionnalites qu'ils ont besoin sans y reflechir enormement.
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.
Et si je ne m'abuse, les "multiples sorties graphiques simultanées" ont été developpé par Citrix.
[^] # Re: Libvirt ?
Posté par vincentxs . En réponse à la dépêche Première publication de la plate-forme libre de HaaS (Hardware as a service) NiftyName. Évalué à 0.
Donc a la creation de la lib, on se retrouve avec un truc immonde basiquement faisant
un mapping presque complet des donnees disponibles par l'interface xend et en mettant du xml autour. 50% des trucs dispo dans xend sont soit tres specifique a Xen (domid, devid, ...), soit trop bas niveau pour etre utile dans une lib d'abstraction.
Seulement arrive KVM (et les autres solutions de virt), et redhat changeant de fusil d'epaule, par necessite se retrouve a adapter une lib mal abstraite au dessus de Xen, en une lib multi hypervisor.
Pour ajouter au post de entr0p1e ci dessus qui pointe plein de details tout a fait correct,
Quant a la contribution des gens de libvirt dans qemu/kvm elle est relativement minimal,
il se contente d'ajouter les fonctionnalites qu'ils ont besoin sans y reflechir enormement.
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.
Et si je ne m'abuse, les "multiples sorties graphiques simultanées" ont été developpé par Citrix.