Journal Red Hat annonce sa stratégie pour la virtualisation

Posté par  .
Étiquettes :
22
23
fév.
2009
La position de Red Hat était mal perçue jusqu'à maintenant. Certains, et même beaucoup, pensaient que Red Hat voulant être un acteur majeur dans la virtualisation, était dans une fâcheuse position. Ce n'était pas faux, c'est un peu faux aujourd'hui. Les annonces de Red Hat permettent d'y voir un peu plus clair.

On peut y voir une rupture ou simplement l'ajout de nouveaux produits. Rupture car Red Hat a dit ne pas vouloir dissocier OS et virtualisation. Aujourd'hui Red Hat fait les deux. Les OS fourniront de la virtualisation (ça sera une facilité de base de l'OS avec KVM) mais il y aura des distributions dédiés virtualisation. C'est une adaption à la montée de la demande de virtualisation et c'est assez bien vu. Ça offre une plus grande ouverture que seulement RHEL.

Red Hat bascule sous KVM. Tous les nouveaux produits utilisent KVM sans fournir Xen. Il y aura KVM dans la à venir RHEL 5.4. Xen sera toujours présent dans la 5.4 pour des raisons évidentes de compatibilité et de continuité de support. Notons que ça va être coton pour Red Hat de mettre KVM dans un noyau 2.6.18. Rien n'a été annoncé pour RHEL 6 qui devrait (encore) être "repoussée" (avec des guillemets). M'enfin, on peut dire avec une grande confiance que ça sera exclusivement du KVM. Les fonctionnalités ajoutées par les nouveaux produits seront sûrement sur RHEL, mais pas avant RHEL 6 à mon avis. Ceci facilitera aussi la maintenance de l'ensemble pour Red Hat (tout utilisera la même base).

La stratégie se veut très ouverte à d'autres acteurs. Tout (presque) est basé sur des technologies ouvertes depuis longtemps (libvirt, kvm, ovirt, Cobbler, Thincrust, FreeIPA, etc). Red Hat espère créer un écosystème autour de son offre/architecture. Il y aura, par exemple, peut-être des offres commerciales avec l'hyperviseur Red Hat, mais un autre outil de gestion que celui proposé par Red Hat, etc.

Il y a :
* Red Hat Entreprise Linux (RHEL) : Presque rien ne change ici. RHEL reste un produit généraliste que l'utilisateur pourra personnaliser à fond. Il est pour les utilisateurs expérimentés (sauf desktop). On pourra évidemment faire tourner RHEL sur RHEV-H (voir ci dessous). RHEL reste l'appliance de Red Hat (virtualisé ou pas).

* Red Hat Enterprise Virtualization Hypervisor (RHEV-H) : C'est une distribution minimum qui fait hyperviseur. Petite (environ 128 Mo), stateless (pas d'installation, pas de paramétrage, sera bootable avec une clé flash ou un CD-ROM par exemple), Sera gérable à distance (via l'interface libvirt).

* Red Hat Enterprise Virtualization Manager for Servers (RHEV-MS) : Ne fait pas de virtualisation, il permet de gérer un ou plusieurs hyperviseurs (migration, etc). Gère aussi les images, provisionnement, etc. Pourra très probablement utiliser d'autres fournisseurs de virtualisation que RHEV-H (par exemple EC2).

* Red Hat Enterprise Virtualization Manager for Desktops (RHEV-MD) : C'est Solid ICE de Qumranet. Solid ICE est dédié à la virtualisation desktop. Il est dommage que RHEV-MS et RHEV-MD soit deux produits différents. Peut-être que face à la demande pression, Red Hat n'a pas le temps de les fusionner. Mais à mon avis à long terme il n'en restera qu'un.

Un cas d'utilisation de RHEV-MS pour se faire une idée (c'est simplifié) :
- RHEV-H : Une RHEV-H par machine, aura des machines virtuelles (GNU/Linux, Windows, Solaris, etc).
- RHEV-MS : Une RHEV-MS. Gère les RHEL-H et ce qui tourne dessus (fait les demandes de création d'OS, provisionne le stockage, gère les images, etc).
- Stockage : Actuellement iSCSI ou NFS.
- Un poste quelconque avec un navigateur web pour se connecter à RHEL-MS et gérer le tout.

Remarquons que les RHEV sont pour un usage bien spécifique. A l'usage elles ne demanderons pas d'être une pointure en GNU/Linux. Pourra par exemple être utiliser pas des admins qui ne connaissent rien à GNU/linux. Ce sont des solutions qui se veulent "clé en main".
Red Hat indique que la suite RHEV doit permettre des déployements massifs (par milliers !).

Actuellement les RHEV ne sont pas basées sur RHEL (RHEV-H et RHEV-MS sont actuellement développées sur F10/Rawhide). Mais elles passeront probablement à RHEL 6 lorsque celle-ci sortira. Ce n'est pas critique, ce ne sont que de toutes petites distributions pour y faire tourner des applis bien spécifiques.


Logiciel libre :
Tout ceci utilise des produits libres ou qui vont le devenir :
* libvirt : http://libvirt.org/
* ovirt : http://ovirt.org/ (à lire ! Ovirt utilise beaucoup d'autres technos très intéressantes (issues de http://et.redhat.com/ ) et pas seulement libvirt)
* SolidICE : n'est pas encore libre, mais va le devenir. Plus d'info ici : http://www.qumranet.com/ . Cette page Fedora montre que ça sera bientôt libéré : https://fedoraproject.org/wiki/Qumranet
* SPICE : Techno équivante à rdp mais en plus rapide. Sera libérée assez rapidement. Voir par exemple http://www.press.redhat.com/2009/02/18/whats-on-brians-mind-(...) .
* Drivers spécifiques pour KVM ou Spice (genre virtio pour Linux ou pour utiliser Spice) pour améliorer les performances des OS invités. Pour Linux ils sont déjà libérés (sauf pour Spice). Pour Windows, ils le seront lorsqu'ils seront prêts (la licence n'est pas encore définie (MS et ses ambroglios oblige...)).

Notons qu'il n'est pas dans la nature de Red Hat d'avoir du proprio.

Dans les divers communiqués du jour, Spice n'est indiqué que pour RHEV-MD. Mais il le sera pour tout le monde à terme.

Il y a quelques doublons (RHEV-MS et RHEV-MD, RHEL-MGR qui fait grille/cluster dont beaucoup de ses besoins sont dans RHEL-MS).
Red Hat veut unifier tout ça :
http://www.redhat.com/v/ogg/Red_Hat_Sets_Virtualization_Agen(...)

Notons que l'accord récent entre Red Hat et MS ne couvre pas KVM.

Prix : Inconnu actuellement.
Date de sortie : en plusieurs étapes. La première est prévue dans 3 mois (RHEV-MD ou SPICE ?), la dernière dans 18 mois.

Les communiqués du jours :
http://www.redhat.com/virtualization-strategy/
http://www.press.redhat.com/2009/02/23/open-source-innovatio(...)
http://investors.redhat.com/releasedetail.cfm?ReleaseID=3670(...)
http://investors.redhat.com/releasedetail.cfm?ReleaseID=3670(...)
Le webcast : http://www.redhat.com/promo/webcast/223 (enregistrement demandé)

Lecture fortement recommandée : http://ovirt.org/ : donne une bonne idée de ce que veut faire Red Hat. On peut utiliser Ovirt sur une seule bécane. Pratique pour les tests et développements.


Red Hat est brillant mais joue très gros ici. L'objectif étant rien moins que de se frotter aux offres de VMWare et MS. Techniquement c'est du bon (même si on peut regretter des redondances). Mais il reste beaucoup de boulot pour en faire des produits entreprise.
  • # .

    Posté par  . Évalué à 1.

    Merci pour le journal complet et les liens, ça va me faire un peu de lecture.

    >SPICE : Techno équivante à rdp mais en plus rapide.

    Y'a des benchmarks qui trainent ou c'est un souhait ou une annonce ?
    • [^] # Re: .

      Posté par  . Évalué à 2.

      > Y'a des benchmarks qui trainent ou c'est un souhait ou une annonce ?

      Pas de bench à ma connaissance (du moins public).
      Mais actuellement c'est le seul truc qui, par exemple, permet d'avoir de la vidéo en haute définition. Rdp ne le supporte pas (trop lent).
      J'avais fait un journal sur SPICE :
      http://linuxfr.org/~IsNotGood/27880.html
      On y trouve des démos :
      http://www.youtube.com/watch?v=S4DZwYqnyJM
      http://us.qumranet.com/videos/Qumranet.wmv (Spice et SolidICE)
      • [^] # Re: .

        Posté par  . Évalué à 4.

        Mais actuellement c'est le seul truc qui, par exemple, permet d'avoir de la vidéo en haute définition. Rdp ne le supporte pas (trop lent).

        RDP 7 dans Windows 7 / 2008 R2 le supporte, de meme que le remoting DirectX cf. http://www.dabcc.com/article.aspx?id=9284
        • [^] # Re: .

          Posté par  . Évalué à 1.

          ( tant que j'ai un type qui s'y connait à portée de clavier :) Est-ce que le remoting directx ça va avoir un impact bénéfique sur les applis wpf en terminal server ?
          • [^] # Re: .

            Posté par  . Évalué à 2.

            arg. Je viens de voir le diagramme sur ton lien. Tant pis pour wpf.
  • # Virtualisation

    Posté par  (site web personnel) . Évalué à 4.

    Merci pour ce journal, qui pourrait faire dépêche.

    "Notons que ça va être coton pour Red Hat de mettre KVM dans un noyau 2.6.18" <= Debian Etch dispose de KVM backporté sur un 2.6.18, donc c'est possible, après niveau fonctionnalité, je ne sais pas si tout sera exploitable, etch dispose de la version 28 de KVM, la dernière étant la 84 ...

    Cependant, cela est très intéressant, mais au vu de ce qu'il est annoncé, d'ici 18mois, on aura une infrastructure complète made in Red Hat (et libre !), équivalent à VMware Center (anciennement VirtualCenter) d'aujourd'hui ...
    Sachant que la version 4 de ESX (de VMware) va sortir cette année, ESXi étant maintenant gratuit, RedHat va devoir mettre la paquet :-)
    RHEV-H à l'air intéressant, j'espère que je pourrais le tester un jour !

    J'espère que cela marchera, et que RedHat arrivera à prendre des parts de marché dans ce marché bouillonnant, ou des hyperviseurs sortent presque chaque semaine ... (j'exagère mais c'est presque ça)
    • [^] # Re: Virtualisation

      Posté par  . Évalué à 1.

      > Merci pour ce journal, qui pourrait faire dépêche.

      Tu peux en faire une dépêche.
      Petite exigence, si tu me cites dans ta proposition de dépêche, je veux un lien sur ce journal. Sinon, le lien sur ce journal n'est pas demandé et tu fais tout ce que veux du texte de ce journal. C'est valable pour d'autres.
    • [^] # Re: Virtualisation

      Posté par  . Évalué à 3.

      > Debian Etch dispose de KVM backporté sur un 2.6.18, donc c'est possible, après niveau fonctionnalité, je ne sais pas si tout sera exploitable, etch dispose de la version 28 de KVM, la dernière étant la 84 ...

      Concernant la version, Red Hat doit au moins utiliser la version qui supporte virtio (version 70 mininum ?). Il serait très mal vu que RHEL 5.4 avec KVM soit moins rapide que RHEL 5.3 avec Xen.
  • # Merci pour ces infos

    Posté par  (site web personnel) . Évalué à 3.

    Journal intéressant sur des technos en pleine mouvance ;)
  • # ovirt

    Posté par  . Évalué à 2.

    Je suis grandement intéressé par oVirt depuis que je suis passé de Xen à KVM. Quelqu'un a des retours d'expérience à ce sujet? Par exemple, libvirt a pris un peu de temps à être réellement utilisable.

    Au niveau du déploiement sur d'autres distrib autres que Redhat/Fedora? Ca se tente? Mon objectif est surtout d'ouvrir ma plateforme de virtualisation à des personnes, certes technique, mais pas au point de se servir de libvirt/kvm en ligne de commande.
    J'utilise déjà virt-manager de manière ponctuelle mais à ce niveau c'est le déploiement qui pose problème. Qqch comme oVirt ce serait le must. J'ai juste l'impression que le déploiement risque d'être assez complexe.
    • [^] # Re: ovirt

      Posté par  . Évalué à 3.

      > Au niveau du déploiement sur d'autres distrib autres que Redhat/Fedora?

      Pour l'instant à ma connaissance ce n'est pas porté sur d'autres distributions.

      > Ca se tente?

      Bon courage alors.
      Il y a énormement de travail sur Ovirt actuellement. Ovirt dépend de pleins d'autres projets qui sont aussi en développement. Le portage ne doit pas être facile actuellement.
      Red Hat annonce prêt de 18 mois pour finaliser le tout ! Certes, ceci inclus le support, les formations, etc.

      > J'ai juste l'impression que le déploiement risque d'être assez complexe.

      Il y a d'autres projet un peu moins poussés :
      http://www.opennebula.org/
      http://xenman.sourceforge.net/
      • [^] # Re: ovirt

        Posté par  . Évalué à 1.

        Ovrit est et reste pour le moment une grosse usine à gaz de par ses dépendances avec beaucoup d'autre logiciel libre.

        Personnellement j'utilise ubuntu server et ce petit script basé sur vmbuilder :

        #!/bin/bash
        RAM=
        IP=
        HOST=
        DST=/infra/$HOST/

        mkdir -p /data/virt/$DST
        echo $IP $HOST >> /etc/hosts

        vmbuilder kvm ubuntu -m $RAM --suite intrepid --flavour virtual --arch i386 -o --libvirt qemu:///system --ip $IP --host $HOST --tmpfs - --firstboot boot.sh -d /data/virt/$DST --mirror http://mir1.ovh.net/ubuntu/ --addpkg vim ctags unattended-upgrades

        virsh start $HOST
        • [^] # Re: ovirt

          Posté par  . Évalué à 1.

          C'est aussi ce que je fais. Mais j'essaie surtout de trouver une solution pour le personnel non geek qui aurait éventuellement des besoins ponctuels quand je suis absent.

          En fait virt-manager aurait été parfait mais dispo sur un nombre restreint de plateforme. C'est pour ça que oVirt, sur le papier me parait la solution idéale. Mais à partir des retours de IsNotGood et du site, je crois que, pour le moment, ça en vaut pas la peine (rapport emmerdes/features trop élévé).
        • [^] # Re: ovirt

          Posté par  . Évalué à 3.

          > Ovrit est et reste pour le moment une grosse usine à gaz de par ses dépendances avec beaucoup d'autre logiciel libre.

          L'objectif d'Ovirt n'est pas de faire un wrap bash de 10 lignes de libvirt.
          Par exemple avec Ovirt tu peux dire que 10 cpu et 500 Go seront affectés à l'équipe de développement. Celle-ci se connecte à Ovirt et crée ses bécanes (sans avoir le droit de toucher aux autres). L'admin en fonction de la disponibilité du matériel pourra déplacer des machines virtuelles.
          Est-ce une "grosse usine à gaz" ?
          Ben si tu sais fournir les même fonctionnalités de façon simple, n'hésites pas.
          Ovirt est a des objectifs techniques mais aussi d'organisation. Il doit être intégrable dans une grosse entreprise. C'est-à-dire pas seulement aux admins du data-center, mais aussi à d'autres départements le tout étant consolidé au niveau du data-center.
          Ce n'est pas une solutions de virtualisation pour un besoin spécifique. Ça se veut généraliste.
  • # Excellent !

    Posté par  . Évalué à 2.

    j'aime beaucoup Redhat pour sa capacité à se dire. Ok Xen c'était bien. Maintenant kvm c'est mieux on part sur kvm. J'aime bien ça. Surtout que grace à la libvirt (et donc ovirt) on garde quand même la possibilité d'avoir aussi ses anciens xen. Franchement j'adore.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.