>> 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.
dans quel partie de ma phrase tu vois que je dis que RedHat n'a pas le droit de fournir ce qu'il veut (KVM) ? donc il semble que le contexte t'echappes quelque peu; ici je ne fais que recapituler l'histoire de libvirt, et expliquant comment la lib est devenu pseudo multi-hypervisor.
> C'était dès l'origine une lib multi-hyperviseur.
non absolument pas. libvirt est sorti en decembre 2005 (KVM fin 2006 pour info), et a l'epoque se veut etre une lib d'abstraction de Xen. tu peux aller consulter les archives de la ML libvirt pour eclairer ta lanterne.
>> 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.
Non justement qemu n'est *pas* le probleme. la console n'a pas ete designe pour etre scriptable, et c'est tout a fait bien comme ca pour l'utilisation usuelle (i.e. interactive) de qemu. Par contre quand on veux changer l'utilisation du programme, on se donne les moyens de ses ambitions.
> Globalement je trouve rigolo ceux qui descendent une solution alors qu'il n'y a pratiquement rien d'autre...
Moi je trouve rigolo les gens qui justifie une solution mal faites parce que "c'est la seule solution" ... les gens de ielo prouvent ici que c'est possible de faire des trucs bien sans utiliser libvirt et que tout simplement, on obtient des resultats bien meilleurs (voir post sur la ML de niftyname et le poste d'un des staffs de ielo plus haut ..)
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.
> C'est comme ça que l'auteur de virtio a présenté son projet sur la liste de diffusion xen-devel d'ailleurs.
ca n'empeche que xen l'utilisera pas.
> Chez moi ça s'appelle une couche d'abstraction.
je parle pas de la couche d'abstraction, mais de l'affranchissement des limites.
> C'est rédigé du point de vue de la disponibilité dans le kernel (cité deux fois dans l'extrait) et ces patches n'y sont pas encore intégrés
a vraiment manque de bol pour toi la, le lien a rien a voir. je suppose que t'a pas vraiment lu; donc si un jour l'envie t'en prends, tu telechargera un kernel 2.6.25 (qui est officiellement sorti) et aller voir autour de VIRTIO_{NET,BLOCK,PCI,BALLOON}, et voir que tu peux avoir un domaine completement virtio'ise avec le kernel officiel.
la majorite de ce changelog c'est pour le support des nouvelles archs. le seul nouveau virtio device, c'est la VIRTIO_CLOCK
> En gros tu dis qu'ils ont raison, sauf pour certains matériels spécifiques, et dans ce cas ce n'est de toute façon pas aussi rapide que de la paravirtualisation
et on est loin de performance *genante* comme mentionne l'article.
> D'ailleurs le « draft IV » écrit par l'auteur de virtio parle également de « virtual I/O layer » et ne cite à aucun moment le terme paravirtualisation.
ca depend de quel cote on regarde. ca paravirtualise les IO par rapport a l'hote. et au final c'est le concept de paravirtualisation qui compte en rendant le guest amical au fait de tourner dans une VM.
> Non, contrairement aux autres systèmes qui passent par une couche intermédiaire pour traduire les instructions d'un processeur vers un autre. Mais quand on ne veut pas comprendre...
et ils utilisent quels processeurs au final ? les cpus de la machine hote ...
- XEN n'a jamais parle d'utiliser virtio.
- KVM est un hyperviseur et utilise _deja_ virtio (pas comme l'article suppose en mettant "supportera")
- libvirt n'est pas une couche d'abstractions permettant de s'affranchir des limitations des solutions. tout au plus une couche pour permettre de piloter les differentes solutions de facon relativement transparente.
- ESX n'etant pas un hyperviseur paravirtualise comme XEN; pas besoin de modifier l'OS pour que ca marche. (meme si ESX peut avoir des guests paravirtualises, et que xen peut faire tourner des OS non modifies a l'aide de HVM)
- perte de performance genante dans le cas des "machine virtuelle complete": completement faux: l'emulation de certaines cartes relativement amicales par rapport a la virtualisation (e1000 et scsi) permet aux guests d'avoir des bonnes performances meme si on atteint pas le maximum possible avec des drivers paravirtualises.
- le manque de mention de lguest (relativement modeste projet, mais inclus dans le kernel linux)
- virtio n'est pas un couche de "virtualisation des entrées/sorties" mais de *paravirtualisation* des entrees/sorties.
et plein de phrase sont ambigues au possible, par example:
- "l'émulation du processeur se faisant directement sur le processeur de la machine hôte" : contrairement aux autres systemes qui n'utilise pas les processeurs de la machine hote et utilise la magie pour fonctionner ?
le fait de travailler pour une des solutions de virtualisation presente dans l'article, me donne un certain avantage qd je dis que l'article est bourre d'erreurs. j'aurais pu pointer les erreurs (ce que j'ai essaye avant que templeet me bouffe mon commentaire avec une erreur SQL), j'aurai pu etre plus constructif, mais au final je pense que tout l'article presente tres mal les choses et aussi introduit des erreurs trop importantes pour que des correctifs "par dessus" soit suffisant.
Les lecteurs interesses ont mieux fait d'aller chercher les quelques bon articles deja existant sur le sujet (et c'est aussi pour ca que je ne suis pas motive a faire une depeche, quand la prose deja existante est probablement meilleur que ce que je pourrai faire)
> Nombre de message de ta part dans ce topic : 1. -> que de critique constructive, vonlonté d'éclaircissement itou...
>
> Donc a part dire "je travaille chez xen, ce qu'il dit c'est de la merde" , tu fais quelque chose dans ta vie ?
(je vois pas le rapport.)
donc parce que je participe pas a linuxfr, j'ai pas de vie ? c'est vraiment interessant ton point de vue.
XenEntreprise v4 (le dernier produit commercial de xensource) supporte le concept de pool avec un master et des slaves, mais il n'y a pas de support equivalent en opensource.
Le concept de pool est avant tout de l'administration de machine du clusters et de migration de VM; Xen (l'hypervisor) n'a aucune idee des pools.
[^] # 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.
>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.
dans quel partie de ma phrase tu vois que je dis que RedHat n'a pas le droit de fournir ce qu'il veut (KVM) ? donc il semble que le contexte t'echappes quelque peu; ici je ne fais que recapituler l'histoire de libvirt, et expliquant comment la lib est devenu pseudo multi-hypervisor.
> C'était dès l'origine une lib multi-hyperviseur.
non absolument pas. libvirt est sorti en decembre 2005 (KVM fin 2006 pour info), et a l'epoque se veut etre une lib d'abstraction de Xen. tu peux aller consulter les archives de la ML libvirt pour eclairer ta lanterne.
>> 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.
Non justement qemu n'est *pas* le probleme. la console n'a pas ete designe pour etre scriptable, et c'est tout a fait bien comme ca pour l'utilisation usuelle (i.e. interactive) de qemu. Par contre quand on veux changer l'utilisation du programme, on se donne les moyens de ses ambitions.
> Globalement je trouve rigolo ceux qui descendent une solution alors qu'il n'y a pratiquement rien d'autre...
Moi je trouve rigolo les gens qui justifie une solution mal faites parce que "c'est la seule solution" ... les gens de ielo prouvent ici que c'est possible de faire des trucs bien sans utiliser libvirt et que tout simplement, on obtient des resultats bien meilleurs (voir post sur la ML de niftyname et le poste d'un des staffs de ielo plus haut ..)
[^] # 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.
[^] # Re: stats
Posté par vincentxs . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 7.
http://kernelnewbies.org/Linux_2_6_26
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 1.
ca n'empeche que xen l'utilisera pas.
> Chez moi ça s'appelle une couche d'abstraction.
je parle pas de la couche d'abstraction, mais de l'affranchissement des limites.
> C'est rédigé du point de vue de la disponibilité dans le kernel (cité deux fois dans l'extrait) et ces patches n'y sont pas encore intégrés
a vraiment manque de bol pour toi la, le lien a rien a voir. je suppose que t'a pas vraiment lu; donc si un jour l'envie t'en prends, tu telechargera un kernel 2.6.25 (qui est officiellement sorti) et aller voir autour de VIRTIO_{NET,BLOCK,PCI,BALLOON}, et voir que tu peux avoir un domaine completement virtio'ise avec le kernel officiel.
la majorite de ce changelog c'est pour le support des nouvelles archs. le seul nouveau virtio device, c'est la VIRTIO_CLOCK
> En gros tu dis qu'ils ont raison, sauf pour certains matériels spécifiques, et dans ce cas ce n'est de toute façon pas aussi rapide que de la paravirtualisation
et on est loin de performance *genante* comme mentionne l'article.
> D'ailleurs le « draft IV » écrit par l'auteur de virtio parle également de « virtual I/O layer » et ne cite à aucun moment le terme paravirtualisation.
ca depend de quel cote on regarde. ca paravirtualise les IO par rapport a l'hote. et au final c'est le concept de paravirtualisation qui compte en rendant le guest amical au fait de tourner dans une VM.
> Non, contrairement aux autres systèmes qui passent par une couche intermédiaire pour traduire les instructions d'un processeur vers un autre. Mais quand on ne veut pas comprendre...
et ils utilisent quels processeurs au final ? les cpus de la machine hote ...
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 6.
- XEN n'a jamais parle d'utiliser virtio.
- KVM est un hyperviseur et utilise _deja_ virtio (pas comme l'article suppose en mettant "supportera")
- libvirt n'est pas une couche d'abstractions permettant de s'affranchir des limitations des solutions. tout au plus une couche pour permettre de piloter les differentes solutions de facon relativement transparente.
- ESX n'etant pas un hyperviseur paravirtualise comme XEN; pas besoin de modifier l'OS pour que ca marche. (meme si ESX peut avoir des guests paravirtualises, et que xen peut faire tourner des OS non modifies a l'aide de HVM)
- perte de performance genante dans le cas des "machine virtuelle complete": completement faux: l'emulation de certaines cartes relativement amicales par rapport a la virtualisation (e1000 et scsi) permet aux guests d'avoir des bonnes performances meme si on atteint pas le maximum possible avec des drivers paravirtualises.
- le manque de mention de lguest (relativement modeste projet, mais inclus dans le kernel linux)
- virtio n'est pas un couche de "virtualisation des entrées/sorties" mais de *paravirtualisation* des entrees/sorties.
et plein de phrase sont ambigues au possible, par example:
- "l'émulation du processeur se faisant directement sur le processeur de la machine hôte" : contrairement aux autres systemes qui n'utilise pas les processeurs de la machine hote et utilise la magie pour fonctionner ?
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 2.
Les lecteurs interesses ont mieux fait d'aller chercher les quelques bon articles deja existant sur le sujet (et c'est aussi pour ca que je ne suis pas motive a faire une depeche, quand la prose deja existante est probablement meilleur que ce que je pourrai faire)
> Nombre de message de ta part dans ce topic : 1. -> que de critique constructive, vonlonté d'éclaircissement itou...
>
> Donc a part dire "je travaille chez xen, ce qu'il dit c'est de la merde" , tu fais quelque chose dans ta vie ?
(je vois pas le rapport.)
donc parce que je participe pas a linuxfr, j'ai pas de vie ? c'est vraiment interessant ton point de vue.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 2.
faut etre realiste, l'article a pas ete ecrit par quelqu'un comprenant la virtualisation, ou qui a pris le temps de se documenter assez sur le sujet.
et pour repondre au premier post, on est tres loin d'un article de patrick_g.
(PS: je travaille a xensource)
[^] # Re: Xen VS VMWare ?
Posté par vincentxs . En réponse à la dépêche Citrix Systems Inc. achète la société XenSource Inc.. Évalué à 2.
Le concept de pool est avant tout de l'administration de machine du clusters et de migration de VM; Xen (l'hypervisor) n'a aucune idee des pools.
Disclaimer: je travaille pour XenSource.