Les premières solutions de virtualisation sont historiquement apparues au sein des gros systèmes mainframe de chez IBM vers la fin des années 60 et au début des années 70. Malgré les avantages apportés par ce type de procédé, ces solutions sont restées cantonnées aux gros systèmes.
Ce n’est que bien plus tard – vers le milieu des années 90 – qu’il s’est popularisé avec l'explosion des performances des PC et l'arrivée des émulateurs de vieilles machines et console en tout genre. Malgré cela, la virtualisation est réservée à un cercle d'initiés jusqu’à la sortie d’un logiciel phare (propriétaire) : VMware, à l’origine de l’engouement actuel pour la virtualisation, la prolifération de solutions et l’accélération de son adoption au sein des entreprises.
On distingue :
- la virtualisation par isolation
- la machine virtuelle complète ou partielle
- l'hyperviseur
Ici, le système va gérer des contextes dans lesquelles les processus de chacune des zones ne pourront accéder qu’à un ensemble limité de processus ainsi qu’à une arborescence limitée (à la façon d’un chroot Unix (1)). Une seule zone sera capable de voir tous les processus et toutes les arborescences : la zone principale. Il s’agit de la solution la plus simple techniquement et la moins consommatrice en terme de coût supplémentaire dû à la virtualisation. L'autre gros avantage est la facilité de partager des ressources disques et réseaux avec la zone principale. Sun utilise cette technique pour ses zones/containers Solaris (2). OpenVZ (3) propose cette solution pour les serveurs Linux.
L’inconvénient majeur est l’impossibilité de virtualiser des OS différents de l’OS principal.
Machine virtuelle complète ou partielle
À l’opposé des containers, les solutions de virtualisation complète ont l’avantage de pouvoir s’affranchir du matériel. Cette virtualisation du matériel peut-être plus ou moins totale dans le sens où elle peut également inclure le processeur (Qemu (4), bochs, PearPC, émulateur de console, etc.) ou seulement les périphériques (VMware, QEMU + KQEMU ou KVM (5)) l'émulation du processeur se faisant directement sur le processeur de la machine hôte.
Dans ce type de solution la machine virtualisée n’a aucune connaissance de sa situation. Le bénéfice réside dans sa faculté à pouvoir faire fonctionner, sans aucune modification, des systèmes d’exploitation non conçus à l'origine pour la virtualisation. Tout ceci se faisant au prix d’une perte de performance pouvant être gênante (accès disque plus lent, gestion réseau plus consommatrice de ressource CPU) à très impactante (temps de traitement notoirement plus long dans le cas de l’émulation du processeur).
Hyperviseur
Face aux problèmes rencontrés par la solution virtuelle complète et par isolation, certains acteurs ont fait le pari de trouver une solution intermédiaire en spécialisant l’OS hôte et les OS invités : on parle ici de para-virtualisation. Les 2 solutions les plus connues sont Xen (projet libre repris récemment par Citrix (6)) et ESX Server (produit propriétaire de chez VMware (7)). A remarquer que Microsoft a également prévu une solution à base d'hyperviseur pour Windows Server 2008 (8).
L'avantage de cette démarche est une amélioration des performances. Du côté des inconvénients, l’OS invité doit être conçu pour être utilisé au sein d’un hyperviseur. On peut néanmoins remarquer que dans les dernières versions de Xen, nous ne sommes plus obligés d’avoir un OS capable de gérer la notion d'hyperviseur et donc passer à une virtualisation complète (9).
Autre remarque pour Xen, Sun a annoncé récemment que cette technologie serait supportée sur sa prochaine version de Solaris (10).
On peut également remarquer que, comme pour le cas des machines virtuelles complètes, les processeurs récents AMD et Intel (technologie AMD-V et Intel VT) sont capables de prendre en charge une gestion matérielle des machines virtuelles.
Perspectives d'évolution des solutions libres
Actuellement, la solution la plus utilisée en entreprise reste Xen puisqu'il s'agit historiquement de la plus ancienne solution. Malheureusement celle-ci n'est pour l'instant pas encore complètement incluse dans le tronc principal de Linux (c'est juste le mode Guest qui est entré dans le noyau 2.6.23) et son inclusion fait encore l'objet de discussion - voire d'un rejet pur et simple par certaines distributions (11).
En effet, il faut plutôt chercher du côté de KVM qui a été inclus dans Linux dès la version 2.6.20 (12). Ce choix a surtout été motivé par sa simplicité comparé à Xen. Ses défauts sont de ne pouvoir supporter que les processeurs récents de chez Intel et AMD et surtout de n'être pour l'instant géré que par une version modifiée de Qemu. A noter qu'à l'avenir, KVM supportera également la notion de para-virtualisation via l'interface virtio (inclus dans la version du kernel Linux 2.6.24 (13)).
À ce propos, virtio est amené à devenir l'interface unique du kernel pour la virtualisation des entrées/sorties. Elle permettra ainsi de mettre en commun les efforts de développement de Xen, KVM ou de toute autre solution de virtualisation à venir.
Enfin, notons l'existence de libvirt (14) qui apporte une couche d'abstraction sur la notion de virtualisation. Cette librairie supporte actuellement Xen, Qemu, KVM et OpenVZ. Elle permettra ainsi de pouvoir s'affranchir des limitations de chacune des solutions et offrir un service commun pour tout le monde.
Article rédigé avec la complicité d'Yvan.
(1) : chroot est une commande Unix qui va permettre d’isoler le processus Unix dans une sous-arborescence et de laquelle il ne pourra pas sortir.
Cette technique est souvent utilisée pour limiter les accès d’un processus dans le cadre de la sécurisation d’accès.
(2) : Quelques références sur les zones Solaris (Containers)
(3) : Quelques références sur OpenVZ pour Linux
(4) : Page principale de Qemu
(5) : Page Wikipedia de KVM
(6) : Virtualisation : Citrix rachète XenSource, le principal concurrent de VMware
(7) : Page de ESX Server
(8) : Microsoft lance la première bêta de son hyperviseur Hyper-V
(9) : Xen 3.0.3 virtualise sans modification l'OS invité
(10) : Page sur le support de Xen dans opensolaris
Xen officially in Solaris
(11) : Fedora abandonne Xen
The plan for Xen kernels in Fedora 9 : http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
(12) : KVM Official in Linux 2.6.20
(13) : qemu and virtio
Sortie du noyau Linux 2.6.24
(14) : Page principale de libvirt
# ...
Posté par cosmocat . Évalué à 6.
# VirtualBox
Posté par j (site web personnel) . Évalué à 10.
http://miscellanea.free.fr/vbox/vbox_w2k_cpu.png
[^] # Re: VirtualBox
Posté par Ellendhel (site web personnel) . Évalué à 7.
Je préfère d'ailleurs VirtualBox par rapport à son concurrent direct VMWare ; VirtualBox est moins 'intrusif' lors de l'installation (pas de création d'interface réseau, de serveur DHCP spécifique, ...) et il y a quelques fonctions supplémentaires intéressantes (support de l'USB par exemple).
[1] : http://www.sun.com/aboutsun/pr/2008-02/sunflash.20080212.1.x(...)
[^] # Re: VirtualBox
Posté par TNorth . Évalué à 8.
[^] # Re: VirtualBox
Posté par djibb (site web personnel) . Évalué à 5.
[^] # Re: VirtualBox
Posté par TNorth . Évalué à 2.
[^] # Re: VirtualBox
Posté par wilk . Évalué à 3.
[^] # Re: VirtualBox
Posté par alexissoft . Évalué à 4.
[^] # Re: VirtualBox
Posté par TNorth . Évalué à 2.
[^] # Re: VirtualBox
Posté par wilk . Évalué à 1.
[^] # Re: VirtualBox
Posté par TNorth . Évalué à 1.
J'aimerai bien l'avis d'autres personnes à ce sujet.
On trouve sur le net des bench qui donnent l'avantage à Kqemu... mais moi je ne constate pas ça.
[^] # Re: VirtualBox
Posté par ʭ ☯ . Évalué à 6.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: VirtualBox
Posté par FantastIX . Évalué à 6.
Je n'en ai pas vu mais j'avoue aussi ne pas avoir beaucoup cherché. Et puis, ne soyons pas mauvaise langue et ne sautons pas sur les conclusions de manière hâtive: le support administratif par RDP avait commencé ainsi. Maintenant il est intégré dans la version Open Source, ce qui n'est pas plus mal. Patience donc...
Opinion strictement personnelle: je préfère de loin KVM à VirtualBox en raison de sa flexibilité et de ses possibilités étendues. Je me rends compte que, depuis ma reconversion sous Linux, je me détourne de plus en plus des tout-au-GUI... :-)
[^] # Re: VirtualBox
Posté par Ririsoft . Évalué à 2.
Malheureusement j'en suis réduit à utiliser la version Puel (non libre) de Virtualbox pour les 2 raisons suivantes :
1 - Je n'ai pas de processeur compatible AMD-V ou Intel VT, donc pas de kvm/qemu. Dans ce cas vboxdrv/virtualbox est beaucoup plus rapide que kqemu/qemu.
2 - L'USB est vital pour une partie de l'utilisation que je fais de mes machines virtuelles : Windows XP pour supporter 100% des fonctionnalités de mon Tomtom et iPod. Malheureusement le support de l'USB sous Qemu, nottament l'USB 2.0, laisse à désirer ... il y a du neuf là-dessus, à ce sujet ?
Pour ce qui est de juste tester des distros, Qemu pourrait me suffire, et je vais de ce pas le réinstaller : cette petite conversation m'y a redonné goût !
[^] # Re: VirtualBox
Posté par _flo_ . Évalué à 1.
ca aussi c'est un belgicisme? :-)
en tout cas j'aime bien...
(oui, c'est bien inutile comme commentaire...)
[^] # Re: VirtualBox
Posté par Gniarf . Évalué à 3.
et UML (User Mode Linux), coLinux...
# Ovirt
Posté par IsNotGood . Évalué à 5.
Ovirt : http://ovirt.org/
C'est surtout pour les datacenter.
# un bon bouquin sur Xen
Posté par atarakt . Évalué à 5.
Je bosse avec en ce moment, et c'est vraiment une mine d'info, je vous le conseille vivement, notamment concernant les possibilités de configuration réseau de la bête qui sont épatantes.
atarakt
# Virtualisation par isolation
Posté par jean-philippe gaulier . Évalué à 5.
http://linux-vserver.org
De mémoire, linuxFr l'utilise aussi, sauf changement de l'architecture.
Au-delà du conteneur, il permet également d'installer différentes distributions clientes sur un hôte simple.
[^] # Re: Virtualisation par isolation
Posté par Victor . Évalué à 4.
[^] # Re: Virtualisation par isolation
Posté par alexissoft . Évalué à 2.
[^] # Re: Virtualisation par isolation
Posté par xabilim . Évalué à 1.
# Jails ?
Posté par kimelto . Évalué à 8.
Ça peut être une bonne solution pour isoler un service sans passer par la case "virtualiser tout un SE" :-)
http://fr.wikipedia.org/wiki/BSD_Jail
[^] # Re: Jails ?
Posté par Anonyme . Évalué à 3.
Mais oui, jes jails, c'est bon, mangez-en, et ça peut éviter de passer par une virtualisation complète de système (après, tout dépend des besoins, évidemment).
[^] # Re: Jails ?
Posté par kimelto . Évalué à 3.
PS : l'article sur la version anglophone de wikipedia est plus complet http://en.wikipedia.org/wiki/FreeBSD_Jail (mais dans tous les cas se référer au handbook :p )
[^] # Re: Jails ?
Posté par benja . Évalué à 2.
IMPORTANT: Due to handling semantics of user/kernel memory in concurrent environments, the sysjail tools, in inheriting from systrace(4), are vulnerable to exploitation. Details available here. Many thanks to Robert Watson for discovering these issues! Until these problems have been addressed, we do not recommend using sysjail (or any systrace(4) tools, including systrace(1)) for security purposes. sysjail will continue to be updated for future releases of implementing systems.
http://sysjail.bsd.lv/
# Des chiffres
Posté par oops (site web personnel) . Évalué à 5.
>puisqu'il s'agit historiquement de la plus ancienne solution.
Tu as des chiffres là dessus ?
Parce que du bruit et du marketing oui j'en ai vu beaucoup mais dans la vrai vie j'ai vu des gros parcs de linux-Vserver et d'OpenVZ mais Xen ... bof
# Niieeee??
Posté par Samuel Thibault (site web personnel) . Évalué à 6.
?!?!?!
Man lire.
Ne PAS lire ce que dit is-not-good, deja, et plutot aller lire le lien chez Fedora: pour fedora 6-8, ils ne feront pas d'effort de portage, mais pour fedora 9, oui:
`Since people seeem to use Xen, we have decided not to drop it :-)
So the plan is to re-focus 100% of all Xen kernel efforts onto paravirt_ops.'
[^] # Re: Niieeee??
Posté par entr0p1e . Évalué à 3.
C'est surtout pour ca que RH a lancé le projet Xenner [1]qui permet de faire tourner des kernels "xen-isés" sur du kvm, pour pouvoir se débarrasser de Xen tout en continuant a supporter la base installée.
Et puis ca serait sympa de préciser que tu bosses pour Citrix/XenSource!
(Ne le prends pas mal, j'apprécie énormément le boulot que tu fais, notamment sur qemu).
Gildas, partie prenante pour kvm.
[1] http://kraxel.fedorapeople.org/xenner/
[^] # Re: Niieeee??
Posté par IsNotGood . Évalué à 2.
http://fedoraproject.org/wiki/Features/XenPvops
Summary
Replacing the current forward-ported XenSource code in kernel-xen with the paravirt_ops based implementation from upstream. DomU support only, for now.
Dom0 support is targetted to Fedora 10 and being tracked on Features/XenPvopsDom0 [ http://fedoraproject.org/wiki/Features/XenPvopsDom0 ]
On peut donc presque affirmer que RHEL 6 n'aura pas Xen (de xen-source).
Ceci dit, un grand merci xen-source pour avoir fournit une fabuleuse technologie.
# ESX et paravirtualisation
Posté par Mr Kapouik (site web personnel) . Évalué à 1.
Avec ESX on peut faire tourner un système propriétaire sur une machine ne possédant pas la technologie de virtualisation. C'est pour cela qu'il y a encore une grosse différence de performance entre XEN et ESX (à l'avantage de XEN).
[^] # Re: ESX et paravirtualisation
Posté par Frédéric Guihéry (site web personnel) . Évalué à 1.
http://lwn.net/Articles/175706/
http://www.vmware.com/interfaces/paravirtualization.html
[^] # Re: ESX et paravirtualisation
Posté par GeneralZod . Évalué à 2.
* La virtualisation matérielle c'est de la virtualisation classique à l'exception que le matériel comporte le support de la virtualisation.
L'OS invité n'a pas conscience d'être virtualisé. C'est le cas de qemu/Kqemu, KVM, Xen>3
* La paravirtualisation, tu adaptes l'OS invité pour tourner avec un hyperviseur. L'OS a conscience d'être virtualisé, c'est actuellement la solution la plus efficace à machine égale.
Xen fait de la paravirtualisation donc pas besoin des extensions VT-X ou AMD-V.
[^] # Re: ESX et paravirtualisation
Posté par jeffcom . Évalué à 4.
Zut... quelqu'un lui a déjà demandé ce qu'il pensait de sa virtualisation ? doit-on prendre en compte l'impact psychologique de cette prise de conscience lors des tests ?
[^] # Re: ESX et paravirtualisation
Posté par GeneralZod . Évalué à 3.
[^] # Re: ESX et paravirtualisation
Posté par Gniarf . Évalué à 4.
# k-suite
Posté par bubar🦥 (Mastodon) . Évalué à 10.
Dites, VmWare n' utilise t il pas kvm, (maintenant) par hasard ?
Dites, kvm n' est pas basé sur le travail fait sur kqemu, par hasard ?
Dites enfin, kqemu ce n' est pas l' accélérateur de Qemu ?
Des solutions concurentes, des solutions 'adjacentes', beaucoup d' évolution. L' évolution de ces solutions (vmware donnant dans l' hyperviseur, xen évitant de modifier les guest. Vmware poussant kvm, xen racheté par citrix), finalement kvm intégré upstream au noyau. Les hyperviseurs du monde du RT (rtlinux puis rtai puis xenomai) débarquent sur la virt. (d' ailleurs le patch rt pour blob nvidia n' a pas été intégré au patch xen pour blob nvidia ?, là je m' égare..)
Merci à ceux qui complèterai ce commentaire (très) raccourci de la vie politique des solutions plus ou moins libres pour la para et directe virtualisation. Ce commentaire à l' emporte pièce de raccourcis,
tout ça pour dire :
MERCI Mr Fabrice BELLARD
zou je ->[_]
[^] # Re: k-suite
Posté par Samuel Thibault (site web personnel) . Évalué à 6.
> Dites, Xen ne sera pas également géré au travers de kvm, (bientôt) par hasard ?
Non.
> Dites, VmWare n' utilise t il pas kvm, (maintenant) par hasard ?
Pas a ma connaissance, et ca m'etonnerait.
> Dites, kvm n' est pas basé sur le travail fait sur kqemu, par hasard ?
Non, c'est fait a cote dans qemu.
> Dites enfin, kqemu ce n' est pas l' accélérateur de Qemu ?
Si !
> vmware donnant dans l' hyperviseur,
Oui.
> xen évitant de modifier les guest.
Oui.
> Vmware poussant kvm,
Uh ?! Je ne suis pas au courant d'un truc comme ca.
> xen racheté par citrix),
Oui, mais c'est en fait un prolongement logique de la strategie XenSource (qui lui donne acces a des milliers de clients). Le projet xen.org, lui, continue comme avant.
> finalement kvm intégré upstream au noyau.
Oui.
> tout ça pour dire : MERCI Mr Fabrice BELLARD
Oui ! qemu reste un element central de la plupart des solutions opensource, grace a la plethore de peripheriques virtuels qu'il sait emuler. A quand une libqemu ?
[^] # Re: k-suite
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
* ainsi que tous les contributeurs du libre, que ça soit par réalisation logicielle ou comme ici par diffusion (très bonne dépèche au passage) et explications de ces nouvelles technologies !
# xen le plus ancien
Posté par Yves-Gaël Chény . Évalué à 1.
Qemu est largement plus vieux, non ?
[^] # Re: xen le plus ancien
Posté par Yves-Gaël Chény . Évalué à 3.
http://fr.wikipedia.org/wiki/Bochs
[^] # Re: xen le plus ancien
Posté par CrEv (site web personnel) . Évalué à 2.
Bochs est un émulateur x86 et non une solution de virtualisation
Qemu l'est également mais peut être agrémenté d'un noyau jouant le rôle d'accélérateur (il ne fait "que" balancer les instructions qu'il peut au proc sans passer par l'émulation, me souvient plus exactement du nom
Kernel-based_Virtual_Machine lui fait vraiment de la virtualisation mais se base sur une version modifiée de QEmu
[^] # FreeVM
Posté par Kerro . Évalué à 2.
# virtualisation et 3D
Posté par ndesmoul . Évalué à 4.
Toutes les solutions actuelles permettent d'émuler une machine/OS presque parfaitement mais pour avoir une accélération 3D c'est plus compliqué.
Certes pour les aspects serveurs, on s'en fout mais un utilisateur donné pourrait trouver pleins d'avantages à bénéficier d'accélération graphique dans une machine virtuelle (entre autre pour jouer à des jeux réberbatifs à wine sous un Windows émulé).
VMware semble proposer un support expérimental de DirectX. J'ignore si c'est utilisable.
Un journal parlait de ce sujet https://linuxfr.org//~qdm/24807.html
Dans ce journal je vous invite plus particulièrement à regarder le message de Jux introduisant le projet VMGL qui semble apporter une solution intéressante en permettant une accélération OpenGL (pour le moment limité à du Linux).
La page du projet: http://www.cs.toronto.edu/~andreslc/xen-gl/
[^] # Re: virtualisation et 3D
Posté par yannig (site web personnel) . Évalué à 1.
Ces braves gens s'appuient sur les drivers Direct3D de chez Wine pour fonctionner (y'avait même eu une polémique à l'époque sur la non mise à disposition des drivers : http://www.winehq.org/pipermail/wine-devel/2007-November/060(...)
Mais personnellement, je ne sais pas ce que ça donne.
[^] # Re: virtualisation et 3D
Posté par jeffcom . Évalué à 3.
ça l'est... quand ça marche (quand la vm démarre)
je jouais à conquer online, un jeu utilisant dX, sous ubuntu festy, lors du passage à gutsy, ça n'a plus fonctionné... pourquoi... mystère... d'ailleurs ça m'a presque donné l'idée de faire un serveur de bots....
bref oui c'est très utilisable, pas forcément ultra performant (disons qu'il faut une machine qui suive derrière coté matos), mais c'est très utilisable... quand ça passe...
[^] # Re: virtualisation et 3D
Posté par jeffcom . Évalué à 2.
[^] # Re: virtualisation et 3D
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Ca marche tres bien avec Xen en paravirtualisation. Pour la virtualisation materielle, il faut utiliser la technologie VT-d, mais le support des cartes graphiques n'est pas encore fait dans Xen (c'est sur la roadmap de la 3.3).
[^] # Re: virtualisation et 3D
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
[^] # Re: virtualisation et 3D
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
# En parlant de ça...
Posté par Johan Charpentier (site web personnel) . Évalué à 4.
http://linuxfr.org//2008/01/12/23557.html
(qui se referait à une étude sur la virtualisation effectuée par la société Bearstech: http://bearstech.com/news/2007-12-7/livre-blanc-sur-la-virtu(...) )
Je le précise car il est, à mon avis, un trés bon complement à cette depêche...
# VMware ESX hyperviseur ??
Posté par Yves Martin . Évalué à 1.
Pour moi, VMware ESX n'est pas dans la catégorie hyperviseur mais de la virtualisation partielle.
En effet, un OS non modifié pour x86 fonctionne parfaitement dès qu'il supporte l'IDE, le SCSI par BusLogic ou LsiLogic, la carté réseau Amd PCnet32, et les bases du IBM PC AT (clavier/souris PS/2 et écran VGA)
Les "vmware-tools" ne sont pas nécessaires. Ils permettent:
* d'optimiser l'utilisation de l'interface graphique si utilisée - pour un serveur Linux, pas grand intérêt
* d'améliorer la gestion de la RAM - pour éviter de faire swapper à la fois l'OS hôte et la VM dans l'hyperviseur
* pour les anciennes versions 2.5, fournit un driver "vmxnet" pour l'interface réseau spécifique qui améliore les perfs. Depuis la version 3, la carte virtuelle PCnet32 est la seule disponible et est aussi performante que la "vmxnet".
La seule chose qui pourrait être attribuée à un hyperviseur serait la gestion de qualité de service pour l'accès aux resources CPU, disques, bande passante réseau. Mais finalement, ESX n'est qu'un Linux modifié qui fait tourner les VM comme des processus - je ne pense pas qu'il y ait énormément de différence avec VMware workstation d'ailleurs (à part la qualité de service)
Bref, pour moi, ESX ce n'est pas de la para-virtualisation mais de la virtualisation partielle.
[^] # Re: VMware ESX hyperviseur ??
Posté par palm123 (site web personnel) . Évalué à 2.
ウィズコロナ
[^] # Re: VMware ESX hyperviseur ??
Posté par Kerro . Évalué à 2.
Et LE point important: les neuneus peuvent l'installer. Alors qu'installer xen ou kvm, fume :-)
# ESX paravirtualiseur ?
Posté par guhh . Évalué à 1.
# article avec bien trop d'erreurs ou d'inexactitudes
Posté par entr0p1e . Évalué à -5.
Sérieux, il mélange tellement tout que je pense qu'il faudrait le supprimer.
Tout ce que je peux conseiller, c'est de ne pas s'y fier pour vous faire une opinion sur quelle techno fait quoi et quel est l'état de l'art.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par lezardbreton . Évalué à 5.
Non, sérieux, ça va le clientélisme passif et pourtant insultant ? Si tu as des corrections à faire, n'hésites pas.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . Évalué à 2.
faut etre realiste, l'article a pas ete ecrit par quelqu'un comprenant la virtualisation, ou qui a pris le temps de se documenter assez sur le sujet.
et pour repondre au premier post, on est tres loin d'un article de patrick_g.
(PS: je travaille a xensource)
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par briaeros007 . Évalué à 1.
si tu es si bon : pourquoi ne pas indiquer de facon constructive les erreur, vois mieux, faire toi meme une dépêche ?
Nombre de message de ta part dans ce topic : 1. -> que de critique constructive, vonlonté d'éclaircissement itou...
Donc a part dire "je travaille chez xen, ce qu'il dit c'est de la merde" , tu fais quelque chose dans ta vie ?
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par entr0p1e . Évalué à 0.
Désolé, moi je n'adhère pas.
Si l'article est de tellement mauvaise qualité qu'il faut lire la totalité des commentaires, puis les vérifier pour arriver à se faire une idée de l'état de l'art, alors il aurait mieux fallu qu'il ne soit pas publié. Sur des sujets aussi "hype" que la virtualisation, le marketing fait déjà des ravages et il est bien difficile de se faire une idée des réalites _techniques_, voire, sous les descriptions de haut-niveau, de comprendre comment ça marche, tout simplement.
PS: lezard breton as surement envie de regarder à nouveau les différentes définitions de clientélisme.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . Évalué à 2.
Les lecteurs interesses ont mieux fait d'aller chercher les quelques bon articles deja existant sur le sujet (et c'est aussi pour ca que je ne suis pas motive a faire une depeche, quand la prose deja existante est probablement meilleur que ce que je pourrai faire)
> Nombre de message de ta part dans ce topic : 1. -> que de critique constructive, vonlonté d'éclaircissement itou...
>
> Donc a part dire "je travaille chez xen, ce qu'il dit c'est de la merde" , tu fais quelque chose dans ta vie ?
(je vois pas le rapport.)
donc parce que je participe pas a linuxfr, j'ai pas de vie ? c'est vraiment interessant ton point de vue.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par Frédéric Lopez . Évalué à 1.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . Évalué à 6.
- XEN n'a jamais parle d'utiliser virtio.
- KVM est un hyperviseur et utilise _deja_ virtio (pas comme l'article suppose en mettant "supportera")
- libvirt n'est pas une couche d'abstractions permettant de s'affranchir des limitations des solutions. tout au plus une couche pour permettre de piloter les differentes solutions de facon relativement transparente.
- ESX n'etant pas un hyperviseur paravirtualise comme XEN; pas besoin de modifier l'OS pour que ca marche. (meme si ESX peut avoir des guests paravirtualises, et que xen peut faire tourner des OS non modifies a l'aide de HVM)
- perte de performance genante dans le cas des "machine virtuelle complete": completement faux: l'emulation de certaines cartes relativement amicales par rapport a la virtualisation (e1000 et scsi) permet aux guests d'avoir des bonnes performances meme si on atteint pas le maximum possible avec des drivers paravirtualises.
- le manque de mention de lguest (relativement modeste projet, mais inclus dans le kernel linux)
- virtio n'est pas un couche de "virtualisation des entrées/sorties" mais de *paravirtualisation* des entrees/sorties.
et plein de phrase sont ambigues au possible, par example:
- "l'émulation du processeur se faisant directement sur le processeur de la machine hôte" : contrairement aux autres systemes qui n'utilise pas les processeurs de la machine hote et utilise la magie pour fonctionner ?
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par Frédéric Lopez . Évalué à 3.
XEN n'a jamais parle d'utiliser virtioL'article ne dit pas que XEN a parlé d'utiliser virtio, il dit seulement que cette interface permettra de mettre en commun les efforts de développement des différentes solutions. C'est comme ça que l'auteur de virtio a présenté son projet sur la liste de diffusion xen-devel d'ailleurs.
Voir : http://archive.netbsd.se/?ml=xen-devel&a=2007-05&t=4(...)
KVM est un hyperviseur et utilise _deja_ virtio (pas comme l'article suppose en mettant "supportera")L'extrait dit que KVM supportera la notion de paravirtualisation via l'interface virtio. C'est rédigé du point de vue de la disponibilité dans le kernel (cité deux fois dans l'extrait) et ces patches n'y sont pas encore intégrés. Ça a été demandé à Linus il y a 3 jours sur la LKML pour intégration dans le 2.6.26.
Voir : http://lkml.org/lkml/2008/4/27/120
libvirt n'est pas une couche d'abstractions permettant de s'affranchir des limitations des solutions. tout au plus une couche pour permettre de piloter les differentes solutions de facon relativement transparenteChez moi ça s'appelle une couche d'abstraction. Cela dit, il est clair que les auteurs auraient du détailler les limitations dont ils parlent ou supprimer cette mention.
ESX n'etant pas un hyperviseur paravirtualise comme XEN; pas besoin de modifier l'OS pour que ca marche. (meme si ESX peut avoir des guests paravirtualises, et que xen peut faire tourner des OS non modifies a l'aide de HVM)Il n'est pas dit qu'ESX est un hyperviseur paravirtualisé, seulement que c'est un hyperviseur, ce qui est bien le cas.
perte de performance genante dans le cas des "machine virtuelle complete": completement faux: l'emulation de certaines cartes relativement amicales par rapport a la virtualisation (e1000 et scsi) permet aux guests d'avoir des bonnes performances meme si on atteint pas le maximum possible avec des drivers paravirtualises.En gros tu dis qu'ils ont raison, sauf pour certains matériels spécifiques, et dans ce cas ce n'est de toute façon pas aussi rapide que de la paravirtualisation. Complètement faux en effet...
le manque de mention de lguest (relativement modeste projet, mais inclus dans le kernel linux)Ça c'est éventuellement un oubli, mais certainement pas une erreur. Vu que tu dis toi-même que c'est un projet modeste, la raison pour laquelle ils n'en ont pas parlé semble évidente...
virtio n'est pas un couche de "virtualisation des entrées/sorties" mais de *paravirtualisation* des entrees/sortiesDeux lignes plus haut il est dit que virtio fournira la paravirtualisation à KVM, donc ça montre bien que ça permet de faire de la paravirtualisation et que le terme virtualisation a été employé au sens large. D'ailleurs le « draft IV » écrit par l'auteur de virtio parle également de « virtual I/O layer » et ne cite à aucun moment le terme paravirtualisation.
Voir : http://lwn.net/Articles/240626/
"l'émulation du processeur se faisant directement sur le processeur de la machine hôte" : contrairement aux autres systemes qui n'utilise pas les processeurs de la machine hote et utilise la magie pour fonctionner ?Non, contrairement aux autres systèmes qui passent par une couche intermédiaire pour traduire les instructions d'un processeur vers un autre. Mais quand on ne veut pas comprendre...
Disclaimer : je ne bosse ni chez Citrix, ni chez VMware et je n'ai aucun lien avec les auteurs de l'article.
[^] # Re: article avec bien trop d'erreurs ou d'inexactitudes
Posté par vincentxs . Évalué à 1.
ca n'empeche que xen l'utilisera pas.
> Chez moi ça s'appelle une couche d'abstraction.
je parle pas de la couche d'abstraction, mais de l'affranchissement des limites.
> C'est rédigé du point de vue de la disponibilité dans le kernel (cité deux fois dans l'extrait) et ces patches n'y sont pas encore intégrés
a vraiment manque de bol pour toi la, le lien a rien a voir. je suppose que t'a pas vraiment lu; donc si un jour l'envie t'en prends, tu telechargera un kernel 2.6.25 (qui est officiellement sorti) et aller voir autour de VIRTIO_{NET,BLOCK,PCI,BALLOON}, et voir que tu peux avoir un domaine completement virtio'ise avec le kernel officiel.
la majorite de ce changelog c'est pour le support des nouvelles archs. le seul nouveau virtio device, c'est la VIRTIO_CLOCK
> En gros tu dis qu'ils ont raison, sauf pour certains matériels spécifiques, et dans ce cas ce n'est de toute façon pas aussi rapide que de la paravirtualisation
et on est loin de performance *genante* comme mentionne l'article.
> D'ailleurs le « draft IV » écrit par l'auteur de virtio parle également de « virtual I/O layer » et ne cite à aucun moment le terme paravirtualisation.
ca depend de quel cote on regarde. ca paravirtualise les IO par rapport a l'hote. et au final c'est le concept de paravirtualisation qui compte en rendant le guest amical au fait de tourner dans une VM.
> Non, contrairement aux autres systèmes qui passent par une couche intermédiaire pour traduire les instructions d'un processeur vers un autre. Mais quand on ne veut pas comprendre...
et ils utilisent quels processeurs au final ? les cpus de la machine hote ...
# Je suis pas fashion, je sais...
Posté par phentex . Évalué à 2.
Avoir un OS, qui comme son nom l'indique EXPLOITE une architecture matériel, OK. En avoir plus qu'une...
[^] # Re: Je suis pas fashion, je sais...
Posté par Gniarf . Évalué à 4.
[^] # Re: Je suis pas fashion, je sais...
Posté par Aris Adamantiadis (site web personnel) . Évalué à 3.
Mais dans la vraie vie, il y a d'énormes avantages à virtualiser :
pour un particulier, un programmeur:
tester une application, un changement sur différents OS sans sacrifier sa machine réelle. Effectuer des tests sur de nombreuses versions d'un même OS. Sauvegarder l'état complet d'une machine avant d'effectuer un test irreversible (je pense à ma copine qui fait des essais de mises à jour de Koha avant de les faire sur le serveur de production), etc.
pour une entreprise:
centraliser sur une seule machine des dizaines de services à très faible consommation CPU.
avantage: là où on avait 20 serveurs bas de gamme (10 + 10 backup), on en utilise plus que 2 haut de gamme. Economie à l'achat, economie de stockage et d'energie, en plus des facilités pour faire des backups et effectuer des tests.
Bref, tu peux penser que c'est une abération parce qu'on finit par utiliser une machine à seulement x% de ses performances totales, mais dans la réalité ces performances sont secondaires dans enormement de cas.
[^] # Re: Je suis pas fashion, je sais...
Posté par Ellendhel (site web personnel) . Évalué à 2.
- migrer une machine virtuelle d'un hôte physique vers un autre pour éviter une coupure due à une maintenance.
Dans l'idéal lorsqu'on à deux gros hôtes physiques, on ne les charges qu'à 50% au maximum afin que l'un puisse récupérer la charge de l'autre si nécessaire (maintenance, panne).
- garder sur une plateforme virtuelle un système / logiciel non maintenu. Jusqu'à maintenant j'ai surtout vu cet exemple pour montrer comment faire survivre du Microsoft Windows NT 4 mais bon, ...
[^] # Re: Je suis pas fashion, je sais...
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
[^] # Re: Je suis pas fashion, je sais...
Posté par benoar . Évalué à 2.
Mais bon, quand je vois aujourd'hui des images Xen/VMWare prêtes et installables pour n'importe quel type de service, je me dit que c'est bien lourd pour quelque chose qui aurait pu être fait de manière beaucoup plus intelligente si on avait réfléchi un peu plus, et que Intel n'avait pas poussé à fond dedans (quoique, il me semble que la virtualisation hard de l'IA32 a été poussée par AMD au départ). Mais c'est vrai que ça permet de réutiliser l'existant. Mais à quel prix ... on le verra dans quelques années, quand on trouvera que l'IA32 commence vraiment à se faire vieux (ha oui, pardon, maintenant c'est l'EMT64/x86_64).
[^] # Re: Je suis pas fashion, je sais...
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
En effet, a nombre de transistor egal, l'evolution des process de production, nous aurions dans 5 ans des Core2Duo a 12 GHz pour 10 euros!
Encore un peu de patience et le x86 sera juste un coprocesseur integre de serie a tout processeur afin de garantir la compatibilite des applications industrielles. Applications pour lesquelles un changement d'archi ne serait qu'une perte financiere sans le moindre gain de fiabilite, ou de fonctionnalite ou de performance...
Je dois etre demode aussi ! ;)
[^] # Re: Je suis pas fashion, je sais...
Posté par IsNotGood . Évalué à 1.
Ben c'est comme avoir plus d'un terminal virtuel ou d'avoir la possibilité d'afficher plus d'une fenêtre sous X11, etc.
J'ai une bécane, mais sur cette même bécane je peux développer pour différents OS, tester une distribution sans arrêter mon travail en cours, etc.
L'intérêt est évident. Ce qui n'implique pas que tout le monde en a besoin.
# La virtualisation de réseaux
Posté par clowncoder . Évalué à 1.
Il manque UML dans les solutions de virtualisations présentés, d'ailleur, je ne connais que celle-là, étant donnée qu'elle me satisfait pleinement pour les manips associés aux réseaux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.