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.
Journal Red Hat annonce sa stratégie pour la virtualisation
23
fév.
2009
# .
Posté par snt . Évalué à 1.
>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 IsNotGood . Évalué à 2.
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 pasBill pasGates . Évalué à 4.
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 snt . Évalué à 1.
[^] # Re: .
Posté par snt . Évalué à 2.
# Virtualisation
Posté par Skunnyk (site web personnel) . Évalué à 4.
"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 IsNotGood . Évalué à 1.
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 IsNotGood . Évalué à 3.
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 Dup (site web personnel) . Évalué à 3.
# ovirt
Posté par P.-A. . Évalué à 2.
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 IsNotGood . Évalué à 3.
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 oau . Évalué à 1.
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 P.-A. . Évalué à 1.
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 IsNotGood . Évalué à 3.
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 oau . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.