bhyve - was ist zu erwarten?

SchaubFD

Member
Hallo,

ich habe bhyve bisher noch nicht eingesetzt. Mich würde interessieren, welche Vorteile und Nachteile es gegenüber KVM hat. Ist KVM unter FreeBSD sinnvoller als bhyve. Mich würde interessieren wie die Unterstützung der Gastbetriebssysteme aussieht, hier speziell Windows, Linux und OmniOS. Ich benötige Audio und Video Wiedergabe des VM Clients auch auf Remote für (Linux/Windows/FreeBSD). Gibt es einen Zugriff über z.B. Spice oder ähnliches?

Das einige Dinge nicht gleich gehen ist nicht schlimm, nur würde ich wirklich gerne mal auf einer VM Plattform alles laufen lassen. Bisher wechsele ich permanent zwischen verschiedenen Platformen hin und her und bin irgendwie nicht zufrieden. Ich möchte ungern einen Mischmasch aus ESXi, Xen oder Proxmox mit Plattendurchgriff vermeiden.

Ich würde wirklich gerne bei FreeBSD bleiben, mir fehlt aber bei ZFS die SMB Kernel und Spare Platten Funktion eines Illumos/OmniOS Systems oder auf der anderen Seite etwas mehr Unterstützung ähnlich Linux. Dinge wie Bildschirmtreiber, etwas bessere Dateisystemunterstützung. Klar, ein Optimum wird es noch nicht geben, aber ich möchte nicht permanent uminstallieren. Ich wäre froh, wenn man hier nach und nach auch für andere die dies interessiert eine Lösung bekommen könnte, Danke!
 
Ich habe auch lange gesucht und muss sagen, dass ich mittlerweile bei Proxmox angekommen bin.

Mein "dicker" Server hat die beiden LSI-Controller (3008 onboard | IBM 1015 geflashed) an eine FreeNAS-VM durchgereicht, so dass für alle wichtigen Daten ZFS anliegt.
Den Rest mache ich mit VMs (Mischung aus FreeBSD und Linux).

Als Root-FS hab ich ZFS bei Proxmox - für das Cluster (noch zwei "kleinere" Server) Ceph.
Läuft einwandfrei und die Verwaltung läuft über die Webgui.

Ich glaube Spice gibts auch...
Gruß
Markus
 
Danke Markus, auch wenn deine Lösung für Dich gut funktioniert, ich will diese nicht schlecht machen. Bitte korrigiere mich, wenn ich etwas falsch sehe. Proxmox ist Linux mit KVM, ZFS ist dann entweder vom Linux Kernel abhängig (Proxmox) oder es muss an die FreeNAS VM durchgereicht werden, was wieder eine Art gegenseitige Abhängigkeit hat. Ich würde gerne ZFS und Hypervisor direkt im Betriebssystem nutzen. Dann braucht es auch nur ein KVM oder bhyve neben ZFS. Was war aber der Grund eine solchen Lösung für Dich? Einen Grund wirst du gehabt haben.
 
Ich weiß nicht, ob ich die Frage richtig verstehe. Unter FreeBSD hat man im Moment realistisch gesehen die Wahl zwischen 2 Hypervisor: VirtualBox als der Klassiker und Bhyve als das coole, neue Kind in der Stadt. Theoretisch kann FreeBSD noch Xen Dom0 spielen, aber der Support dafür ist wohl recht wackelig. KVM ist mal experimentell auf FreeBSD portiert worden, das Projekt wurde allerdings nicht weiterverfolgt. Man kann qemu allerdings als reinen, entsprechend langsamen Emulator nutzen.

Zu VirtualBox muss man wohl nicht viel sagen. Das Ding erfüllt im Großen und Ganzen seinen Zweck, ist allerdings recht ressourcenintensiv (der weniger nette Ausdruck ist "ineffizient") und die Qualität verschiedener Versionen ist schwankend. Die Integration in FreeBSDs Basissystem lässt zu wünschen übrig, gerade die Netzwerkintegration ist aufwändig. Ich habe mehrere Windows Server 2012 R2 auf VBoxHeadless laufen, es funktioniert stabil und zuverlässig.

Bhyve ist direkt für FreeBSD entwickelt worden, er integriert daher eng in das Basissystem. So kann Bhyve zusammen mit ZFS Volumes TRIM nutzen, belegt also nur tatsächlich benötigten Speicherplatz. Er ist sehr ressourceneffizient, kommt auch in Situationen mit wenig verfügbaren RAM noch gut zurecht. Und er kann auf FreeBSDs Netmap Usermode-Netzwerkstack und den zugehörigen VALE-Switch zugreifen. Aber Bhyve unterscheidet sich von der Konzeption her etwas von anderen Hypervisorn:
  • Byhve versucht so schlank und legacyfrei wie möglich zu sein. Er emuliert nur das absolute Minimum an Hardware, greift ansonsten auf das VirtIO-Interface zurück.
  • Bhyve benötigt eine CPU mit vollständiger Hardwarevirtualisierung. Bei Intel ist man ab Sandy Bridge auf der sicheren Seite, davor kommt es auf die CPU drauf an.
  • Derzeit gibt es keine Grafikausgabe, nur eine serielle Konsole. Das reicht eigentlich. Wahrscheinlich wird mit FreeBSD 11.0 eine VNC-Brücke kommen.
Ob Bhyve für die eigenen zwecke ausreicht, muss jeder für sich entscheiden. Mit einem Wrapper wie iohyve ist es einfach zu benutzen, unterstützt alle wichtigen Betriebssystem. Oder wie ein überzeugter CentOS-Nutzer sagte: "Holy crap that's fast!"
 
Ok, also wäre ich mit FreeBSD zumindest zur Zeit und bei dem was ich vor habe leider nicht auf der richtigen Seite. Finde die Antwort wenigstens ehrlich. Bleibt für mich die Frage, welches OS sollte man sonst nehmen. Geht man von BSD in Richtung Illumos/OmniOS ggf. SmartOS wird es ggf. zwar mit dem Hypervisor etwas besser, aber es ist halt pur und ich brauche dringend Audio und Video remote. Ich möchte von nativen Windows weg und es wäre schön wenn man Linux auch mit Audio/Video virtualisieren könnte. Geht man in Richtung Linux, dann hat man mit den Kernel Updates Probleme oder man bleibt beim Kernel, dann darf man kein Rolling Release nutzen. Bliebe KVM wie es Markus sagte, dass er über Proxmox nutzt. Ich würde aber gerne auf jeglichen teils geschäftlich genutzten Überbau verzichten und ich möchte auch nicht Platten durchreichen wenn möglich wegen ZFS. Also doch auf Linux bleiben und bei passender Gelegenheit wieder zu FreeBSD wechseln ...

Ja Virtualbox Headless ... läuft, wäre auch ein letzter Ausweg, oh Mann. Virtualbox hat kein Spice denke ich und nur Windows Clients hätten dann RDP. Ich kenne NX oder andere Remote Dienste noch nicht so gut in dem Umfeld.
 
Bei Video und Audio in der virtuellen Maschine würde ich als erstes an den ESXi von VMware denken. Ist für Privatzwecke auch kostenlos...
 
es wäre auch möglich auf die neue ubuntu 16.04 mit zfs und Xen da wäre dann auch alles möglich.

aber sonst würde ich das Trennen 1x server Freebsd als Storage mit NFS vielleicht noch smb/iSCSI
und daran wird der Virtualisierer deines vertrauens angebunden, bei mir ist das ein ESXI.

das Läuft super schnell :).
 
Ich habe mir damals die verfügbaren Lösungen angeschaut und getestet.

Anforderungen: Hochverfügbarkeit, eine Gui, ausreichende Doku, regelmäßige Updates und die Möglichkeit KVM / HVM o.ä. zu verwenden.
MIt Proxmox funktioniert das alles.

Meine Synology habe ich durch eine FreeNAS-VM abgelöst, die über "durchgereichte" Controller die Festplatten direkt anspricht - Proxmox sieht die Datenplatten überhaupt nicht.
Als restliche VMs laufen einige FreeBSD-VMs (Proxy / Jumphost in der DMZ, Web- und Dev-Server), eine Firewall unter pfSense, einige Linux-Container...

Bisher kann ich mich weder über Performance noch Komplexität beschweren. Alles läuft so wie es soll.

Falls mir etwas passieren sollte kann die Umgebung durch Umstecken eines Kabel (Doku "rotes Kabel") und Einstecken eines USB-Sticks so umgebaut werden, dass nur noch FreeNAS auf dem dicken Server läuft und meine Frau an alle Daten kommt, sowie das Internet über einen handelsüblichen Router bereitgestellt wird -> Jeder unser "technikafineren Bekannten / Verwandten" kann ab dann meine Frau "supporten".

Gruß
Markus
 
Ich habe auch lange gesucht und muss sagen, dass ich mittlerweile bei Proxmox angekommen bin.
...
Markus

Hallo Markus,

eine Rückfrage zwecks näheren Verständnisses: Du nutzt Proxmox NICHT als Virtualisierer unter FreeBSD, sondern bspw. unter Windows, um als GUEST FreeBSD laufen zu lassen?

Ich frage nach, weil Proxmox für FreeBSD offensichtlich weder als Port noch als Package existiert.

Danke und viele Grüße
testit
 
Proxmox ist nicht ein Virtualisierungs-Programm (ala Virtualbox) was auf einem vorhandenem Betriebssystem läuft, sondern eine komplettes Virtualisierungssystem (ala VMWare ESXi oder Microsofts HyperV) basierend auf einem optimiertem und erweitertem Linux Betriebssystem (afaik Debian) und wird auf eine leere Festplatte installiert.
Es nutzt Linux-Container und Qemu um die virtuellen Umgebungen bereitzustellen; in welche dann die zu virtualisierenden Betriebssysteme installiert werden können.
Wenn du mit FreeBSD als Basissystem etwas virtualisieren willst, bleiben dir nur Jails, Bhyve, Qemu oder Virtualbox.
 
Anfangs war ich etwas zu ängstlich bzgl. "Beih Vieh" - und nahm virtualbox um beruflich dringend benötigte Windows Gäste verfügbar zu haben.
Nach nun gut einem Jahr Erfahrung mit VirtualBox, sowohl unter 10.3 als auch 11 ... muss ich sagen: es läuft - aber es gibt zu viele Ecken und Kanten unter BSD. Es gibt und macht einfach zu viele Probleme.
Es ist halt irgendwie aus der linuxwelt mal mehr, mal weniger "schlecht als recht" ins BSD eingebastelt.

Inzwischen hab ich erste Erfahrungen mit bhyve - hab einen Win10 Gast in einem zfs-Dataset unter FreeBSD11 laufen, den ich mit dem Viewer von TigerVNC connecte.

Performance kann ich schlecht vergleichen - da unter VirtualBox ein 32Bit Win7 lief und ich jetzt mit Bhyve Win10 virtuell am Laufen hab

Aber meine ersten Erfahrungen und Eindrücke sind zusammengefasst formuliert: Es passt!
 
Guten Morgen!

@cla: Herzlichen Dank für die Klarstellung, dass es sich bei Promox um einen Bare-Metal-Hypervisor handelt. Hört sich trotzdem so interessant an, dass ich das mal testen möchte.

@Vril: Ich habe bislang VirtualBox "nur" für weitere FreeBSD-Gastsysteme genutzt und keine Probleme feststellen können. Trotzdem möchte ich gerne bhyve ausprobieren.

Ich finde phpVirtualBox als GUI für VirtualBox ganz angenehm. Für bhyve gibt es wohl derzeit nur virt-manager, oder habe ich etwas vergleichbares übersehen?


Viele Grüße
testit
 
Guten Morgen!

@Vril: Ich habe bislang VirtualBox "nur" für weitere FreeBSD-Gastsysteme genutzt und keine Probleme feststellen können...
Ich finde phpVirtualBox als GUI für VirtualBox ganz angenehm. Für bhyve gibt es wohl derzeit nur virt-manager, oder habe ich etwas vergleichbares übersehen?


Viele Grüße
testit

Also ich komme sehr oft in die Verlegenheit erstmal ~/.Xauthority löschen zu müssen, damit VB überhaupt startet ... desweiteren habe ich immer wieder Konflikte beim Bauen von Ports aufgrund Abhängigkeiten von VB.
Oft ist es auch so, dass der win-Gast startet - und nach 10 - 15 Min der ganze Mist crasht - und das VB Fenster sagt: " abgebrochen"

Ich muss ehrlich sagen, dass ich auch gar keine Lust mehr hab - hier Zeit und Mühe in die Ursachenforschung zu investieren.

phpVirtualBox kenne ich gar nicht - und virtManager auch nicht.

Ich will die Kontrolle über die Dinge selbst behalten - und starte " BeihVieh " mit eigenen Script, dass im ~/.fluxbox/menu eingetragen ist und dessen Start auf FluxBox inclusive vncviewer mit Mausklick getriggert wird.

Gruß Walter
 
Freiwillig per VNC? Besser wäre es doch den Remote Desktop auf der Windows VM zu aktivieren und dann per IP via RDP zu verbinden. Das ist viel schneller als VNC.


Ah o.k. - Danke fuer die Info, Foxit

ich hatte irgendwo im englischen BSD-Forum was gelesen, dass RDP manchmal irgendwelche Probleme macht -
und war deshalb bei VNC geblieben, ohne RDP mal ueberhaupt zu probieren.

Aber dann werde ich mal pkg install -y freerdp starten :-) ..und 'mal selbst probieren.

Gruss walter
 
Ist bhyve ein Typ 1 oder Typ 2 Hypervisor? Also ähnlich wie Xen mit Dom0/DomU oder mehr mit KVM + qemu + Virtualbox verwandt?
 
Wobei die Unterscheidung zwischen Typ 1 und Typ 2 aus den 1970ern kommt und sich so heute nicht mehr unbedingt aufrechterhalten lässt. Auch die meisten als Typ 1 verkauften Lösungen beinhalten entweder den größten Teil eines Betriebssystem oder benötigen zwingend ein vollwertiges Betriebssystem in Form einer privilegierten Instanz.
 
Xen gibt's mittlerweile übrigens auch für FreBSD, nur weil das hier im Thread in ein paar Aufzählungen nicht drin ist und allmählich sind da auch die rauen Kanten draußen. Gab ja nach dem 11.0er Release ein paar Erratas.

Zu Typ 1 und Typ 2 muss man sagen, dass da häufig auch Schindluder getrieben wird, bei Vor- und Nachteilen. Zumindest sieht man da immer mal wieder Behauptungen, die einfach mit der Realität nichts zu tu haben. Also gerade wenn's um so Themen, wie Security geht und wie sehr stark/gut was vermeintlich isoliert ist. Im Namen von Performance und im Namen von alles als virtuelles Device zu haben, was ja beides valide ist hat da schon öfters mal Security den kürzeren gezogen.

Und ganz generell macht diese Unterscheidung für den User nicht mehr so richtig sind, weil den meisten Aussagen ein "es sei denn" dran hängen kann. Ich sage das nur, weil ich selbst genau so wie so ziemlich jeden den ich kenne es da ähnlich erging und es große Erleuchtungen gab, wenn man sich mehr mit der Materie befasst hat und diesse Technologien dann nicht nur als Black Box sieht. Nur so als Tipp: Einfach nach tatsächlich verstandenen und benötigten Features/Anwendungsfällen gehen und nicht zu sehr Erwartungshaltungen aufbauen. Ist zwar generell gut, aber für Virtualisierung noch mehr als für manch andere Systeme.

Vielleicht hat meinte Yamagi das, aber es ist aus vielen Gründen mehr "blurred", als es mal war. Deshalb einfach den Fokus auf das tatsächlich greifbare legen bei Entscheidungen was man nun nimmt. :)
 
Meine Argumentation wäre: Als in den 1970ern die Definition von Typ 1 und Typ 2 geschaffen wurde, waren die Computer trotz ihrer physischen Größe wesentlich weniger komplex als moderne Systeme. Das betraf die Hardware, die Software und auch die frühen Hypervisor. Ein Typ 1 Hypervisor konnte damit genau das sein, was die Definition besagt. Hardware -> Hypervisor -> Betriebssystem. Moderne Computer sind aber wesentlich komplexer. Dazu kommt, dass die heute gängigen Architekturen wie x86 bereits 25 und mehr Jahre technische Altlasten ansammeln konnten, bevor man überhaupt begann sich über Virtualisierung Gedanken zu machen. Das macht es sehr schwer eine Virtualisierung sauber in die bestehende Architektur einzufügen. Hypervisor wurden dadurch wesentlich komplexer und mussten Aufgaben des Betriebssystems übernehmen. Dadurch wurde Typ 1 eher zu Hardware -> Hypervisor mit versteckten Betriebssystem -> Betriebssystem.

ESXi zum Beispiel ist zwar nicht auf auf Linux aufgebaut, enthält aber größere Teile von Linux, um Linux-Treiber für die Hardware und architekturabhängigen Code einbinden zu können. Oben drauf läuft ein Busybox. Xen und HyperV machen es offensichtlicher, sie haben einen privilegierten Gast, welcher eine Reihe Aufgaben übernimmt. Führt man diese Argumentation weiter endet man bei der Frage, ob ein regulärer Linuxkernel nicht auch zu einem Typ 1 Hypervisor wird, wenn die KVM-Module geladen sind. Das Gleiche gilt für FreeBSD mit vmm.ko. Und wenn nicht, ist FreeBSD + Bhyve ein Typ 1 Hypervisor, wenn wir das FreeBSD gut verstecken, sodass es zwar vorhanden, aber für den Anwender nicht sichtbar ist? Aufgrund dieser Definitionsschwierigkeiten sollte man in meinen Augen diese alte Unterscheidung endlich beerdigen.

Dazu kommt das Thema hardwareunterstützte Virtualisierung. Einen reinen softwareseitigen Hypervisor zu bauen ist für x86 sehr, sehr schwer. In den Anfangsjahren konnten das nur sehr wenigen Organisationen, VMwares bis heute hohe Verbreitung kommt aus der Zeit. Da will man eine möglichst definierte Umgebung, es ist also sinnvoll den Hypervisor in einer klar spezifizierten und entsprechend entsprechend berechenbaren Umgebung zu positionieren. Und dennoch sind reine Softwarelösungen bis heute fehleranfällig, es vergeht z.B. gefühlt kaum ein Monat in dem nicht neue kritischen Lücken in Xens PVM gefunden werden. Mit hardwareunterstützer Virtualisierung ist das alles wesentlich einfacher. VT-d und SVM stellen virtuelle Prozessoren zur Verfügung, Nested Pagetables machen es einfach den Arbeitsspeicher zu separieren und so weiter. Damit sind Hypervisor letztendlich nur noch schlanke Wrapper um die Hardwareunterstützung. Solange die Hardware sauber arbeitet, ist es damit weitgehend egal wo sie im Stack platziert werden.
 
Zurück
Oben