Dans ce livre blanc vous trouverez une description des différents systèmes de virtualisation existants et des préconisations d'utilisation dépendant de l'usage que l'on veut en faire.
Pour terminer, ce livre blanc décrit les projets disponibles (KVM, Xen, VServer, etc.) avec un comparatif des différentes technologies utilisées.
Cet ouvrage très didactique ne nécessite pas de connaissances préalables sur le sujet. Il peut donc intéresser tous ceux qui veulent en savoir un peu plus sur la virtualisation.
Ce document est diffusé sous la licence CC By-NC-SA 2.0
Aller plus loin
- Lien vers l'article (109 clics)
- Livre blanc (PDF) (326 clics)
- Autre livre blanc sur la virtualisation par Smile (111 clics)
# Bof
Posté par oops (site web personnel) . Évalué à 4.
C'est en gros un livre blanc de promotion de Xen, qui est (de mon expérience) pour faire de la virtualisation Linux / Linux le moins performant et le moins stable (par rappart à Linux Vserver , OpenVZ et Vmware), et qui de plus à une pérénité discutable ( rachat par Citrix etc .... ).
[^] # Re: Bof
Posté par Antoine . Évalué à 5.
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à -6.
Mais c'est vrai que c'est si bon les SPOF... avoir n serveur tombant en simultané quel bonheur, quel délice !
Tiens je sens que je vais me faire moinser... Mais je n'exprime que mon humble avis... je préfère avoir n machine en PIII (ou equivalent) qu'une en quad-core de la mort qui fera tourner n serveurs virtuels..... Mais qu'entends-je ? Tiens l'echo de quelques intégristes verts qui vont sous peu me parler de consommation, d'économie... Ok les gars c'est vous qui avez raison et je passerai à ces réductions nécéssaires pour l'environnement quand l'interdiction de peter (notamment pour les vaches) sera effective et votée par notre noble assemblée (ainsi que l'interdiction formelle aux volcans de se mettre en irruption et ce au niveau des instances mondiales)...
Bon et bien c'était mon troll à deux balles et cher tovarich, je m'en excuse d'avance ;)... J'en resterai jusque preuve du contraire que la virtualisation est une fausse bonne idée en production...
[^] # Re: Bof
Posté par GnunuX (site web personnel) . Évalué à 3.
Ca ne te convient pas ? Ben n'utilise pas ... et ?
Par contre, ca peut convenir à d'autres personnes (et pour bien d'autre raison que l'écologie). Aujourd'hui nous utilisons vserver dans notre entreprise sur 3 serveurs interne et nous ne reviendront pas en arrière.
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à -1.
Si il vous a semblé que je fus insultant dans ce commentaire, veuillez recevoir mes plus plates excuses. Il ne m'avait semblé pourtant n'exprimer que mon humble opinion sur les dangers relatifs en terme de disponibilité et sécurité des solutions de virtualisation. J'avoue ne pas avoir développé sur le sujet car cela serait bien long. En aucun cas je ne dénigre votre choix vers Vserver (je parlais surtout de Xen mais seuls quelques érudits l'auront compris) qui dans certains cas peut s'avérer représenter une solution louable... Ne connaissant pas votre infrastructure, je me garderai bien de juger de vos décisions. Cela fait partie intégrante de mon éducation générale, tout comme le fait d'éviter les single point of failure fait partie de mon 'éducation informatique'. J'exprimais mon opinion, ne vous en déplaise... Mais encore une fois, si vous avez été blessé par mes propos, je vous prie de bien vouloir m'en excuser...
[^] # Re: Bof
Posté par benoar . Évalué à 3.
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à -2.
Mais j'exprimais juste un avis sur les solutions de virtualisation... Avoir une couche logicielle pour piloter les serveurs virtuels m'emmerde je te l'avoue... J'aimerai que ce soit piloté en hard directement (vt étant amha insuffisant) et que mes serveurs virtuels soient totalement independents...
Reste ensuite le problème même du hardware et du SPOF... à l'image des combis (j'avoue que cela est réducteur et moindre que le cas qui nous concerne mais bon ca reste une image) télé + magnéto qui lorsque le magneto tombe en panne t'impose de te separer de ton téléviseur.
C'est une question d'approche et chacun voit midi à sa porte.... mais très sincèrement, je ne peux cautionner l'utilisation d'une couche logicielle (et les problemes inhérents à ce type de configuration) pour la virtualisation c'est tout...
Maintenant, j'ai peut être tord, et il est dans la nature humaine de se tromper ou d'avoir de fausses idées et c'est probablement mon cas.... C'est l'approche que j'ai eu toutefois et les interrogations que je me suis posées sur ce type de solutions... C'est tout...
J'avoue être bien souvent de mauvaise foi, d'être souvent condescendant et d'utiliser parfois le vous à ces mêmes fins... Mais bon je suis moi... avec tous mes bugs de la vie, mon caractère de merde, mes idées arrêtés qu'il m'arrive avec intelligence de remettre en question sans l'avouer (cf. mauvaise foi) et tu vois j'avoue même une certaine propension à parler pour ne rien dire (symptomatique des personnes qui se coupent parfois du monde sans vouloir pourtant s'eloigner inconciemment d'un semblant d'humanité)
Oui tu peux me tutoyer car je ne suis qu'un vieux con de 38 printemps qui à son humble plaisir n'est jamais et n'a jamais voulu sortir de l'adolescence et de ses provocations ... ;)
Il n'y a pas de bonne ou de mauvaises idées quelque soit le sujet... Il y a juste des approches différentes.... C'est aussi cela qui fait la richesse de l'homme...
Bien à toi et au plaisir de te lire... ;)
[^] # Re: Bof
Posté par briaeros007 . Évalué à 1.
Tu ne rechercherais pas plus une mainframe que de la virtualisation?
[^] # Re: Bof
Posté par vieuxshell (site web personnel) . Évalué à 3.
Rien à voir avec le débat mais j'aime beaucoup la notion de "Solution Virtuelle".
J'essayerai de le replacer lors de ma prochaine réunion :)
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . Évalué à 5.
Pour prendre l'exemple d'une plate-forme d'un client qu'on est en train de refaire (l'ancienne a 3 ans et montre ces limites en terme de performances), toute la partie principale (grosso modo l'hébergement des sites soit 7 serveurs) n'est pas virtualisée. On sait qu'on a besoin de beaucoup de ressources et on ne veut pas la déstabiliser avec d'autres services.
Par contre, on a galéré pendant les 3 ans pour gérer des services annexes répartis sur plusieurs autres serveurs. Certains étaient petits au début et ont trop grossi pour qu'on les laisse perturber les autres services d'une machine. Pour d'autres, on avait prévu large et finalement, ça a vivoté. Du coup, on a pas mal galéré à déplacer les services, les réorganiser...
On a maintenant 4 machines banalisées pour ces services. Chaque service est dans un VServer et s'il y a besoin de les balader, ça se fera de manière plutôt transparente.
Le principe du "j'ai un serveur qui tombe, je perds n services" n'est pas forcément pertinent vu qu'on ne peut pas vraiment se permettre de perdre ne serait-ce qu'un service. Donc, les VServers sont doublés sur les 4 machines (ce qui aurait été chiant à faire sinon parce que tous les services auraient été mélangés).
En l'occurrence, on n'a pas moins de serveurs qu'avant sur la plate-forme. On est passé de 17 à 15 mais juste parce qu'on a supprimé une couche intermédiaire. Par contre, c'est plus propre, on peut la faire évoluer plus facilement et on sera serein sur les démarrages de nouvelles fonctionnalités ou pour l'évolution des anciennes. Pas besoin de prévoir 2 serveurs dès le départ, on monte 1 ou 2 VMs pour les différents services et on attend de voir ce que cela donne.
Après pour prendre un autre exemple avec de la vraie virtualisation, c'est aussi très pratique sur des machines d'intégration pour avoir plein d'environnements différents.
Clairement, il y a un gros effet de mode actuellement mais derrière il y a des vrais besoins et cela apporte vraiment quelque chose sur le plan pratique.
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à 1.
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
Je dirai la même chose de la non-virtualisation :).
Le fait d'avoir un SPOF n'est pas un problème intrinsèque de la virtualisation, juste que ton SPOF est peut-être plus critique. Ca reste une mauvaise idée d'avoir un SPOF. Et la "virtualisation" (j'inclus les containers) peut te permettre de redonder tes services de manière élégante (ie en évitant d'avoir une machine fourre-tout).
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à 2.
Après, nous sommes d'accord... C'est une question de cout mais il vaut mieux 2 machines minimum même sans virtualisation mais redondées, qu'une seule qui, si elle tombe (panne hardware ou exploit) entrainera une indisponibilité de l'ensemble des services.
C'était d'ailleurs l'objet de mon premier commentaire car bon nombre de personnes malheureusement virtualisent sans redondance et dans ce cadre mettent en péril la disponibilité de leurs services.
Nous avons la même approche je pense, peut etre nous sommes nous mal compris (j'avoue avoir quelques problemes pour exprimer ceratines idées parfois ;) )
Bien à vous,
[^] # Re: Bof
Posté par Thomas Douillard . Évalué à 1.
Alors soit tu as VRAIMENT de gros problèmes,
parce que dire "La virtualisation ça sux des mamans des ours" pour dire virtualisation ça peut être bien, faut juste faire attention" c'est énorme, soit tu tro^W fait preuve d'une mauvaise foi incroyable.
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à -1.
Pardonnez moi d'avoir perturbée la sacro-sainte église de la virtualisation encore une fois...
[^] # Re: Bof
Posté par Thomas Douillard . Évalué à 0.
Comme quoi je trolle mais tu files le bâton pour te faire battre.
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à -1.
Mais c'est si bon de se faire foutter en public sur le donjon LinuxFR ...
Ah OUIIIIIII, j'ai été un mauvais garcon.... Fouette moi encore !!!!!
(délire à deux balles)
[^] # Re: Bof
Posté par IsNotGood . Évalué à 5.
Refuser de façon butée la virtualisation, c'est aussi se tirer une balle dans le pied.
Ce n'est pas car il y a des mauvais usages de la virtualisation (comme pour tout) qu'il faut en conclure que la virtualisation est sans intérêt.
On pourrait facilement donner pleins de cas où 10 machines physique sont utilisées alors que 4 ou 5 suffiraient sans problème (même sans utiliser de virtualisation).
Trop de virtualisation c'est nul. Trop de machine physique aussi.
J'utilise actuellement la virtualisation. Je dois faire un site web qui va tourner sur un serveur dédié (virtuel ou réel, qu'importe). Le développement va se faire sur ma station de travail. Elle a une distribution communautaire et donc un support dans le temps trop limité. Il me faut une distribution avec un long support pour ce site web.
Que faire ?
Acheter une nouvelle bécane ?
Non, c'est ridicule.
Installer l'autre distribution en multi-boot et booter dessus lorsque je veux/dois bosser sur le site ?
Trop chiant, je perds tout mon environnement.
Etc...
La solution pour mon cas (et que ce cas) est d'installer une machine virtuelle avec le distribution qui sera utilisée pour le site web. Et voila. C'est facile, c'est rapide, ça marche très bien. C'est se tirer une balle dans le pied que de ne pas le faire.
[^] # Re: Bof
Posté par tuiu pol . Évalué à 3.
C'est bête, c'est simple et ça marche.
[^] # Re: Bof
Posté par Antoine . Évalué à 1.
Oui, enfin il suffit de payer moins cher et tu n'auras pas un monstre...
Si tu as le goût de l'aventure, tu peux même essayer de te concocter un petit serveur économe à base de processeur Via (équivalent à un PIII :-)).
[^] # Re: Bof
Posté par IsNotGood . Évalué à 2.
Je ne connais pas exactement les caractéristiques du serveur dlfp, mais je ne serais pas étonné qu'au niveau cpu, un cpu grand public (un athlon 64 X2 à 80 €) soit suffisant. Pour 80 € tu as un monstre pour le cpu. Pour 300 € tu as 2 Go de mémoire très très rapide (8 Go/s de bande passante je crois).
Ça demande presque de faire un effort non justifiable pour chercher du matos moins puissant.
NB : Ce raisonnement n'est valable qu'en entreprise.
[^] # Re: Bof
Posté par Antoine . Évalué à 2.
https://linuxfr.org/stats/web.html/
Environ 3 pages par seconde en moyenne, donc avec des pics bien au-dessus de ça. Ce sont des pages dynamiques générées en PHP/MySQL, même avec le système de cache de Templeet qui-tue-sa-race je pense qu'il vaut mieux prévoir du matos pas anémique. A mon avis il n'y a pas de quoi héberger plusieurs Linuxfr-like sur le CPU dont tu parles, sauf à accepter de grosses lenteurs.
Par ailleurs, en entreprise si tu fais un site Web, tu veux qu'il tienne quand il y a des poussées de fréquentation très brusques (genre slashdottage), parce que ce serait quand même bête que le site soit inaccessible juste au moment où il attire beaucoup de clients potentiels. Donc il vaut mieux prévoir de la marge.
[^] # Re: Bof
Posté par IsNotGood . Évalué à 1.
Je ne parlais pas d'en mettre plusieurs. Mais un seul.
Je pense que le cpu que j'ai donné doit tenir le "choque" sans trop de problème (pas forcément les doigts dans le nez).
[^] # Re: Bof
Posté par Antoine . Évalué à 1.
Oui, mais le sujet c'est la virtualisation :-)
[^] # Re: Bof
Posté par tuiu pol . Évalué à 1.
Encore une fois je parle de la vie pro, pas d'un cas personnel. Je n'ai pas besoin d'un serveur de jetons pour moi. Dans un SI les catalogues sont généralement ciblés et limités à certains modèles (contrat passé avec un constructeur). Crois moi, si tu prends la machine la moins chère tu auras tout de même quelque chose de surpuissant pour des besoins basiques. Le fait de chercher à réduire la prolifération de ces bécanes par la virtualisation est extrêmement courant.
[^] # Re: Bof
Posté par Stéphane Davy . Évalué à 4.
Je plussoie énergiquement. J'ai sur une plate-forme de test un serveur qui ne demande qu'à ce qu'on utilise ses ressources. Plutôt que d'avoir comme souvent un GNU/Linux avec des milliers de services dans tous les sens qui se marchent les uns sur les autres, j'ai plusieurs machines virtuelles soigneusement rangées les unes à côté des autres, avec parfois des durées de vie très limitée. J'utilise Xen pour cela, ça marche très bien, nous sommes plusieurs sur le serveur, et tout le monde est content car chacun gère sa ou ses machines virtuelles. Et pas besoin d'un rack rempli de bécanes pour ça. Franchement, j'ai déjà eu à gérer des situations avec justement plein de de PIII partout, et bien, y'a pas photo.
[^] # Re: Bof
Posté par Gniarf . Évalué à 6.
indice : tes machines en PIII ou équivalent ca se fait plus et ca a disparu de la circulation. déjà j'aurais du mal à les acheter, même si je voulais
indice : tes autres bécanes en PII aussi auront vécu et leur alimentation ou leur disque va lacher du jour au lendemain. dans le premier cas ca crame tout, dans le deuxieme il faut se lever tot pour trouver des disques durs de la même classe de taille (genre IDE < 120 Go) et souvent tu t'apercevras qu'il te manque la moitié des affaires pour restaurer cette machine. joie.
indice : au lieu de surveiller au niveau matériel n machines tu en surveilles juste une ou deux pour le prix de la supervisation des machines virtuelles : si ca te prend moins de temps - ou si tu dors plus tranquille - c'est gagné et puis c'est tout.
[^] # Re: Bof
Posté par rcmn . Évalué à -1.
[^] # Re: Bof
Posté par Éric JACQUOT . Évalué à 0.
Je plussoie d'ailleurs en ton sens... Décidement je ne connais rien à l'informatique.... Mon QI est limité, mes neurones ne suivent plus... bref je suis cassé et usé... Tu me proposes de lire des mags mais le problème c'est que je n'ai jamais appris ni à lire ni d'ailleurs à écrire... D'ailleurs je te demande un peu de compassion... Cela ne fait que trois jours que je me suis mis à l'informatique et ne sachant pas lire, cela me cause de gros problèmes....
Voudrais tu dans ton infime bonté :
1 - M'apprendre à lire et à écrire
2 - M'enseigner les rudiments de l'informatique et ainsi faire de moi le professionnel que je rêve d'être c'est à dire à ton image ?
Merci de ta bienveillance ...
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
En particulier sur OpenVZ. Pour avoir très sérieusement envisagé de l'utiliser, je n'ai jamais eu l'impression que les gens de Virtuozzo poussaient outre mesure les utilisateurs vers la solution propriétaire, que ce soit dans les forums et sur les mailing-lists où j'ai toujours vu une attitude très constructive pour aider les utilisateurs. Ils maintiennent vraiment OpenVZ comme une solution technique viable et fiable, pas comme une version de développement mal finie de Virtuozzo.
De plus, ils ont une vraie volonté d'intégrer leurs technos dans le noyau Linux pour que Linux propose enfin en standard une vraie solution de container.
Le seul truc qui m'a un peu rebuté dans OpenVZ, c'est la gestion des ressources puissantes mais pas spécialement facile à prendre en main. Il est difficile de trouver de la documentation concrète sur le sujet.
Je n'aurai pas comparé les solutions de containers type VServer et OpenVZ avec les solutions de virtualisation que peuvent être Xen ou KVM. Les usages et les contraintes ne sont pas du tout les mêmes et il faut, AMHA, au moins une solution de chaque.
Typiquement, quand il s'agit juste d'obtenir un gain de facilité d'administration en compartimentant des services (avec pour objectif d'avoir des services bien identifiés, de pouvoir les rerépartir sur des machines en fonction de leur évolution...), les solutions de container sont clairement devant. Elles sont beaucoup plus souples et offrent en général de meilleures performances.
Je suis par ailleurs un peu surpris par le fait que VServer soit considéré comme complexe - il est à mon sens plutôt simple à utiliser et les outils sont assez rodés. Je suis par contre on ne peut plus d'accord sur le fait que maintenir des patches sur des trucs aussi complexes peut poser des soucis de maintenabilité à long terme.
OpenVZ a l'avantage de proposer des patches sur les kernels des distributions (notamment ceux des RHEL), ce qui est plutôt bien pour des serveurs de production. Il me semble qu'il y a des kernels debian aussi mais je n'y mettrai pas ma main au feu.
Bon, après, c'est probablement un peu facile de critiquer mais je pense qu'il est important d'insister sur le fait que containers ET virtualisation ne répondent pas aux mêmes besoins et qu'il est important d'avoir les deux. Et j'attends avec impatience le jour où il y aura enfin une solution de containers dans les kernels standards.
[^] # Re: Bof
Posté par Lucas Bonnet . Évalué à 2.
Tout à fait d'accord, ces deux technologies ne visent pas forcément le même but, mais pour de l'hébergement de serveurs, qui était le but premier de l'étude, les deux conviennent, à mon sens. C'est pour ça que j'ai étudié ces deux technos côte à côte.
Après, pour isoler de manière quasi-parfaite des systèmes, il faut éviter les conteneurs, alors que pour simplement cloisonner des applis pour éviter qu'elles se "pourrissent" mutuellement, il est plus pertinent d'avoir recours aux conteneurs qu'à une solution à base de machine virtuelle. C'est peut être pas dit aussi clairement dans le document, c'est vrai.
[^] # Re: Bof
Posté par Lucas Bonnet . Évalué à 4.
À terme, je suis déjà moins confiant pour Xen, avec le rachat par Citrix qui a tout perturbé en pleine rédaction du pavé, et un possible virage vers le proprio (on attend toujours la Xen Foundation...).
VMware est hors concours pour cette étude, proprio. Il est cependant très performant, c'est certain.
OpenVZ, je n'aime pas le comportement de la société qui met en avant sa solution proprio partout, même sur le wiki "communautaire" (ce que ne fait pas XenSource, le wiki est certes bordélique, mais ne fait pas de lien vers XenEntreprise Pro machin tous les 3 paragraphes). Si on fait abstraction de ça, cela reste une solution de virtualisation par conteneurs très performante, au même niveau que Linux-VServer (je n'ai pas fait de comparatif très poussé entre ces deux là, je ne me prononce pas plus).
[^] # Re: Bof
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
J'ai vraiment l'impression que c'est une fausse idée. J'ai fait pas mal de recherches concrètes sur OpenVZ et beaucoup lu la doc et les forums pour le mettre en place en test et je n'ai vraiment pas eu cette impression.
Un des trucs qui contredit ce que tu penses, c'est qu'ils fournissent des noyaux patchés pour pas mal de distributions et les maintiennent (ils maintiennent encore le noyau de la RHEL4 par exemple). Ca aide quand même pas mal à l'adoption d'OpenVZ alors qu'ils auraient pu fournir un patch et un kernel vanilla.
[^] # Re: Bof
Posté par Lucas Bonnet . Évalué à 1.
[^] # Re: Bof
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Je ne suis, mais alors pas d'accord du tout. VMWare est une solution
lourde disposant certes (en version entreprise) de tout un tas de
système de gestion poussé. Mais de la à dire qu'il est très performant ....
Très cher oui, très bien vendu par IBM & co, oui aussi.
Pour avoir fait des tests basiques de débit réseau sur une interface loopback j'ai eu des résultats ... intéressant ... (7.5Gbps sur la machine, physique, 6,6Gbps sur une VM xen, et 700Mbps dans les bons moments) sans parler des tests réseaux inter VM et/ou mettant en oeuvre une machine externe
# Pour les petites entreprises !?!
Posté par IsNotGood . Évalué à 3.
Premièrement, et c'est à ne pas à oublier lors de la lecture de la suite du commentaire, c'est un très bon et important travaille. J'en conseille la lecture pour ceux qui veulent se familiariser avec la virtualisation et plus.
Effectivement, comme certains le disent plus haut il y a toujours à redire. La virtualisation proposent plein de solutions et souvent compliquées. Chaqu'une à ses atouts. Normal de faire quelques erreurs.
Ce qui m'a "choqué", c'est que le livre blanc est consacré aux "petites entreprises". Ce n'est pas "petites" qui me posse problème, c'est "entreprise".
Une entreprise (la majorité en tout cas) va prendre une offre complète. Pas un programme/projet où elle doit patcher X ou Y pour que ça marche ni être obligé d'être abonné aux mailing list des développeurs (bien que ça ne soit pas une mauvaise idée).
J'ai l'impression que le livre blanc avait un certain type de "petites entreprises" en tête.
Quelles sont les offres ?
Vmware, Xensource évidemment.
Il doit aussi y avoir Novell (mais je ne me suis pas documenté).
Il a aussi Red Hat qui en fait sa première priorité depuis 2 ans (ce qui devrait durer encore de nombreux mois).
Le problème pour une majorité d'entreprises n'est pas Xen vs Qemu/KVM vs OpenVz. Le problème c'est l'offre (packaging, facilité d'utilisation, support, formation, applis certifiées pour l'environnement virtuelle, etc).
Xen "nu" ou Qemu/KVM ou autre ne sont pas satisfaisant pour une entreprise (il y a toujours des exceptions pour confirmer la règle). Le livre blanc le dit.
C'est sous cet angle que je pensais le livre blanc serait fait.
Un exemple d'offre de virtualisation très intéressant et un peu particulier (Amazon EC2) :
http://www.amazon.com/b/ref=sc_fe_l_2?ie=UTF8&node=20159(...)
On peut choisir des images publics, en acheter, les stocker, les "instancier", etc. On peut choisir sa machine virtuelle parmis 3, on paie à l'heure, etc. On trouve des images spécialisées pour Alfresco, etc. Une boite c'est spécialisé dans le support EC2 : http://info.rightscale.com/
Et qu'importe qu'EC2 utilise Xen ou KVM (pour info, c'est Xen actuellement).
Il est claire que l'analyse de ses offres est très très compliqué.
En passant, "Virtual Machine Manager" est virt-manager :
http://www.virt-manager.org/
Virt-manager n'est que la partie visible et qu'une application. Le plus important (du moins techniquement) est libvirt :
http://www.libvirt.org/
> Il est donc tout à fait envisageable à l’heure actuelle d’utiliser une architecture
complète de virtualisation constituée uniquement de logiciels libres.
Pub : http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
C'est "une architecture complète de virtualisation constituée uniquement de logiciels libres" et ça utilise libvirt/virt-manager (pas seulement). Mieux, c'est supporté, il y a des formations, pleins de fournisseurs de logiciels (libre et proprio) qui certifient/supportent, etc...
On n'est pas dans l'"envisageable". C'est du concrêt (sorti début 2007, grosse mise à jour vers novembre 2007).
Quand à l'avenir de KVM et pour confirmer l'impression de l'auteur du libre blanc, il faut noter que Red Hat va "abandonner" Xen pour se consacrer quasi exclusivement à Qemu/KVM/paravirt_ops (c'est comme ça pour Fedora qui est la base de RHEL).
Je pense que les solutions de cloisonnement ont aussi un bel avenir.
Très bon document avec de très bonnes informations. La cible a été un peu ratée :-)
Pour les solutions 100 % libre pouvant intéresser une majorité d'entreprise, ça se comprend facilement. L'offre est actuellement peu étoffée et manifestement peu visible (vu que le plus gros distributeur "entreprise" est passé inaperçu).
C'est un domaine en pleine évolution qui méritera un nouveau livre blanc dans quelques mois. Une mise à jour de ce livre blanc ?
[^] # Re: Pour les petites entreprises !?!
Posté par IsNotGood . Évalué à 2.
J'ai maintenant tout lu :-)
> J'ai l'impression que le livre blanc avait un certain type de "petites entreprises" en tête.
Du livre :
Bref, des entreprises très spécialisées. Pas pour toutes les petites entreprises comme je l'ai cru au début.
Du livre :
Je crois que ce n'est pas un "format" Qemu. C'est seulement une fonctionnalité qu'on trouve dans vfs du noyau. En tout cas ext3 le supporte, c'est la fonctionnalité "sparse file". Les images Qemu sont "bêtement" des images sans rien de particulier.
Exemple (utilisant un fichier "creu" créé par libvirt (et non qemu, mais peut être utilisé par qemu)) :
[root@one ~]# ll system_test.img ; du system_test.img
-rwxr-xr-x 1 root root 5242880001 jan 13 03:29 system_test.img
20 system_test.img
[root@one ~]# mke2fs -j system_test.img
[...]
[root@one ~]# mkdir mount_point
[root@one ~]# mount -o loop system_test.img mount_point
[root@one ~]# df mount_point/
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/root/system_test.img
5039616 141216 4642400 3% /root/mount_point
[root@one ~]# du system_test.img
213392 system_test.img
[root@one ~]# dd if=/dev/zero of=mount_point/zero bs=1M count=1000
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 bytes (1,0 GB) copied, 7,31288 s, 143 MB/s
[root@one ~]# du system_test.img
1239160 system_test.img
Notons bien que c'est spécifique au système de fichier. Si on copie le fichier sans prendre de précaution, il fera 5 Go (mais on peut le copier avec cp --sparse=... pour ne pas qu'il "grossisse", mais le système de fichier de destination doit supporter "sparse file").
Du livre :
MMOOUUAAIIFFF...
Heureusement qu'il n'y a pas Linux dans la phrase...
En passant, Red Hat (qui n'est *jamais* cité parmis les contributeurs à la virtualisation dans ce livre blanc alors que lwn.net a démontré plus d'une fois que c'était le plus gros contributeur à linux...) en a marre d'avoir à toujours porter Xen sur les différentes versions de Linux et surtout marre que Xen refuse de prendre en compte ce boulot (XenSource reste à Linux 2.6.16) :
http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
Faut lire entre ligne :
Bien que Xen soit la meilleur solution actuelle, ça ne va pas empêcher Red Hat de s'en désengager car ce n'est plus tenable (Red Hat continura de maintenir/porter certaines parties de Xen pour compatibilité avec RHEL5 comme le sous-entend le lien précédent).
Notons bien XenSource est toujours à la version 2.6.16 de Linux ! (ou alors ça a récemment changé).
> Un autre aspect négatif du projet Xen est le fait qu’il est externe au projet Linux.
Et ne fait pas grand chose pour se synchroniser avec Linux...
Tout ceci peut être compréhensible depuis le rachat par Citrix qui va se concentrer sur Windows, l'embarqué, etc...
A terme, au moins pour les serveurs ou machines de développement, Qemu/KVM va remplacer Xen sur Linux et ça ne semble pas déranger Citrix.
Du livre :
C'est device-mapper/lvm2 qui fournit la fonctionnalité je crois. Donc on peut le faire avec n'importe quoi. Qemu doit le proposer, je n'ai pas vérifié.
Du livre :
Libvirt (qui fournit virsh, virt-manager étant une interface graphique au-dessus de libvirt) peut gérer Qemu/Kvm et Xen. Un support OpenVz a été réalisé récemment je crois. Notons que RHEL (ou Centos...) utilise libvirt au-dessus de Xen. Donc ce n'est pas spécifique à Qemu/KVM.
[^] # Re: Pour les petites entreprises !?!
Posté par Lucas Bonnet . Évalué à 3.
Pour les fonctionnalités sparse et overlay, il faut en effet que le kernel le gère, mais je les mentionne parce que la page de man de Qemu en parle, et ça me semblait important de les mettre en avant.
[^] # Re: Pour les petites entreprises !?!
Posté par IsNotGood . Évalué à 1.
Ils le gèrent quasiment tous aujourd'hui. Ça existe depuis si longtemps...
> mais je les mentionne parce que la page de man de Qemu en parle, et ça me semblait important de les mettre en avant.
Il semble que qemu a effectivement un format qui lui est propre (qcow2). Il est là pour les systèmes qui ne supportnt pas "sparse file" (typiquement Windows). Sous Linux, on n'en a pas besoin.
[^] # Re: Pour les petites entreprises !?!
Posté par IsNotGood . Évalué à 1.
Qemu a effectivement qcow et qcow2 comme format (qui ajoutent les fonctionnalités "compressés", cryptés, snapshot, etc et qui sont gérées par qemu). Mais comme j'ai toujours vu ça fait avec dm/lvm2, je n'avais pas imaginé que qemu avait un format spécifique.
Sous Linux c'est d'un intérêt très limité, mais qemu en tourne pas que sous Linux.
[^] # Re: Pour les petites entreprises !?!
Posté par FRLinux (site web personnel) . Évalué à 1.
2.6.18 et depuis deja quelques temps.
[^] # Re: Pour les petites entreprises !?!
Posté par xguardian . Évalué à 1.
2.6.20 pour ma part sous Gentoo/Linux 2007.0
@+,
Guile.
[^] # Re: Pour les petites entreprises !?!
Posté par CrEv (site web personnel) . Évalué à 2.
Le kernel "officiel" xen est un 2.6.18
Par contre, certaines distributions telles que redhat, gentoo et surement d'autres "xenifient" elles-même leurs kernel.
Je crois que c'est une des raisons (le fait de devoir tout le temps xenifier les nouveaux noyaux alors que xensource ne le fait pas) pour lesquelles Redhat souhaite abandonner xen.
[^] # Re: Pour les petites entreprises !?!
Posté par IsNotGood . Évalué à 1.
Pour info, 2.6.21 sous F8. Notons que le noyau sans Xen est un 2.6.23, que F8 va bientot passer à 2.6.24 et le noyau xen rester à 2.6.21. Bref, il y a un problème.
[^] # Re: Pour les petites entreprises !?!
Posté par IsNotGood . Évalué à 1.
Et le 2.6.18 est sorti depuis bien longtemps. Et entre temps le 2.6.19, .20, .21, .22, .23 sont sortis...
Bref, ça ne change pas grand chose au problème.
Merci d'avoir corrigé mon commentaire.
[^] # Re: Pour les petites entreprises !?!
Posté par FRLinux (site web personnel) . Évalué à 3.
Comme precise plus haut, oui, depuis d'autres versions sont sorties et Xen serait gentil de patcher tout seul au lieu d'attendre que d'autres le fassent, on parle quand meme de leur projet. Je rejoins le coup de gueule de RedHat ici, faut pas prendre les libristes pour des cruches.
# Quelques imprécisions
Posté par Yves Martin . Évalué à 4.
Dans ce cas, il est rare qu'un processeur récent soit bien exploité par un vieux système d'exploitation. Il est même possible que ce vieux système ne démarre pas. La virtualisation n'est plus possible, il faut émuler !
Là encore, il y a confusion car la note fait penser à Mac pour PowerPC. Dans ce cas la virtualisation ne fonctionne pas. C'est à nouveau de l'émulation.
Je n'ai pas trouvé de mention (ok je n'ai pas encore tout lu) que la virtualisation devrait se limiter au partage des ressources CPU et mémoire du matériel mais qu'il vaut mieux éviter les gros accès disque - donc ne pas héberger un serveur de base de données très solicité sur une VM. Cela reste possible avec un SAN par fibre optique mais il faut tester au cas par cas.
[^] # Re: Quelques imprécisions
Posté par Lucas Bonnet . Évalué à 2.
Je faisais principalement référence à de l'émulation pour ce cas de figure (typiquement, un QEMU qui fait tourner un Windows 95/98 sur une machine moderne).
Pour moi, cela reste de la virtualisation (par le biais d'un émulateur), mais ce n'est clairement pas le même usage qu'un Xen, c'est clair.
Je n'ai pas trouvé de mention (ok je n'ai pas encore tout lu) que la virtualisation devrait se limiter au partage des ressources CPU et mémoire du matériel mais qu'il vaut mieux éviter les gros accès disque - donc ne pas héberger un serveur de base de données très solicité sur une VM.
C'est peut être pas dit aussi explicitement, je répète à plusieurs endroits que les E/S sont des opérations très coûteuses sur un système virtualisé.
# Merci !
Posté par Ririsoft . Évalué à 4.
Je suis entrain de me plonger dans l'univers de la virtualisation pour des besoins de particulier (et non d'entreprise). Néanmoins je suis curieux et j'aime bien comprendre les choses.
Jusqu'ici je n'avais jamais trouvé de document présentant une vue d'ensemble de toutes les technologies utilisées et des sociétés/communautés derrière.
Très franchement je trouve ton travail remarquable. L'ensemble du document est hyper clair et rend accessible à des néophytes comme moi des concepts qui ne sont pas forcément évidents à appréhender.
Quand j'aurais assez d'expérience en la matière je serais tenté d'écrire une autre partie à ton document : une étude des solutions de virtualisation pour les particuliers. Je parlerai bien de Virtualbox, Parrallels, Qemu (encore et toujours lui) et autre. Je parlerai bien aussi du support des périphériques vidéo et USB : le support matériel des périphériques (carte graphique, webcam, ipod ...) est assez important pour un particulier.
Enfin d'ici là le monde de la virtualisation aura bien changé !
Merci encore pour ce très bon travail et merci de l'avoir partagé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.