La virtualisation et le libre : où en est-on ?

Posté par  . Modéré par Mouns.
Étiquettes :
1
28
avr.
2008
Virtualisation
Virtualisation par isolation, machine virtuelle complète ou partielle, hyperviseur : état des lieux et perspectives de l'open source.
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
Chacune des solutions comporte des avantages et des inconvénients. Virtualisation par isolation

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  . Évalué à 6.

    patrick_g sort de ce corps!!!!
  • # VirtualBox

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

    • [^] # Re: VirtualBox

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

      Qui a été racheté il y a peu par Sun Microsystems [1].

      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  . Évalué à 8.

        Le support de l'USB n'est pas disponible dans l'"Open Source Edition" malheureusement.
        • [^] # Re: VirtualBox

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

          c'est clair... si il avait ce support... ca ferait un malheur total.
          • [^] # Re: VirtualBox

            Posté par  . Évalué à 2.

            Oui, quoique les performances ne sont pas toujours au rendez.vous comparé à Vmware. Essayez d'installer une distrib dans vmware puis dans virtualbox : c'est clairement plus long dans virtualbox, je dirais au moins une fois et demie.
            • [^] # Re: VirtualBox

              Posté par  . Évalué à 3.

              C'est curieux je constate exactement l'inverse ! Chez moi virtualbox est beaucoup plus véloce d'une part et la gestion de la mémoire est meilleure également, j'arrive à lancer beaucoup plus de machines virtuelles en même temps.
              • [^] # Re: VirtualBox

                Posté par  . Évalué à 4.

                Ptêt parce que toi tu as du VT-X et pas lui.
                • [^] # Re: VirtualBox

                  Posté par  . Évalué à 2.

                  Si je l'ai... et j'ai essayé avec et sans.
                • [^] # Re: VirtualBox

                  Posté par  . Évalué à 1.

                  Je compare avec vmware server, pas esx, c'est peut-être pour ça ?
                  • [^] # Re: VirtualBox

                    Posté par  . Évalué à 1.

                    Peut-être (j'utilise le player).
                    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.

            Ben alors Qemu doit faire un malheur ;-)

            ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: VirtualBox

          Posté par  . Évalué à 6.

          C'est bien quelque chose qui me... "chipote" (attention: belgicisme). Etant donné sa nature Open Source, je m'attendais à ce que cette version de Virtual Box soit dotée d'un patch communautaire pour le support de l'USB, pour faire comme Qemu et KVM.

          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  . Évalué à 2.

            Je partage ton opinion sur les GUI, et je trouve comme toi que l'interface de Qemu est nettement mieux que celle de Virtualbox.

            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  . Évalué à 1.

            "ne sautons pas sur les conclusions"

            ca aussi c'est un belgicisme? :-)

            en tout cas j'aime bien...

            (oui, c'est bien inutile comme commentaire...)
    • [^] # Re: VirtualBox

      Posté par  . Évalué à 3.

      > Il manque VirtualBox

      et UML (User Mode Linux), coLinux...
  • # Ovirt

    Posté par  . Évalué à 5.

    Un nouveau projet qui utilise libvirt :
    Ovirt : http://ovirt.org/

    C'est surtout pour les datacenter.
  • # un bon bouquin sur Xen

    Posté par  . Évalué à 5.

    Pour information, voici un bouquin sympa pour ce qui voudrait approfondir leurs connaissances sur Xen ( http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470138114.(...) ).

    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  . Évalué à 5.

    Mis à part OpenVZ, il y a l'excellent Vserver disponible directement en patch kernel (compatible grsec) et qui est pas mal utilisé :

    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.
  • # Jails ?

    Posté par  . Évalué à 8.

    On parle de chroot, de zones Solaris mais pas des Jails des *BSD.
    Ç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  . Évalué à 3.

      Les jails c'est plutôt pour FreeBSD, non ? Pour les autres *BSD, il me semble qu'il existe quand même des implémentations...
      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  . Évalué à 3.

        Oui Open & Net le supportent via sysjail http://en.wikipedia.org/wiki/Sysjail

        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  . Évalué à 2.

          Sauf que sysjail se repose sur systrace dont on a découvert une bonne grosse race qui rend le bouzin inefficace...

          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  (site web personnel) . Évalué à 5.

    >Actuellement, la solution la plus utilisée en entreprise reste Xen
    >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  (site web personnel) . Évalué à 6.

    `son inclusion fait encore l'objet de discussion - voire d'un rejet pur et simple par certaines distributions (11).'

    ?!?!?!

    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  . Évalué à 3.

      Désolé Samuel, mais le seul mot qui me vient à l'esprit c'est "bullshit".

      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  . Évalué à 2.

        Fedora a un peu de retard mais dès le début il était annoncé que c'était très ambitieux de tenir les délais. Donc la dé-xennification (xen-source) ne sera pas terminée pour F9 mais pour F10.

        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  (site web personnel) . Évalué à 1.

    Si je ne m'abuse, ESX est un hiperviseur de virtualisation et non de paravirtualisation comme XEN.

    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  (site web personnel) . Évalué à 1.

      En effet, mais il est possible d'ajouter le support de la paravirtualisation au travers de l'interface VMI (Virtual Machine Interface). Mais bon, c'est visiblement un bon gros blob... Un équivalent intéressant de VMI est paravirt_ops, qui est notamment utilisé par Lguest pour gérer les opérations sensibles (interruptions, pagination, etc.)

      http://lwn.net/Articles/175706/
      http://www.vmware.com/interfaces/paravirtualization.html
    • [^] # Re: ESX et paravirtualisation

      Posté par  . Évalué à 2.

      Tu sembles confondre paravirtualisation et virtualisation matérielle.
      * 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  . Évalué à 4.

        L'OS a conscience d'être virtualisé

        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 ?
  • # k-suite

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

    Dites, Xen ne sera pas également géré au travers de kvm, (bientôt) par hasard ?
    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  (site web personnel) . Évalué à 6.

      Il n'y a pas que du n'importe quoi dans ce post, donc j'y reponds :)

      > 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  (site web personnel) . Évalué à 2.

        Et je me permets de rajouter : Merci Sam ! *

        * 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  . Évalué à 1.

    Je ne suis pas convaincu que Xen soit la solution de virtualisation le plus ancienne en logiciel libre.
    Qemu est largement plus vieux, non ?
    • [^] # Re: xen le plus ancien

      Posté par  . Évalué à 3.

      je m'auto corrige : il s'agit probablement de bochs :
      http://fr.wikipedia.org/wiki/Bochs
      • [^] # Re: xen le plus ancien

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

        oui mais non

        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  . Évalué à 2.

        Nan, c'était FreeVM, défunt projet dirigé par Kevin Lawton. Projet abandonné très rapidement. Il n'en reste presque plus aucune trace dans google, snif. J'était le traducteur pour le français.
  • # virtualisation et 3D

    Posté par  . Évalué à 4.

    Il y a un point qui n'est pas abordé par ce journal, c'est l'accélération 3D.
    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  (site web personnel) . Évalué à 1.

      Je sais que le projet Parallels Desktop te permet justement d'intégrer des applications 3D DirectX directement dans ton bureau sur Mac OSX.

      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  . Évalué à 3.

      VMware semble proposer un support expérimental de DirectX. J'ignore si c'est utilisable.

      ç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  (site web personnel) . Évalué à 2.

      Une autre solution est d'utiliser du PCI passthrough, et de dedier une carte graphique a un machine virtuelle.

      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).
  • # En parlant de ça...

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

    En début d'année il y avait eu un article sympa sur la virtualisation :

    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  . Évalué à 1.

    Salut,
    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  (site web personnel) . Évalué à 2.

      Il y a eu de nombreuses choses intéressantes de dites, mais en entreprise, je vois 100% de Vmware ESX, car il fait tourner XP :-(

      ウィズコロナ

      • [^] # Re: VMware ESX hyperviseur ??

        Posté par  . Évalué à 2.

        ESX ou GSX (maintenant 'server'). Car il fait tourner XP, mais aussi 2000, 2003, Vista, 2008. Et surtout car les performances sont très bonnes.

        Et LE point important: les neuneus peuvent l'installer. Alors qu'installer xen ou kvm, fume :-)
  • # ESX paravirtualiseur ?

    Posté par  . Évalué à 1.

    Il me semble que dansVMware ESX Server on n'a pas besoin de modifier un OS pour le virtualiser !?
  • # article avec bien trop d'erreurs ou d'inexactitudes

    Posté par  . Évalué à -5.

    C'est vraiment l'un des plus mauvais articles que j'ai vu sur le sujet.

    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  . Évalué à 5.

      C'est dingue, on devrait nous payer pour lire ce genre d'article !

      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  . Évalué à 2.

        la desinformation due a la confusion massive des concepts de paravirtualisation/modification de l'OS/etc.. c'est pas terrible non plus.

        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  . Évalué à 1.

          comme disait lizardbreton
          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  . Évalué à 0.

            Mais oui bien sûr, après tout qu'importe que leurs définitions et l'approche pseudo-historique choisie nous fasse passer des vessies pour des lanternes ou nous classe les baleines dans la famille des poissons! Qu'importe si des oublis de solutions techniques montrent qu'ils n'ont finalement pas fait beaucoup de recherches. Demain, moi aussi je me bombarde expert d'un sujet et je ponds une news, puisque c'est ce qui est le plus important, n'est-ce-pas?

            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  . Évalué à 2.

            le fait de travailler pour une des solutions de virtualisation presente dans l'article, me donne un certain avantage qd je dis que l'article est bourre d'erreurs. j'aurais pu pointer les erreurs (ce que j'ai essaye avant que templeet me bouffe mon commentaire avec une erreur SQL), j'aurai pu etre plus constructif, mais au final je pense que tout l'article presente tres mal les choses et aussi introduit des erreurs trop importantes pour que des correctifs "par dessus" soit suffisant.

            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  . Évalué à 1.

              Pointe au moins une erreur, ça sera déjà ça. Et ça nous permettra de nous faire une idée sur la valeur de tes autres commentaires...
              • [^] # Re: article avec bien trop d'erreurs ou d'inexactitudes

                Posté par  . Évalué à 6.

                en vrac (liste non exhaustive):

                - 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  . Évalué à 3.

                  XEN n'a jamais parle d'utiliser virtio
                  L'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 transparente
                  Chez 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/sorties
                  Deux 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  . Évalué à 1.

                    > C'est comme ça que l'auteur de virtio a présenté son projet sur la liste de diffusion xen-devel d'ailleurs.

                    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  . Évalué à 2.

    Hmm,... je suis le seul à trouver que le concept même de virtualisation (émulateurs, hyperviseurs) est une aberration monumentale ?
    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  . Évalué à 4.

      je suppose que tu ne vois pas non plus les avantages du multi-tâches et du multi-fenetrés ?
    • [^] # Re: Je suis pas fashion, je sais...

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

      Tu n'en as peut-être jamais eu besoin parce que tous tes besoins sont satisfaits par un OS unique, ou même en redémarrant ton pc.

      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  (site web personnel) . Évalué à 2.

        Je complète : pour une entreprise il y a aussi quelque autres avantages :

        - 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  (site web personnel) . Évalué à 1.

        Je complete encore: pouvoir fournir de l'hebergement de "machine" dont on peut choisir la quantite de RAM au Mo pres (qui a besoin de plus de 64 Mo pour se faire tourner son petit serveur web perso ?)
    • [^] # Re: Je suis pas fashion, je sais...

      Posté par  . Évalué à 2.

      Oui, c'est vrai que c'est drôle l'évolution de l'informatique : il y a quelques temps, on a inventé des machines virtuelles pour avoir à s'abstraire du matériel. Mais en fait, ce qui est devenu la "meilleure" (au sens commercial) VM c'est l'IA32 ... Comme quoi, on va se trimbaler cette archi pourrie d'Intel pour encore un bout de temps. Je pense que personne n'avait prévu la virtualisation de cette archi, tellement elle n'est pas faite pour, mais finalement, VMWare/Xen y sont arrivés, et maintenant c'est devenu "normal". Je n'oserai même pas regarder en détail tous les hacks^Winnovations qui ont permis cela. Ca me rappelle d'ailleurs que beaucoup d'idées viennent du papier d'un chercheur, datant du début des années 2000, que je ne retrouve plus ...

      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  (site web personnel) . Évalué à 2.

        Je me souviens d'un article sur Login expliquant que pour Intel et AMD, il est indispensable economiquement de complexifier les architectures des processeurs en augmentant le nombre de transistors.
        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  . Évalué à 1.

      > En avoir plus qu'une...

      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  . Évalué à 1.

    La virtualisation de machines permet la virtualisation de réseaux, ce qui permet de tester les maquettes logiciels sans avoir les dizaines de machines réelles.
    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.