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 Laurent Cligny (site web personnel) . É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 GeneralZod . Évalué à 4.
Un truc sympa, c'est que BHyVE supporte également les pilotes virtio, donc ce qui est un bon point pour les perfs.
Et VirtualBox ? Certes, c'est pourrave, mais ça tourne sous FreeBSD.
[^] # Re: ça mérite une dépêche
Posté par Zenitram (site web personnel) . Évalué à 3.
Pas assez libre
https://www.virtualbox.org/wiki/GPL
vs
http://svnweb.freebsd.org/base/projects/bhyve/COPYRIGHT?view=markup
[^] # Re: ça mérite une dépêche
Posté par Laurent Cligny (site web personnel) . É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 gnumdk (site web personnel) . Évalué à 2. Dernière modification le 01 décembre 2011 à 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 Zenitram (site web personnel) . É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 Joris Dedieu (site web personnel) . Évalué à 2.
Tu as déja essayé la cli de virtualbox ?
[^] # Re: ça mérite une dépêche
Posté par GeneralZod . Évalué à 6.
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 Laurent Mouillart . Évalué à 2. Dernière modification le 01 décembre 2011 à 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 zebra3 . É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 Laurent Mouillart . É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 zebra3 . É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 GeneralZod . Évalué à 4.
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.
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 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 Misc (site web personnel) . É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 Grunt . É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 Laurent Mouillart . É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 MTux . É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 Enjolras . Évalué à 1.
Ça sait faire hyperviserur VB ? il ne me semblait pas…
# Pourquoi pas Xen ?
Posté par zul (site web personnel) . É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 RB . Évalué à 2.
licence ?
[^] # Re: Pourquoi pas Xen ?
Posté par GeneralZod . Évalué à 4.
Xen c'est de la GPLv2
[^] # Re: Pourquoi pas Xen ?
Posté par MTux . É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 Joris Dedieu (site web personnel) . Évalué à 2.
Dans la vraie vie avec plein d'io, j'ai comme un doute.
Oui enfin ça c'est la théorie parce que sans virtio c'est légèrement mou.
La je suis d'accord
[^] # Re: Pourquoi pas Xen ?
Posté par claudex . Évalué à 3.
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 Joris Dedieu (site web personnel) . Évalué à 3.
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.
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 Grunt . É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:
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Que Intel? Dommage.
Posté par Laurent Cligny (site web personnel) . É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 NeoX . Évalué à 3.
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 Grunt . É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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# BSD vs GPL
Posté par vjm . É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 Laurent Cligny (site web personnel) . É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 GeneralZod . É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 BAud (site web personnel) . Évalué à 4.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.