Ceci est une première version qui ne gère pas encore de redondance active multi-site, bien que l'ensemble des composants y soit préparé.
L'architecture se base sur un ensemble de webservices XML-RPC (SSL) documentés permettant de développer ses propres outils de gestion. En outre, deux clients (console et GTK) s'appuyant sur l'API permettent déjà de manipuler l'ensemble des services.
Cette version 1.0.0 a les fonctionnalités suivantes :
- Machines virtuelles (sur base KVM, multi processeurs, x86-64, VNC, etc.)
- Stockage (privés, publics, clonage, partage entre instances)
- Réseau (adressage public, support IPv6, réseaux virtuels privés, interfaces multiples)
- Gestion des utilisateurs/clients, permissions, rôles, etc.
Une plate-forme de test est proposée par IELO/Lost-Oasis, elle vous permet dès aujourd'hui de créer des utilisateurs de tests ainsi que des services en conditions réelles.
Nous comptons sur vos remarques, propositions et contributions afin de nous permettre d'améliorer le projet et de le porter au plus haut niveau.
Aller plus loin
- Site du projet NiftyName (39 clics)
- Captures d'écrans du client gtk (37 clics)
- Doc client console (6 clics)
- Doc client console (13 clics)
- Lost Oasis (14 clics)
# rapport avec EC2 et Azure ?
Posté par TImaniac (site web personnel) . Évalué à 4.
De ma compréhension, les Amazon EC2 et Azure font justement abstraction du hardware pour ne plus poser de questions à l'utilisateur du style : "combien de RAM ?" "combien de CPU ?". Ces plateformes proposent à la place d'acheter des ressources en fonction de l'utilisation réelle qu'on en fait (tu achètes de l'utilisation CPU, de l'utilisation mémoire, etc.), c'est au fournisseur d'adapter sa plateforme matériel aux besoins qui deviennent dynamique.
C'est le principe même des "clouds" : tu balances ton appli dans le nuage, et tu te préocupes pas du hardware, tout l'inverse du concept de "HaaS".
Bref pour moi ca peut être cool comme base pour un hébergeur de plateforme mutualisé, mais ca n'a pas beaucoup de rapport avec ce qu'apporte EC2 et Azure d'un point de vue services fournies aux clients.
[^] # Re: rapport avec EC2 et Azure ?
Posté par Bertrand Yvain . Évalué à 3.
D'après mon expérience (avec EC2, du moins) la notion de machine virtuelle est fondamentale : http://aws.amazon.com/ec2/#instance
Quant à l'attribution automatique de ressources en fonction des besoins, ce n'est pas encore dans NiftyName, mais ça va venir.
[^] # Re: rapport avec EC2 et Azure ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Quelques questions :
- une application peut-elle toute seule instancier de nouvelle vm pour monter en charge ?
- peut-on "augmenter" en live les capacité d'une VM ?
- une vm est-elle "mappée" sur une machine physique ou peut elle tourner sur plusieurs noeud à la fois (est-ce une véritable abstraction de la notion hardware ou une simple abstraction d'une machine physique précise) ?
- quid de la redondance, de la sécurité, du load-balancing ?
[^] # Re: rapport avec EC2 et Azure ?
Posté par Bertrand Yvain . Évalué à 4.
La modification à chaud d'une machine virtuelle est limitée par les capacités de QEMU : ajout/retrait de volumes de stockages pour l'instant. Cela ne fait pas beaucoup de sens de gérer la modification des processeurs et de la mémoire à chaud car le support par le guest est loin d'être généralisé.
Oui, une VM est instanciée sur un nœud. La migration à chaud est cependant supportée.
La redondance intrasite du stockage est déjà implémentée. Les scenarii de redondance intersite sont esquissés mais il y a encore beaucoup de code à faire. En matière de sécurité, cela dépendra surtout des OS guest, mais les précautions ont été prises pour éviter tout type de spoofing sur les vlans publics (notamment avec ebtables). Pour le load-balancing, cela sera géré par les nœud d'accès au réseau, avec LVS sans doute.
Si vous êtes intéressés par ces aspects de haute disponibilité et allocation dynamique de ressources, essentiels pour les phases à venir du projet, je vous invite à participer.
[^] # Re: rapport avec EC2 et Azure ?
Posté par IsNotGood . Évalué à 2.
EC2 n'est qu'un service parmis d'autres de AWS (Amazon Web Service). C'est seulement un fournisseur de cpu/ram/disque.
> - une application peut-elle toute seule instancier de nouvelle vm pour monter en charge ?
Oui, mais en général on ne le fait pas avec une instance EC2. On le fait "chez soi", à distance (histoire aussi de conserver les clés d'accès au chaud).
> - peut-on "augmenter" en live les capacité d'une VM ?
Pour ec2 non. Mais c'est un faux problème si on a bien compris la philosophie d'ec2 et fait les développements en accord. En gros si le clustering est déjà prévu.
Si on a bien fait le boulot, on peut créer une instance rapidement (une instance plus puissante si on veut pour couper l'ancienne).
> - une vm est-elle "mappée" sur une machine physique ou peut elle tourner sur plusieurs noeud à la fois [...]
> - quid de la redondance, de la sécurité, du load-balancing ?
Pour la redondance amazon à plusieurs sites. On peut choisir entre le groupe US et Europe.
Ça ne fait pas de clustering ou de la haute disponibilité. Mais on peut utiliser des outils tiers pour le faire. ec2 ne fournit que du cpu/ram pour des machines virtuelle. C'est un service bas-niveau d'une certaine manière.
Red Hat avait fait une démonstration de RHEL MRG assez impressionnante qui crée à la volée des instances ec2 pour répartir la charge. Bref, ce n'est pas le boulot d'ec2 mais d'autres outils.
Ec2 fait partit de AWS (Amazon Web Service) :
http://aws.amazon.com/
Notons que s3 (stokage illimité) fournit la redondance et, comme ec2, a une garantit de service.
Désolé, mais AWS c'est mieux qu'Azure pour des besoins spécifiques. On peut y utiliser son propre OS (petit hic, le choix des noyaux est limité car il doit être validé par Amazon).
Enfin, il n'y a pas vraiment la "cloud trap" que décrit à juste titre RMS. Ce sont des services de bas-niveau et ne sont pas liés à un language ou techno spécifique. On peut utiliser l'OS qu'on veut (Linux et même sa propre distrib, Solaris, Windows, etc), le serveur web qu'on veut, etc.
En tout cas pour EC2 ce n'est pas un problème. Pour s3, on peut l'utiliser comme un FS, donc il suffit d'utiliser un autre FS. Tous les services ont une api bien définie, s'il faut un concurrent car Amazon déconne, des alternatives compatibles existeront.
Azure "emprisonne" dans une solution. On peut peut-être le dire de AWS, mais 50 fois moins.
[^] # Re: rapport avec EC2 et Azure ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Concernant le troll Azure/EC2, effectivement Azure enferme dans un modèle donné mais techniquement le modèle est beaucoup plus séduisant et novateur à mon sens : ca se place à un niveau d'abstraction supérieur.
[^] # Re: rapport avec EC2 et Azure ?
Posté par IsNotGood . Évalué à 2.
J'avais l'impression que tu ne connaissais pas aws. Bizarre, j'étais resté sur l'impression de ton premier commentaire.
> le modèle est beaucoup plus séduisant
C'est séduisant ça ? => http://channel9.msdn.com/pdc2008/ES01/
Le peu que j'ai regardé d'Azure était l'"enfer". Par exemple il y avait une vidéo sur comment configurer un poste pour utiliser Azure et c'était passablement compliqué.
L'excuse : c'est du beta.
Es-ce un truc pour développeur ?
> ca se place à un niveau d'abstraction supérieur.
Je me méfis beaucoup de MS, mais il n'empêche qu'ici je crois qu'Amazon n'a pas de soucis à se faire...
[^] # Re: rapport avec EC2 et Azure ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Oué bah entre le première commentaire et le 2ème je me suis renseigné, mais merci pour tes précisions quand même :)
Es-ce un truc pour développeur ?
Bah oué. Tout ce qui est dispo, c'est un SDK.
Mais bon ca y'a pas de miracle hein, faut attaquer des API toussa, c'est pas "simple" à utiliser.
# De près
Posté par Philippe M (site web personnel) . Évalué à 1.
Je vais suivre ce projet de près car pour le moment je commence à me documenter sur le sujet de la virtualisation mais en gros c'est le foutoir, il y a des briques éparpillées sur différents projets et le lien entre les deux n'est pas forcement des plus simple pour un non expert en virtualisation.
Born to Kill EndUser !
# Libvirt ?
Posté par ldng . Évalué à 1.
Sinon ça serait dommage de ne pas en profiter vu que c'est en passe
de devenir le standard GNU/Linux en matière de gestion de MV.
http://et.redhat.com/page/Main_Page
[^] # Re: Libvirt ?
Posté par Bertrand Yvain . Évalué à 2.
[^] # Re: Libvirt ?
Posté par Yann_Hamon . Évalué à 4.
De plus les frontends a libvirt fleurissent: virtmanager, convirt, virsh, ...
Peux-tu développer sur les problemes en environnement de production?
[^] # Re: Libvirt ?
Posté par Bertrand Yvain . Évalué à 1.
Comme je te répondais sur une de nos ML (http://lists.src.ielo.net/pipermail/niftyname-users/2009-March/000005.html), le principale problème que nous avons rencontré en utilisant libvirt est que libvirtd ne peut contrôle que ses processus fils (par héritage de file descriptors si je me souviens bien). Si, pour une raison ou pour une autre, libvirtd meurt (crash, restart, etc) les machines virtuelles deviennent incontrôlables, à moins de les tuer (méchamment, grrr) et de les relancer. En terme de gestion, c'est beaucoup trop pénalisant.
[^] # Re: Libvirt ?
Posté par IsNotGood . Évalué à 2.
J'ai déjà vu ce reproche plus d'une fois.
Peut-être pour "piloter" qemu ? Comment on fait pour demander un shutdown qui sera récupéré par la machine virtuelle sinon ?
Peut-être aussi quand qemu et le noyau supportera l'ajout à la volée de mémoire / cpu? Peut-être pour la migration de machine virtuel ?
Bref, je ne sais pas vraiment, mais j'ai du mal à croire que Red Hat ait laissé cette faiblesse évidente sans bonne raison.
> En terme de gestion, c'est beaucoup trop pénalisant.
Red Hat ne semble pas avoir cet avis. M'enfin, Red Hat ayant fait libvirt...
Red Hat fait Ovirt qui utilisera libvirt :
http://ovirt.org/
La lecture de la doc vous donnera peut-être des idées.
Ovirt sera dans une offre de Red Hat à terme :
http://www.redhat.com/virtualization-strategy/
Ça sera probablement "Red Hat Enterprise Virtualization Manager for Servers" et "Red Hat Enterprise Virtualization Hypervisor".
J'ai survolé la doc, c'est très intéressant.
J'ai bien vu les paquets pour la partie client, mais pour la partie serveur ?
J'ai raté quelque chose ou le serveur est "proprio" ?
[^] # Re: Libvirt ?
Posté par IsNotGood . Évalué à 2.
Ooops, c'est libre.
J'ai raté ces liens :
http://src.ielo.net/wiki/zinn/
http://src.ielo.net/wiki/sinn/
[^] # Re: Libvirt ?
Posté par herodiade . Évalué à 2.
> environnement de production. De plus, libvirt supporte principalement Xen,
> que nous avons écarté aussi, trouvant KVM plus prometteur.
Ca c'est balot, parce qu'en ce moment, tout converge vers libvirt. RH emploi du beau linge pour travailler dessus, mais c'est aussi le seul gestionnaire de vm descent des dernières Debian, ... bref ce n'est plus l'affaire de quelques mois avant que libvirt soit l'outil de base/quasi standard pour les sysadmins. Autant dire que les autres solutions resteront... très confidentielles.
D'autre part les devs de libvirt contribuent fortement à Qemu/KVM (et un peu à Xen) : ce sont donc eux qui infléchirons la direction qui leur convient en ce qui concerne la gestion ; ils ont déjà implémenté le support d'auth par certificat X.509 sur le VNC de Qemu, ainsi que le support des multiples sorties graphiques simultanées, de l'auth SASL, ils travaillent sur le design de l'interface stdio de Qemu, l'intégration avec func (un projet RH aussi), FreeIPA, Cobbler, Puppet, ...
Un peu de concurrence et d'émulation ne feront pas de mal, mais j'ai l'impression que c'est une cause perdue d'avance :(
[^] # Re: Libvirt ?
Posté par entr0p1e . Évalué à 2.
>> environnement de production. De plus, libvirt supporte principalement Xen,
>> que nous avons écarté aussi, trouvant KVM plus prometteur.
>
>Ca c'est balot, parce qu'en ce moment, tout converge vers libvirt. RH emploi du beau
>linge pour travailler dessus, mais c'est aussi le seul gestionnaire de vm descent des
>dernières Debian, ... bref ce n'est plus l'affaire de quelques mois avant que libvirt
>soit l'outil de base/quasi standard pour les sysadmins. Autant dire que les autres
>solutions resteront... très confidentielles.
Le fait que cela soit repandu ou standard ne prejuge en rien de sa qualite.
Je suis rassure que les gens de Ielo aient ecarte libvirt, ca montre qu'ils savent voir au dela du hype.
La grande force de libvirt est effectivement d'etre capable de s'interfacer avec plusieurs plateformes de virtualisation. C'etait une piece importante de la strategie de RH et lui a permis de changer de solution de virtualisation sous-jacente (de xen a kvm).
Mais cela reste amha une usine a gaz fragile qui n'exploite que le plus petit commun denominateur. Un design clean a partir de zero pour un produit qui ne tente pas d'utiliser plusieurs hyperviseurs ne me parait pas idiot. A remarquer qu'il y a des outils simples fait par des admins pour des admins qui marchent bien (genre kvmctl de finntux).
>D'autre part les devs de libvirt contribuent fortement à Qemu/KVM (et un peu à Xen)
> : ce sont donc eux qui infléchirons la direction qui leur convient en ce qui concerne
>la gestion ; ils ont déjà implémenté le support d'auth par certificat X.509 sur le VNC
>de Qemu, ainsi que le support des multiples sorties graphiques simultanées, de
>l'auth SASL, ils travaillent sur le design de l'interface stdio de Qemu, l'intégration
>avec func (un projet RH aussi), FreeIPA, Cobbler, Puppet, ...
C'est vrai que le groupe Emerging Technologies de RH contribue pas mal a Qemu.
Cela dit, comme le nom de leur groupe l'indique, ce sont surtout des gens qui font des prototypes qui passent ensuite souvent en prod tels quels (voir les ProtoTry de http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns ). Ce faisant, ils ont tendance a privilegier le quick and dirty et non un design propre/sain.
Un exemple est le fait qu'ils aient choisis de lancer tout en root, ou encore de se mapper sur la console qemu plutot que de pousser dans qemu une lib qui aurait permis de s'interfacer de facon propre et robuste (avec bindings dans plusieurs langages).
Il est dommage egalement qu'ils n'aient pas commence par rajouter l'auth sasl/pam avant de mettre en place l'usine a gaz pour les certificats et les changements de mots de passe.
Cela dit, il aurait ete plus fute de coder un broker de connections vnc qui effectue le controle/l'authentification en amont de qemu, sur la base de "user/group policies", via sasl/pam. Cela aurait permis d'avoir un acces sur un port unique pour toutes les vms situees sur une machine, et de permettre l'authentification dynamique contre toutes sortes de backends.
Alors, oui, ils contribuent, mais leurs choix ne sont pas forcement les meilleurs.
D'autre part, ils n'ont pas la main-mise sur qemu (ils n'ont meme pas d'acces en ecriture au repo pour l'instant) donc rien n'empeche les gens de Ielo/LO ou des contributeurs externes de rajouter des fonctionnalites.
>Un peu de concurrence et d'émulation ne feront pas de mal, mais j'ai l'impression
>que c'est une cause perdue d'avance :(
Non pas forcement. Ce qui compte, c'est comme tu l'as implicitement fait remarquer, c'est le code commite.
[^] # Re: Libvirt ?
Posté par IsNotGood . Évalué à 2.
>
> Je suis rassure que les gens de Ielo aient ecarte libvirt, ca montre qu'ils savent voir au dela du hype.
Le fait que les gens de lelo aient écarté libvirt, ne préjuge en rien qu'ils savent faire les bons choix.
Ils font bien dans le "hype", la virtualisation est "hype". Dans ce "hype", ils ont pris ce qu'il y a de plus "hype" : kvm.
> C'etait une piece importante de la strategie de RH et lui a permis de changer de solution de virtualisation sous-jacente (de xen a kvm).
Oui, mais pas seulement. Quand libvirt a été fait, personne ne savait qu'il y allait avoir kvm. Le pire ici n'est pas libvirt, mais xend qui a voulu tout faire à la fois en étant lié à une seule techno... Kvm est un remplaçant de Xen. Mais il y autres solutions de virtuailisation qui ne sont pas des remplaçants de Xen et ont leur place. Par exemple les conteneurs. Ce n'est pas actuellement la priorité de Red Hat, mais ces derniers ne sont morts. Un datacenter pourrait combiner OpenVZ et KVM.
> Mais cela reste amha une usine a gaz fragile qui n'exploite que le plus petit commun denominateur. Un design clean a partir de zero pour un produit qui ne tente pas d'utiliser plusieurs hyperviseurs ne me parait pas idiot.
Faire Xend, Kvmd, OpenVZd, etc...
Pas sûr que ça donne plus de qualité.
Quelques soit le système de virtualisation il y a des points communs. Le stockage, l'installation, la migration (à chaud ou froid), l'affichage, la sécurité/authentification, etc.
> remarquer qu'il y a des outils simples fait par des admins pour des admins qui marchent bien (genre kvmctl
Qui ne gère pas l'accès à distance, la création de vm, etc, etc.
> Cela dit, comme le nom de leur groupe l'indique, ce sont surtout des gens qui font des prototypes qui passent ensuite souvent en prod tels quels
Faut bien faire des prototypes. et.redhat.com n'est pas un groupe spécifique de personne qui ne font que ça.
Il y a des développeurs de libvirt, func, etc. L'idée est qu'il y a des solutions qui ont plus de sens lorsqu'elles sont couplées avec d'autres. L'idée est aussi de donnée plus de lumière à des solutions qui semblent prometteuses selon Red Hat.
> Ce faisant, ils ont tendance a privilegier le quick and dirty et non un design propre/sain.
Le kvmctl que tu donnais était du quick and dirty. Et ça ne voulait pas être plus.
> [une pile de reproche plus ou moins valable]
> Alors, oui, ils contribuent, mais leurs choix ne sont pas forcement les meilleurs.
Ils l'ont fait. Au premier jet rien est parfait et un programme est toujours en développement.
> D'autre part, ils n'ont pas la main-mise sur qemu (ils n'ont meme pas d'acces en ecriture au repo pour l'instant) donc rien n'empeche les gens de Ielo/LO ou des contributeurs externes de rajouter des fonctionnalites.
Oui, et c'est très bien. Je ne vois pas problème ici, au contraire.
[^] # Re: Libvirt ?
Posté par julielo . Évalué à 1.
Ce qui est déjà chose faite depuis plus d'un an par ailleurs ;-) Notre expérience sur la libvirt ne date pas d'hier et nous avons déjà contribué à la libvirt, ces patchs ont d'ailleurs été intégré mais malgrès tout il nous est plus simple pour le moment de faire les choses à notre sauce. Sachant que pour le moment l'abstraction de la libvirt doit représenter une centaine de ligne de code (et encore je suis généreux) sur les 20,000 et quelques du projet actuel. L'intégration d'un connecteur vers la libvirt prendrait très peu de temps.
D'ailleurs la libvirt nous permettrait également de supporter d'autres solutions de virtualisation (c'est comme vous l'avez dit sont but), c'est très interessant à terme. Pour le moment nous nous sommes attachés à publier quelque chose avant d'en parler, ensuite les contributions viendront ;-)
Occupons le terrain et proposons des commits!
A bientot
Julien
[^] # Re: Libvirt ?
Posté par vincentxs . É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: Libvirt ?
Posté par IsNotGood . É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...
[^] # Re: Libvirt ?
Posté par vincentxs . É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 IsNotGood . Évalué à 2.
???
> non absolument pas. libvirt est sorti en decembre 2005 (KVM fin 2006 pour info)
C'est de l'enculage de mouche.
Le README de libvirt-0.0.1 (décembre 2005) :
LibVir : simple library to use the Xen hypervisor
As of Wed Nov 2 2005, this is a completely new project, it is not
usable in any way yet.
Daniel Veillard xxx@xxx
Le README de libvirt-0.0.3 (février 2006) :
LibVirt : simple API for virtualization
Libvir is a C toolkit to interract with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard xxx@xxx
Donc bien avant KVM libvirt était conçu pour être multi-hyperviseur.
> Par contre quand on veux changer l'utilisation du programme, on se donne les moyens de ses ambitions.
T'as raison, on change le programme. Mais qemu n'a pas été changé, j'ignore pourquoi.
> 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
Donc il suffit que Ielo n'utilise pas libvirt pour que libvirt soit de la "merde".
Ielo ne veut pas utiliser libvirt, très bien, "rien à foutre" en caricaturant.
Ils ont fait un truc qui pouvait être fait avec libvirt, ça ne veut pas dire qu'ils ont fait quelques chose qui peut remplacer libvirt ni que c'est leur objectif.
# Questions
Posté par wiflye81 . Évalué à 1.
(merci au passage pour la plateforme de test, c'est très généreux).
Mais quelles sont les différences avec Eucalyptus et Enomaly pour ne cités qu'eux ?
Un support de Xen en plus de KVM est-il prévu ?
[^] # Re: Questions
Posté par Bertrand Yvain . Évalué à 2.
Pas de support de Xen prévu, mais les patches seront examinés avec la plus grand objectivité dont nous sommes capables.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.