A native hypervisor is coming to OpenBSD

CW

Netswimmer
[...]
For the last few months, I've been working on a hypervisor for OpenBSD.
The idea for this started a few years ago, and after playing around with
it from time to time, things really started to take shape around the
time of the Brisbane hackathon earlier this year. As development
accelerated, the OpenBSD Foundation generously offered to fund the
project so that I could focus on it in more earnest.

[...]

https://marc.info/?l=openbsd-tech&m=144104398132541&w=2
 
Hehe, mal sehen wie die Antwort von Theo sein wird :-)

Soweit ich weiß hat Er immer Hypervisor abgelehnt (teils zurecht)

Aber es wäre schön wenn OpenBSD endlich auch einen Hypervisor bekommt.
 
Wenn die OpenBSD Foundation Geld ausgespuckt hat, hat Theo es schon gebilligt, oder nicht?
 
Ich kann nur einen Teil der Argumentation verstehen. Ein eigener Hypervisor muss entwickelt werden, weil bestehende Projekte i386 nicht mehr unterstützen, und dann unterstützt dieser Hypervisor auch nur zwei Plattformen?
 
Naja, mit ein Grund wird gewesen sein, dass Theo keinen Herzkasper bekommt, wenn der hört, dass da jemand einen Hypervisor portiert hat.
Wenn man sagt, "der ist nur für Dich geschrieben" wird er zwar Puls bekommen aber vielleicht nicht durchdrehen :D
 
Ich finde es ehrlich gesagt ganz gut das da nichts portiert wurde, die meisten sachen die es so unter linux sind zwar okay, aber imho oft sehr unübersichtlich dokumentiert.
 
Diese Nachricht war ganz klar diejenige, über die ich mich auf undeadly seit längerem am meisten gefreut habe - und dabei sind in letzter Zeit einige interessante Entwicklungen bei OpenBSD zu registrieren (httpd, doas, ...)! Theos Abneigung gegen Virtualisierung ist ja bekannt, weshalb ich einer solchen Entwicklung nicht besonders große Chancen eingeräumt hätte. Nun ist es aber natürlich desto erfreulicher, daß entweder Theo über seinen Schatten gesprungen ist und eine Notwendigkeit unserer Zeit anerkennt, oder sich andere durchgesetzt haben.

Ich hatte OpenBSD gerne auf einem Klappi, der damit überwiegend sehr gut funktionierte. Letztlich fehlte mir aber zu sehr die Möglichkeit, Vagrant verwenden zu können und Puffy mußte vorerst wieder weichen. Freue mich schon sehr darauf, in der Zukunft VMM testen zu können. Sahnehäubchen wäre natürlich, wenn Vagrant es als Provider unterstützen würde! Aber auch so wird das sicherlich eine sehr nette Sache.
 
Nee, das Sahnehäubchen wäre Portabilität. Schade.

Grundsätzlich würde ich sagen, steht OpenBSD in Sachen Portabilität ihrer Projekte sooo schlecht nicht da. Inwieweit das bei einem Hypervisor zu machen ist, ohne Konzessionen machen zu müssen, die man vielleicht nicht zu machen bereit ist, kann ich nicht beurteilen. Ich sehe aber nicht viele Systeme, die Interesse an einem portablen Hypervisor von OpenBSD hätten. FreeBSD hat immerhin seinen eigenen, um den (sicher zurecht) einiges an Rummel gemacht wurde (und ob die i386-Nutzerschaft von FreeBSD so groß ist, daß da viel Interesse bestünde, darf wohl bezweifelt werden). Und Linux hat fraglos bereits genügend Auswahl. Was bliebe? Andere kleinere BSDs. Wäre bestimmt nett - rein vom Gefühl her wäre das aber erheblicher Aufwand für geringen Nutzen.
 
Sagen wir mal so. Der Vorteil eines gut in den Host-Kernel integrierten Hypervisors besteht darin, dass er seine Hardware- und Ressourcenverwaltung mit diesem Teilen kann. Er kann eng mit dem Host-Scheduler interagieren. Er kann gegenüber dem VM exakt jenen Speicher als belegt markieren, den der Gast auch wirklich nutzt. Er kann die Caches wie den Dateisystemcache steuern. Und so weiter. Das führt im Vergleich zu "aufgesetzten" Hypervisoren zu einer deutlich besseren Ressourcenauslastung. Man vergleiche nur mal den RAM-Verbrauch des gleichen Gastes aus Sicht des Hosts, wenn er in Bhyve und Virtualbox läuft. Oder in der Linuxwelt gerne, wenn auch weniger krass, Qemu mit KVM gegen die VMWare Workstation.
Nur eine Integration in den Kernel bedeutet eben auch, dass sich eine enge Abhängigkeit zwischen diesem und dem Hypervisor ergibt, was einer guten Portabilität im Weg steht. Und so muss man abwägen. Legt man auf Portabilität wert und ist bereit den Preis in Sachen Abstraktion und geringerer Integration zu zahlen, oder verzichtet man darauf? In der Praxis wählt man oft den Verzicht, denn man schreibt schließlich einen Hypervisor für exakt ein Host-System...

Ich habe hier in meinen Lesezeichen noch diesen alten Blob-Post zu KVM auf IllumOS gefunden. Er zeigt schön, wie aufwändig der Port der gar nicht portablen KVM war: https://smartos.org/2011/08/15/kvm-on-illumos/
 
man schreibt schließlich einen Hypervisor für exakt ein Host-System...

..., der in diesem Fall offenbar ohne wirklichen technischen Grund auf einigen Plattformen, mit deren Unterstützung dieses Host-System wirbt, läuft und auf anderen nicht, was etwas schade ist.
 
<KetzerModus> haette man nach dem ipfilter Drama dann "besser" iptables "portiert" statt einen "unportablen" pf zu schreiben? </KM> ;-)
 
..., der in diesem Fall offenbar ohne wirklichen technischen Grund auf einigen Plattformen, mit deren Unterstützung dieses Host-System wirbt, läuft und auf anderen nicht, was etwas schade ist.
Naja, so ein Hypervisor ist auch sehr abhängig von der Host-Architektur. Das Drama geht schon auf hoher Ebene mit den unterschiedlichen Wegen Virtualisierung in Hardware zu unterstützen los. Selbst wenn man Dinge wie ARM vs. x86 (ARMs HYP-Mode soll eine mittlere Ekligkeit sein) außen vor lässt, sind dann dort AMD und Intel mit jeweils eigener Suppe. Die älteren Inkarnationen der Architekturen quälen Entwickler dann noch stark eingeschränkten Features. Zum Beispiel ist i386s Pagetable etwas "knapp", diplomatisch ausgedrückt. Man kommt mit PAE etwas weiter, was dann aber wieder andere Ekligkeiten nach sich zieht... In sofern ist schon verständlich, dass sich Entwickler auf die wahrscheinlichsten Einsatzszenarien konzentrieren. FreeBSDs Bhyve läuft daher nur unter FreeBSD/amd64 mit voller Hardwareunterstützung und eventuell bald auf FreeBSD/arm64. Wenn ich es richtig verstehe, bleibt OpenBSDs VMM auch erstmal auf x86 in beiden Flavors...
 
Innerhalb vbox braucht man sich da noch nicht bewegen:
uvm_fault(0xffffff001f710c00, 0x60, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at vmmioctl+0x18: movl 0x60(%rcx),%r8d
ddb>
 
Zurück
Oben