Journal BHyVe, un hyperviseur natif pour BSD

20
1
déc.
2011

A l'origine, une libération de code

BHyVe est un projet d'hyperviseur pour les systèmes BSD tirant parti des fonctions de virtualisation matérielle des processeurs récents (pour l'instant seul la technologie Intel VT-X est fonctionnelle).

Encore au stade alpha, ce projet est porté par des développeurs FreeBSD et est issu d'une publication de code sous licence BSD de la part de la société NetApp, ce qui mérite d'être souligné.

Peut-être la réponse à un manque

Aujourd'hui, il manque clairement ce type de solution de virtualisation pour FreeBSD. En effet, bien que NetBSD propose un noyau XEN en Dom0, ce n'est pas le cas pour FreeBSD, et BHyVE pourrait bien venir combler ce manque, avec du code pleinement intégré au noyau et au système de base.

BHyVE a pour ambition de devenir l'équivalent de KVM, et si vous disposez d'une machine avec les technologies Intel_VT-x, Extended_Page_Table et optionellement la virtualisation d'entrées/sorties Intel_VT-d vous pouvez d'ores et déjà tester tout celà en suivant ces instructions.

Les liens pour en savoir plus

La page de BHyVE sur le wiki de FreeBSD.org.
Un court article de présentation sur freebsdnews.net.
Le document PDF de NetApp à propos de BHyVE.
Les instructions permettant de tester BHyVE.

  • # Mauvais liens wikipedia

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

    Je me suis trompé avec les liens wikipedia sur Intel_VT-x, Extended_Page_Table et Intel_VT-d.

    J'avais oublié que les markdown pour wikipedia renvoie vers la version française, ou les articles ne semblent pas exister.

    Désolé pour le ratage, chers lecteurs ;)

  • # ça mérite une dépêche

    Posté par . Évalué à 4.

    Un truc sympa, c'est que BHyVE supporte également les pilotes virtio, donc ce qui est un bon point pour les perfs.

    Aujourd'hui, il manque clairement ce type de solution de virtualisation pour FreeBSD

    Et VirtualBox ? Certes, c'est pourrave, mais ça tourne sous FreeBSD.

    • [^] # Re: ça mérite une dépêche

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

      • [^] # Re: ça mérite une dépêche

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

        Pourquoi le moinsser ? Le code en GPL n'est pas assez libre pour les projets BSD, c'est une raison connue et assumée par les développeurs *BSD.

        Quand ils peuvent s'en passer, il préfère le faire, quitte à développer leurs propre implémentation. Et c'est justement l'opportunité de la libération de ce code sous licence BSD qui leur en a donné l'occasion.

        • [^] # Re: ça mérite une dépêche

          Posté par (page perso) . Évalué à 2. Dernière modification le 01/12/11 à 11:55.

          Moi c'est les mots "pas assez libre" qui me gave quand on parle de la GPL...

          Par assez libéral ou trop libertaire serait plus adapté.

          • [^] # Re: ça mérite une dépêche

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

            Pas assez libre du point de vue des BSDistes. Ca me semblait évident dans le contexte (BSD tout ça). Sinon la GPL est assez libre (elle est libre à 100%).

            Ca va mieux?

    • [^] # Re: ça mérite une dépêche

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

      Et VirtualBox ? Certes, c'est pourrave, mais ça tourne sous FreeBSD.

      Tu as déja essayé la cli de virtualbox ?

      • [^] # Re: ça mérite une dépêche

        Posté par . Évalué à 6.

        Tu as déja essayé la cli de virtualbox ?

        Quel est le rapport entre la CLI et la qualité de VirtualBox ? Sinon, oui, j'utilise la CLI de préférence pour installer/piloter mes machines virtuelles (VBox, KVM, Xen, LXC).
        VirtualBox est tellement merdique que les développeurs du noyau Linux ont rajouté le drapeau TAINT_CRAP à cause de lui, pour signaler que le module est de la merde en barre et qu'ils veulent plus recevoir des rapports de bogues automatisés si il est présent. Si VirtualBox est utilisé, c'est surtout parce qu'il a une jolie interface graphique, et quelques additions invités sympas, il aurait été propriétaire qu'il aurait fini droit à la poubelle pour sa nullité technique.

        • [^] # Re: ça mérite une dépêche

          Posté par . Évalué à 2. Dernière modification le 01/12/11 à 14:08.

          C'est aussi parce que pour faire tourner un desktop Windows sous Linux c'est la seule solution libre qui fonctionne.

          • [^] # Re: ça mérite une dépêche

            Posté par . Évalué à 1.

            Virt-Manager fonctionne très bien même pour Windows, et c'est basé sur KVM.

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

            • [^] # Re: ça mérite une dépêche

              Posté par . Évalué à 2.

              Quel humour ! C'est ce qu'on utilise, avec les pilotes SPICE (solution corp), c'est d'une lenteur affligeante au niveau des accès disques, de l'affichage, et Virt-Manager plante environ toutes les 10 minutes donc c'est totalement inutilisable (testé sur Fedora 15 et 16). Virtualbox est peut être mal fichu mais je n'ai pas de plantages et c'est utilisable et rapide.

              • [^] # Re: ça mérite une dépêche

                Posté par . Évalué à 1.

                Oui, c'est un bug connu : les accès disques de Virt-Manager sont excessivement lents sur de l'Ext4, mais avec de l'Ext3 ça fonctionne nickel.

                Une fois que tu sais ça, au niveau fiabilité et performance, je n'ai aucun problème sur une Debian stable.

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

              • [^] # Re: ça mérite une dépêche

                Posté par . Évalué à 4.

                Quel humour ! C'est ce qu'on utilise, avec les pilotes SPICE (solution corp)

                Tu dois parler de virtio, effectivement comme le dit le collègue ci-dessus, c'est un bug ext4 mais même avec VirtualBox, c'est la solution la plus efficace pour les I/O (disque et réseau) y compris sous VirtualBox.
                Quant à Spice, c'est du VDI et c'est nettement plus efficace que du VNC ou du RDP avec quelques goodies sympa.

                Virt-Manager plante environ toutes les 10 minutes donc c'est totalement inutilisable (testé sur Fedora 15 et 16)

                J'utilise la CLI (virsh) avec libvirt et vinagre pour la visualisation, mais aucun de mes développeurs n'a eu de soucis avec virt-manager pour accèder aux machines virtuelles.

                Virtualbox est peut être mal fichu mais je n'ai pas de plantages et c'est utilisable et rapide.

                VirtualBox me corrompt régulièrement la mémoire et se fait tatanner la gueule par le noyau. Utilisable dans un cadre non-industriel, oui, rapide, pas du tout.

              • [^] # Re: ça mérite une dépêche

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

                Je suis assez surpris, j'ai pas vu de plantage du tout, et je me sert lourdement de virt-manager. Que l'interface soit à revoir à certains endroits, je suis d'accord, mais c'est aussi pour ça que boxes a été lancé.

          • [^] # Re: ça mérite une dépêche

            Posté par . Évalué à 3.

            J'ai jamais eu de pb avec KVM. Sauf pour l'accès aux fonctions avancées des cartes graphiques évidemment. Mais autrement, marche nickel et sans lenteurs.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: ça mérite une dépêche

              Posté par . Évalué à 1.

              Je parle déjà en utilisation bureautique classique saisie de texte dans word/powerpoint, défilement de page, déplacement de fenêtres sur VB ça tourne comme en natif, avec KVM il y a des latences et des lenteurs qui rendent l'utilisation pénible.

          • [^] # Re: ça mérite une dépêche

            Posté par . Évalué à 2.

            KVM pour les serveurs (pour les performances)

            VirtualBox pour un desktop avec bonnes perfs graphiques si tu veux du libre

            VMware Player / Workstation pour un desktop avec excellentes perfs graphiques si tu veux absolument le meilleur sans te soucier de la licence

    • [^] # Re: ça mérite une dépêche

      Posté par . Évalué à 1.

      Ça sait faire hyperviserur VB ? il ne me semblait pas…

  • # Pourquoi pas Xen ?

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

    NetBSD arrive à intégrer Xen, avec un nombres de développeurs énormes (au moins deux personnes), et pire français (donc probablement des feignants) (coucou bouyer@ and jym@ :D).

    Donc pourquoi les autres systèmes n'arrivent pas à intégrer Xen ? et préfère réimplementer des solutions "from scratch" ?

    • [^] # Re: Pourquoi pas Xen ?

      Posté par . Évalué à 2.

      licence ?

    • [^] # Re: Pourquoi pas Xen ?

      Posté par . Évalué à 2.

      Parce que Xen fait de manière logicielle ce que les processeurs peuvent maintenant faire nativement. Si tu prends des benchmark Xen vs KVM, tu verra que le second est plus performant, et plus universel (pas besoin d'adapter l'OS en domu). Et ce n'est qu'un avis personnel, mais kvm est bien plus simple à administrer.

      • [^] # Re: Pourquoi pas Xen ?

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

        Parce que Xen fait de manière logicielle ce que les processeurs peuvent maintenant faire nativement
        Tu peux détailler ?

        Si tu prends des benchmark Xen vs KVM, tu verra que le second est plus performant

        Dans la vraie vie avec plein d'io, j'ai comme un doute.

        pas besoin d'adapter l'OS en domu

        Oui enfin ça c'est la théorie parce que sans virtio c'est légèrement mou.

        Et ce n'est qu'un avis personnel, mais kvm est bien plus simple à administrer.

        La je suis d'accord

      • [^] # Re: Pourquoi pas Xen ?

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

        Parce que Xen fait de manière logicielle ce que les processeurs peuvent maintenant faire nativement.

        J'ai comme un doute http://wiki.xen.org/xenwiki/XenIntro.html#head-d945d0dd0a57135909a3beae9a74e15095af77fb

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Pourquoi pas Xen ?

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

      Donc pourquoi les autres systèmes n'arrivent pas à intégrer Xen

      Sous FreeBSD la question s'est posée. La support de Xen n'est pas exclue pour des raisons philosophiques, c'est juste que pour l'instant, il n'y a personne pour le faire.

      et préfère réimplementer des solutions "from scratch" ?

      La solution choisie se base sur virtio. Elles est donc compatible avec au moins kvm et virtualbox. En l'occurrence ici c'est xen qui fait bande à part.

  • # Que Intel? Dommage.

    Posté par . Évalué à 2.

    Je suis étonné de voir que le code n'est pas le même pour la virtu AMD et la virtu Intel.

    C'est dommage d'avoir commencé par Intel, d'autant plus que:

    • Contrairement à Intel, AMD ne segmente pas artificiellement ses CPU en faisant payer plus cher la virtualisation. C'est dispo en standard à partir d'une certaine gamme,
    • C'est AMD qui a lancé les instructions de virtualisation sur x86_64, en même temps que la technologie x86_64 d'ailleurs (appelée aussi AMD64).

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Que Intel? Dommage.

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

      Je pense que, étant donné que le code viens à l'origine de NetApp, ceux-ci n'avaient intégré que les fonctionnalités du matériel dont ils se servaient et qui devait être du Intel.

      La prise en charge des instructions AMD-V et AMD-Vi est bien prévue (cf. le PDF), et j'imagine que c'est une priorité, ne serais-ce que pour disposer d'une plus large base de testeurs.

    • [^] # Re: Que Intel? Dommage.

      Posté par . Évalué à 3.

      C'est AMD qui a lancé les instructions de virtualisation sur x86_64, en même temps que la technologie x86_64 d'ailleurs (appelée aussi AMD64).

      marrant ca, j'ai eu un athlon64 3500+
      c'etait bien un AMD64 et ca tournait avec un linux x86_64 dessus
      mais je n'ai jamais eu la virtualisation materielle dedans.

      • [^] # Re: Que Intel? Dommage.

        Posté par . Évalué à 1.

        Elle était pas désactivée au BIOS? Je l'ai eu sur un Athlon64 4200+, avec comme seule différence avec le tien la fréquence plus élevée.

        Par contre beaucoup de BIOS désactivent la virtu par défaut. Ou alors peut-être que la CM ne la prenait pas en compte.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Commentaire supprimé

        Posté par . Évalué à 4.

        Ce commentaire a été supprimé par l'équipe de modération.

  • # BSD vs GPL

    Posté par . Évalué à 7.

    Fichtre ! Une boîte qui a basé son produit sur un BSD et qui reverse du code à la communauté sans y être forcé ! C'est une grande première qui chamboule tout. Le troll BSD vs GPL va-t-il en faire les frais ? Ah non, on me dit dans mon oreille que Juniper, Isilon ou iX Systems font ça depuis un bail et que ça changeait rien...

    • [^] # Re: BSD vs GPL

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

      En fait pour ma part, je ne suis pas étonné de cette libération de code.
      Si j'ai voulu souligner ce fait, c'est par rapport aux arguments lors des trolls sur les licences prétendant qu'avec la licence BSD, les "vilaines sociétés capitalistes volent du code Libre sans rien donner en retour, et en plus ils mangent des enfants".

      Voilà donc un exemple, bien réel parmi d'autres, de libération de code de la part d'une société intégrant du code sous Licence BSD dans ses produits commerciaux.

      Cette précision dans le journal n'avait aucun but trollifère.

      • [^] # Re: BSD vs GPL

        Posté par . Évalué à 4.

        La principale différence est que la GPL oblige les vilaines sociétés capitalistes à reverser le code modifié, pas la BSD mais personne n'a jamais dit que personne ne reversait du code modifié aux projets BSD. C'est deux visions différentes du libre mais tout autant légitime l'une que l'autre.

        • [^] # Re: BSD vs GPL

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

          La principale différence

          J'ai toujours du mal à rentrer dans les trolls GPL vs BSD, vu que les deux sont du libre (libre software ou OSI, les deux étant équivalents). La BSD a de nombreux avantages, surtout pour du code interprété et pour sa compatibilité avec plus d'autres licences que la GPL dont la notion d'héritage dérange certains (heureusement il y a la LGPL pour conserver ce qui est publié en libre, même au travers des redistributions).

          C'est bien d'avoir des exemples où la BSD démontre son intérêt à faire perdurer le libre dans les domaines où elle pourrait a priori paraître plus faible que la GPL.

Suivre le flux des commentaires

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