Xen devient un projet de la fondation Linux

Posté par (page perso) . Édité par Nÿco, jcr83, Benoît Sibaud et Xavier Teyssier. Modéré par Xavier Claude. Licence CC by-sa
58
16
avr.
2013
Virtualisation

Coup de tonnerre ! Alors que Xen était dans l'impasse voici quelques années, le projet de virtualisation racheté par Citrix est soutenu par la Fondation Linux. Red Hat semblait avoir gagné la course pour la solution de virtualisation du noyau. Amazon, Intel, Oracle, Cisco, Samsung, Google ou encore la NSA font partie des entreprises supportant le développement de Xen. Une recomposition du paysage de la virtualisation sous Linux est à anticiper !

The Xen project

Pour rappel, Xen est un logiciel libre de virtualisation, plus précisément un hyperviseur de machine virtuelle publié sous licence GPL v2. Son développement a débuté sous la forme d'un projet de recherche de The University of Cambridge Computer Laboratory au Royaume-Uni, la société XenSource a par la suite été créée spécialement et en a poursuivi le développement, jusqu'au rachat par Citrix. Aujourd'hui, le projet a dix ans, l'âge de la maturité.

Des signes avant-coureurs ont permis au lecteur avisé de pressentir un tel mouvement. Les dernières versions du noyau incluaient davantage de modules Xen. Un noyau Linux récent tourne comme invité Xen sans modification. Aujourd'hui, c'est la partie hyperviseur qui est soutenu par la Fondation Linux.

Développement collaboratif

Il y a quelques années, Xen était un hyperviseur accompagné d'un tas de patchs pour faire tourner Linux dessus. Ce fut une impasse dont Citrix s'en est sorti avec brio en ouvrant davantage le processus de développement de son hyperviseur. Cette ouverture a permis à Oracle, Amazon, Intel, AMD, Cisco ou encore Google de mettre la main dans le projet. Au point qu'en face, KVM paraisse un projet verrouillé par Red Hat.

La fondation Linux prend le relais de Citrix pour favoriser la collaboration de grand nom de l'informatique autour de Xen, à l'instar du développement du noyau Linux. La fondation Linux est donc l'organisation parapluie qui va héberger la gouvernance du projet. Il s'agit donc d'une reconnaissance et d'un coup de pouce pour sortir Xen du giron de Citrix.

Deux solutions

La fondation Linux propose donc deux solutions de virtualisation : utiliser directement le noyau Linux comme hyperviseur avec KVM, ou utiliser un hyperviseur dédié, Xen, avec Linux comme noyau des invités. Chacune a des avantages et des inconvénients. Chacune tend à s'optimiser pour des problématiques différentes.

Par exemple, Xen est plus avancé en ce qui concerne la paravirtualisation de cartes VGA, utile pour faire tourner des jeux dans un Windows virtualisé. En revanche, KVM est très bien supporté par libvirt et les différentes solutions d'administration de Cloud comme OpenStack ou Apache CloudStack. Xen est plus embarrassé par ses différentes générations d'outils d'administration. Un logiciel comme GNOME Machines est à un clic de l'utilisateur, grâce à KVM.

Une popularité à reconquérir

D'ailleurs, Fedora comme Debian fournissent des versions obsolètes de Xen. Le désintérêt pour Xen est palpable. Xen va-t-il reconquérir sa popularité alors que KVM est plébiscité ?

Est-ce que Citrix se débarrasse de Xen ? Vu le dynamisme du projet, c'est peu probable. Citrix annonce au contraire continuer à commercialiser XenServer. C'est une aubaine pour Citrix de placer Xen dans une organisation à but non lucratif. Cela facilitera davantage la collaboration.

Dans la même veine, on peut s'attendre à un retour d'OpenVZ, qui suit le même chemin que Citrix, face à LXC. OpenVZ est en train de réduire drastiquement la taille de son patch sur le noyau. Les nouveaux développements dans le noyau pour LXC sont réutilisés : cgroup, namespace, etc. Dans un futur pas si lointain, on pourrait utiliser les outils OpenVZ sur un noyau non modifié. En tout cas, OpenVZ est beaucoup plus actif que LXC. Pourtant LXC manque de fonctionnalités telles que la migration d'invité. Le temps nous le dira.

L'avenir de la virtualisation est donc multiple, mais libre !

  • # C'est une très bonne chose ....

    Posté par . Évalué à  7 .

    L'avantage de Xen (pour moi) est que celui-ci permet de faire tourner un VMHost sous NetBSD, contrairement à KVM qui est Linux Only (et je ne sais pas si on peut faire tourner un guest sous NetBSD ou Windows avec KVM … Quelqu'un dans la salle peut-il répondre ? D'après http://www.linux-kvm.org/page/Guest_Support_Status c'est possible, mais est-ce efficace comme solution ?)

    • [^] # Re: C'est une très bonne chose ....

      Posté par . Évalué à  7 .

      En fait, le "VMHost", il tourne sous Xen, l'hyperviseur. Linux, NetBSD, OpenSolaris tournent en dom0, une sorte de VM privilégiée dédiée à la gestion de l'hyperviseur.

      Avec KVM tu peux faire tourner tous types d'OS en guest, c'est de la virtualisation complète et non de la paravirtualisation (mais ça te demande le support d'instructions spécifiques à la virtualisation au niveau de ton processeur).

      • [^] # Re: C'est une très bonne chose ....

        Posté par (page perso) . Évalué à  2 .

        KVM est certes une virtualisation complète, mais propose aussi des périphériques paravirtuels (controleur disque, réseau, video) pour les OS virtualisés le supportant, histoire de gagner en performance.

        Personnellement, j'ai du mal à voir les avantages de xen, qui n'offre ni la souplesse (choix de l'OS ou du kernel) d'une virtualisation plus ou moins complète à la KVM, ni l'efficacité d'un système de conteneur à la openVZ.

        • [^] # Re: C'est une très bonne chose ....

          Posté par . Évalué à  10 .

          Personnellement, j'ai du mal à voir les avantages de xen, qui n'offre ni la souplesse (choix de l'OS ou du kernel) d'une virtualisation plus ou moins complète à la KVM

          Il faut te mettre à jour: xen supporte la virtualisation complète depuis longtemps.

        • [^] # Re: C'est une très bonne chose ....

          Posté par . Évalué à  -10 .

          Personnellement, j'ai du mal à voir les avantages de xen, qui n'offre ni la souplesse (choix de l'OS ou du kernel) d'une virtualisation plus ou moins complète à la KVM, ni l'efficacité d'un système de conteneur à la openVZ.

          Eviter systemd et autres lennarteries au niveau du VMHost (ou Dom0 pour les pointilleux ) est un gros avantage.

          • [^] # Re: C'est une très bonne chose ....

            Posté par (page perso) . Évalué à  8 .

            Eviter systemd et autres lennarteries est un gros avantage.

            Si encore ça ne fonctionnait pas, je comprendrais, mais quand même…

            • [^] # Re: C'est une très bonne chose ....

              Posté par . Évalué à  -10 .

              Je n'en veux pas, point barre. Si je voulais un truc à la systemd, j'utiliserais windows et son démarrage de services opaque.

              • [^] # Re: C'est une très bonne chose ....

                Posté par (page perso) . Évalué à  10 .

                C'est quoi le rapport entre systemd et Xen au fait ?

                Love, bépo.

              • [^] # Re: C'est une très bonne chose ....

                Posté par . Évalué à  9 .

                Y a quoi d'opaque dans systemd ? ( et dans le demarrage de windows aussi tant qu'à faire )

              • [^] # Re: C'est une très bonne chose ....

                Posté par (page perso) . Évalué à  2 .

                C'est sûr que udev + sysvinit + pm-utils + … + … c'est beaucoup plus clair. A moins que tu n'ai pas besoin de mise en veille, de hotplug, que tu montes tous tes drivers à la main…

                • [^] # Re: C'est une très bonne chose ....

                  Posté par . Évalué à  0 .

                  La mise en veille sur un dom0 ? Pourquoi faire ? On parle d'un serveur là. Et tout ce que tu cites a un intéret assez limité sur un serveur.

                  • [^] # Re: C'est une très bonne chose ....

                    Posté par (page perso) . Évalué à  9 .

                    Il n'y a pas que sur les serveurs qu'on virtualise hein…
                    Il m'est arrivé d'avoir une machine de dev avec un xen. Le dom0 était mon système de base. Et j'avais plusieurs VM que je démarrais à la demande sous Xen.
                    Ca fonctionnait plutôt pas mal.
                    J'ai d'ailleurs fait la même chose à base de kvm, virtualbox (enfin là c'est un poil différent) ou du vmware.

                    Et après, je ne sais pas si c'est très utilisé, mais il est parfois aussi envisageable d'arrêter des serveurs pour baisser la conso globale lors de faible besoins. C'est loin d'être idiot, et la mise en veille peut s'avérer intéressante.

                  • [^] # Re: C'est une très bonne chose ....

                    Posté par (page perso) . Évalué à  3 .

                    En dehors du fait que le suspend n'est certes pas utile sur un serveur, il faudrait noter qu'on ne va pas faire un init pour les serveur et un autre pour les desktop.

                    Tant qu'à faire, unifions les outils. À mon avis, et je ne suis pas le seul visiblement, systemd unifie ces outils.

                    Love, bépo.

                  • [^] # Re: C'est une très bonne chose ....

                    Posté par (page perso) . Évalué à  10 .

                    Je ne suis pas sûr que tu maitrises vraiment de quoi tu parles…

                    Primo, dire que systemd est opaque, c'est sous-entendre que sysvinit le serait moins, et ça c'est faux. Pour les besoins d'une majorité d'utilisateurs, les fonctionnalités des distributions modernes ont introduit un tas de hack tous pourris dans sysvinit. Exemples. C'est peut-être simple de démarrer un hello world à la fin d'un rc, ça l'est beaucoup moins de s'assurer que des montages NFS sont bien effectués quand le réseau est effectivement up, pour ne parler que de ça. Les isolations légères type LXC ou même chroot sont impossible sans un tas de hack: ne pas démarrer udev, détecter qu'on est bien dans un chroot, etc.

                    Deuxio, le suspend pour un dom0: oui c'est utile. Qui dit virtualisation, dis élasticité, en tous cas pour un grand nombre d'utilisateurs. Et l'élasticité, ça veux dire consolider des vms sur un nombre réduit de machines quand la charge diminue. Et si tu n'éteins pas les dom0 qui ne servent plus (les met en veille plutôt, pour ne pas attendre 3 heures quand la charge augmente), je ne vois vraiment pas comment tu réalises les économies d'énergie qui étaient quand même un des buts d'origine. Donc, oui, mettre en veille des serveurs, ça peut être très utile.

                    Désolé du ton, mais c'est assez pénible d'entendre dire: ça ne sert à rien parce que je n'ai pas compris à quoi ça sert.

      • [^] # Re: C'est une très bonne chose ....

        Posté par . Évalué à  5 .

        En fait, le "VMHost", il tourne sous Xen, l'hyperviseur. Linux, NetBSD, OpenSolaris tournent en dom0, une sorte de VM privilégiée dédiée à la gestion de l'hyperviseur.

        … que l'on appelle couramment VMHost voir le schéma par exemple

        Avec KVM tu peux faire tourner tous types d'OS en guest, c'est de la virtualisation complète et non de la paravirtualisation (mais ça te demande le support d'instructions spécifiques à la virtualisation au niveau de ton processeur).

        Xen supporte aussi la virtualisation complète et tu peux faire également tourner tous types d'OS en guest (j'ai une ou deux VM Guest Windows sous Xen chez moi).

    • [^] # Re: C'est une très bonne chose ....

      Posté par . Évalué à  1 .

      Il y a ce paragraphe tout au début de la page que tu cites :

      qemu/kvm will likely run most production operating systems

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: C'est une très bonne chose ....

      Posté par . Évalué à  6 .

      Perso j'ai un netBSD qui tourne sous KVM pour offrir des services réseau aux autres VMs (dhcp, dns) et ça fonctionne parfaitement bien.
      Il n'y a pas de différences de perfs notables avec les autres VM sous Linux.

    • [^] # Re: C'est une très bonne chose ....

      Posté par . Évalué à  5 .

      contrairement à KVM qui est Linux Only

      KVM est aussi disponible sous illumos (feu opensolaris): http://wiki.illumos.org/display/illumos/About+illumos

  • # Fedora comme Debian fournissent des versions obsolètes de Xen ?

    Posté par . Évalué à  2 .

    Je ne sais pas ce qu'il en est de Fedora, mais (pour une fois ?) Debian n'est pas tellement à la ramasse :
    - Xen 4.0 dans la version stable actuelle.
    - Xen 4.1 dans la prochaine stable.
    - Xen 4.2 en experimental.

    Par contre ce sont des version amputées chez Debian, et c'est parfois un peu pénible de trouver une alternative.

  • # Étrange

    Posté par . Évalué à  3 .

    Sans vouloir troller je ne comprends pas trop l'intérêt de tant miser sur Xen. L'industrie de la virtualisation d'aujourd'hui exploite les instructions de virtualisation des processeurs (VT-x, AMD-V, etc…). Une infrastructure sous KVM ou VMware bien dimensionnée offre des performances natives et une souplesse dans le choix des OS (même des vieux trucs pas pensés pour être virtualisés, comme Windows 2000).

    Xen lui est conçu pour faire de la paravirtualisation logicielle. Ça marche bien mais il faut que l'OS invité soit modifié, ce qui exclue énormément de monde (dont Windows…). C'est donc moins pertinent. Il est possible de le faire fonctionner en mode hvm (compatible Windows), il se met alors à exploiter la virtualisation matérielle, mais dans ce cas autant utiliser KVM qui est bien plus avancé et plus simple à mettre en œuvre.

    Je crois que ma réponse est dans l'article : c'est poussé par des entreprises comme Citrix qui ont des produits historiques basés sur Xen.

    Pour la mise en place d'une nouvelle infra il est plus pertinent d'utiliser OpenVZ/LXC pour des VPS Linux, et KVM pour des VM plus universelles.

    • [^] # Re: Étrange

      Posté par (page perso) . Évalué à  2 .

      Qu'est ce que tu entends par "modifier l'os invité" ? Sous KVM il faut fournir les drivers virtio au Windows si tu veux que KVM le paravirtualise. Il me semble que sous Xen c'est pareil, non ?

      D'ailleurs j'en profite de parler de virtio : j'ai un 2008 R2 virtualisé avec KVM sous Debian, et pour ne pas avoir de perfs disque trop moisies, j'ai installé les drivers virtio (0.1.30) et configuré la VM pour qu'il n'y ait que du cache writeback sur un volume QCOW2.
      Malheureusement, même si c'est mieux que le mode par défaut, je trouve que c'est quand même pas terrible et surtout, j'ai des BSOD dès qu'il monte en charge (en lecture il me semble).
      La VM redémarre suffisamment vite pour que ce ne soit pas perceptible pour les utilisateurs, mais bon, comme c'est mon contrôleur de domaine, ça craint un peu.

      Quelqu'un aurait des infos à me passer à ce sujet ?

      There is no spoon...

      • [^] # Re: Étrange

        Posté par . Évalué à  2 .

        Ben non virtio n'est pas obligatoire sous KVM.
        Par défaut il émule du matériel générique c'est pour ça que ça tourne partout.

        • [^] # Re: Étrange

          Posté par (page perso) . Évalué à  1 .

          Ce n'est pas ce que j'ai dit. :)

          J'ai dit qu'il semblait qu'il fallait les fournir au guest (les drivers virtio) pour faire de la paravirtualisation avec KVM. Sinon, effectivement, c'est de l'émulation/virtualisation complète (comme VirtualBox).

          There is no spoon...

          • [^] # Re: Étrange

            Posté par (page perso) . Évalué à  2 .

            Juste pour précision : dans ton cas avec une VM windows, oui tu as des pilotes virtio à installer pour profiter des accélérations de périphériques paravirtuels.
            Pour un linux, ce sont des modules kernel inclus souvent de base dans les distributions pas trop vieilles (car modules libres). Donc rien à installer de plus pour en profiter.
            Je crois que vmware esx a également des modules libres pour ses périphériques paravirtuels, donc également inclus de base…

          • [^] # Re: Étrange

            Posté par . Évalué à  2 .

            Virtualbox fait aussi de la paravirtualisation (au moins pour le réseau via virtio-net et pour l'émulation de carte graphique).

        • [^] # Re: Étrange

          Posté par (page perso) . Évalué à  6 .

          Ben non virtio n'est pas obligatoire sous KVM.

          Sous Xen en HVM non plus. Il utilise QEMU dans ce cas, au même titre que kvm.

          L'avantage de Xen est clairement la paravirtalisation qui permet par exemple l'ajout de processeur ou de RAM à chaud et qui à mon avis fournie une bien meilleure montée en charge sur les IO.
          Ceci étant dit sans dénigrer KVM.

          • [^] # Re: Étrange

            Posté par (page perso) . Évalué à  4 .

            l'ajout de processeur ou de RAM à chaud

            Jamais testé pour le processeur, mais pour la RAM, ça marche très bien avec KVM :-)

            • [^] # Re: Étrange

              Posté par . Évalué à  2 .

              Ah?
              Ça m'intéresse, comment fait-on ça?
              Et surtout à partir de quelle version est-ce possible?

    • [^] # Re: Étrange

      Posté par . Évalué à  4 .

      Je croyais naïvement que la paravirtualisation (les hyperviseurs de type 1, comme Xen ou Hyper V) offrait en échange un "rendement" important, contrairement à la virtualisation de type 2 (VirtualBox, KVM, VirtualPC) ?

      j'ai aussi entendu dire que KVM était un front-end pour qEMU, quelqu'un peut m'éclairer sur ce sujet ?

      • [^] # Re: Étrange

        Posté par (page perso) . Évalué à  4 .

        Pour les performances, les instructions matérielles et la semi-paravirtualisation permette de rejoindre les performances de la paravirtualisation tout en gardant l'isolation d'une virtualisation complète (i.e. faire tourner Windows sur un hôte Linux, etc.).

        KVM est plutôt un backend à QEMU. QEMU gère la partie BIOS, périphériques, etc. KVM gère l'interaction entre l'invité et l'hôtes, en tirant partie des extensions matérielles des derniers CPU.

    • [^] # Re: Étrange

      Posté par . Évalué à  -3 .

      N'importe quoi …. En tout cas comme appat à troll, c'est pas mal.

    • [^] # Re: Étrange

      Posté par . Évalué à  1 . Dernière modification : le 16/04/13 à 22:02

      Pas seulement. Sans vouloir troller Xent a l'avantage d'etre nativement de la para-virtualisation (ce vers quoi s'oriente la virtualisation si tu suis les évolutions commerciales de vmware, ou plus exactement des cpu partagés pour des entités matérielles (ram, disques) dédiées). (le truc à la mode c'est le balloning, pour gérer ses entités de ram de manière globale, bref faire de la réservation au delà de la réalité -horreur décrié dans les archis de stockage, par ailleurs- et qui vient juste de rentrer dans le noyau, nativement, avec la license qui va bien, pour les vmtools gnu)
      De plus, kvm, bien qu'ayant une histoire particulièrement attrayante pour le nerd, est vraiment un projet redhat centré. Enfni, malgré le rachat de qumranet et la libération de spice, l'afichage est gravement à la traine, ce qui greve le développement d'interface (pour de mauvaises raisons, j'en convient fort bien, quiconque a connu un vsphère center et son horrible gestion du clavier à coup de alt124 saura de quelle souffrance il s'agit)

      Quant à la mise en place d'une nouvelle infra, meme si tu t'affranchi de la problématique d'un décisonnel à la lourde, tu la choisi non pas pour ses qualités mais selon tes objectifs.

      mes deux cents.

      • [^] # Re: Étrange

        Posté par (page perso) . Évalué à  5 .

        Les problèmes d'affichages sont à mon sens très secondaire, KVM étant dans mon cas utilisé pour de la virtualisation de serveurs. Du coup, TSE suffit amplement pour les serveurs Microsoft et ssh évidemment, ssh pour les Unix.

        There is no spoon...

  • # Syntaxe, grammaire et orthographe

    Posté par (page perso) . Évalué à  6 .

    un projet de recherche de The University of Cambridge Computer Laboratory

    un projet de recherche du Computer Laboratory de l'université de Cambridge

    c'est la partie hyperviseur qui est soutenu

    c'est la partie hyperviseur qui est soutenue

    Ce fut une impasse dont Citrix s'en est sorti

    Ce fut une impasse dont Citrix s'est sorti

    mettre la main dans le projet

    participer au projet

    Au point qu'en face, KVM paraisse

    Au point qu'en face, KVM parait

    la collaboration de grand nom de l'informatique

    la collaboration de grand noms de l'informatique

    • [^] # Re: Syntaxe, grammaire et orthographe

      Posté par (page perso) . Évalué à  5 .

      la collaboration de grand nom de l'informatique

      la collaboration de grand noms de l'informatique

      la collaboration de grands noms de l'informatique

      Écrit en Bépo selon l’orthographe de 1990

  • # comparaison avec VMware

    Posté par (page perso) . Évalué à  7 .

    Aujourd'hui VMWare est un standard de fait dans plein d'entreprises.

    Au niveau fonctionnalités, il manque quoi à KVM et XEN pour rivaliser ?

    It would have taken twice as long to build it properly http://www.programmerexcuses.com/

    • [^] # Re: comparaison avec VMware

      Posté par . Évalué à  9 .

      Aujourd'hui J2EE est le standard de fait dans plein d'entreprises.

      Au niveau fonctionnalités, il manque quoi à RoR/Zope/Django pour rivaliser?

      Le problème c'est que les mythes ont la vie dure. Il y plusieurs raisons :

      • Les décideurs pressés lisent 01net, et voit articles sur VMWare, comment c'est utilisé dans toutes les entreprise. Donc quand il décident de passer à la « virtualisation » ou « au cloud » comme ils lisent dans 01net, ils décident d'utiliser VMWare.
      • Comme partout, il y a des adminsys qui sont sorti d'école sans vraiment être passioné par ce qu'il font. Ils installe windows serveur, et font tout tourner dessus. VMWare c'est un peu le windows serveur de la virtualisation.
      • Pour avoir trollé avec un adminsys qui me disait que Xen/KVM c'était de la merde, la principale raison (selon lui) était que Xen et KVM n'ont pas de support officiel. VMWare édite VMWare, donc si t'as un problème tu peux payer VMWare pour le résoudre. À qui demander si tu veux faire du Xen ou du KVM? Quand je lui ai dis qu'il y avait Red Hat et Citrix, il m'a dis « ouais… mais… » puis il a été vague.

      Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dis « je peux le réparer! »

      • [^] # Re: comparaison avec VMware

        Posté par (page perso) . Évalué à  5 .

        J'ai trouvé ce tableau (il n'y a pas KVM)

        http://www.virtualizationmatrix.com/matrix.php

        Ensuite, il reste le marketing, la pub (se faire connaitre comme une alternative crédible), le support

        Et comme dit précédemment, il y a les habitudes. Il y a quelque temps, j'étais dans une boite dans laquelle ils évaluent des solutions de virtualisation. Finalement ils ont choisi Hyper-V de Microsoft, qui n'était pas le meilleur produit étudié selon eux, mais comme ils ont du Microsoft et les personnes sont formées aux produits Microsoft…

        It would have taken twice as long to build it properly http://www.programmerexcuses.com/

        • [^] # Re: comparaison avec VMware

          Posté par . Évalué à  3 .

          J'ai trouvé ce tableau (il n'y a pas KVM)

          Si , Rhev3.1 c est du kvm

        • [^] # Re: comparaison avec VMware

          Posté par (page perso) . Évalué à  1 .

          Alors ce n'était pas utile de perdre du temps à faire une étude …

          • [^] # Re: comparaison avec VMware

            Posté par (page perso) . Évalué à  3 .

            Ça manque d'infos complémentaire mais ça peut tout à fait se justifier si on considère que la solution MS n'est pas trop des autres pour ce qu'on fait. Ça revient à ajouter une ligne « compétences actuelles » avec une pondération assez élevée.

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: comparaison avec VMware

        Posté par . Évalué à  7 .

        la principale raison (selon lui) était que Xen et KVM n'ont pas de support officiel. VMWare édite VMWare, donc si t'as un problème tu peux payer VMWare pour le résoudre.

        Le problème est qu'à part en payant vraiement très cher, il peut se brosser pour qu'un bug soit résolu.
        L'abonnent standard ne permet que du support. Comme chez Microsoft, Oracle, etc. Et la plupart du temps Google et/ou les bons forums donnent de meilleures réponses en moins de temps. Mais bon, il faut savoir trouver l'information et ce n'est pas donné à tout le monde.

    • [^] # Re: comparaison avec VMware

      Posté par . Évalué à  2 .

      Je ne sais pas ce qui existe en équivalence sous Xen ou KVM, mais niveau administration, il faut avouer que vcenter est assez bien fichu. D'ailleurs si vous avez des suggestions à me faire, parce que c'est le seul avantage qu'a(vait?) VMWare sur les autres solutions de virtualisation.

    • [^] # Re: comparaison avec VMware

      Posté par . Évalué à  4 .

      Je ne connais pas KVM, mais je pratique Xen depuis un petit moment, et du VMWare entreprise Lapeau&descouilles plus récemment. Niveau fonctionnalité pas grand chose sans doute, pour peu de vouloir vraiment plonger dans les entrailles de Xen (ou KVM).

      Par contre niveau interface et gestion des VMs, y compris pour des choses complexes, VMWare c'est royal. L'interface est très accessible, quelque soit le niveau de l'utilisateur. Quand la virtualisation n'est qu'un outil, ça nous arrange que le ticket d'entrée technique ne soit pas élevé. Tous les membres de l'équipe peuvent s'en occuper et ça dégage du temps et des compétences pour d'autres sujets qui en ont besoin.

  • # Comparatif Xen / Kvm en Paravirtualisation

    Posté par (page perso) . Évalué à  0 .

    Je cherche un comparatif détaillé entre Xen et Kvm au niveau des performances et des possibilités de garantir une performance minimal a des VM au niveau des E/S.

    La plupart des articles sur Xen sont vieux (avant la sortie du noyau 3.0 qui a permis a Xen de revenir dans la course)

    Si vous trouvez, je suis preneur.

Suivre le flux des commentaires

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