>> Nous avons renoncé à utiliser libvirt qui pose de nombreux problèmes dans un
>> 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 entr0p1e . En réponse à la dépêche Première publication de la plate-forme libre de HaaS (Hardware as a service) NiftyName. É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.