Linux als VirtualBox Quasi Typ I Hypervisor

Mloki schrieb:
es soll kein einfaches Minimalsystem sein, was alles mögliche an Tools installiert hat, die Speicher durch Festplattenplatz/Verlinkungen belegen und insgesamt das System belasten, da sie eben registrierte Komponenten sind, die meiner Erfahrung nach immer ihre Spuren hinterlassen, wenn man sie nachträglich entfernt.
Das ist ein Fehlschluss - zumindest in der Linuxwelt. Bei Deinstallation unter Windows bleiben häufig geteilte Bibliotheken, Registry-Einträge, Services, usw. zurück.
Es gibt aber unter Linux keine Registry. Konfigurationsdateien werden meist einfach nur als .conf-Dateien im selben Verzeichnis gespeichert. Löscht du den entsprechenden Ordner, dann ist auch das gesamte Programm entfernt.
Außerdem installierst du Programme (je nach Distribution) fast ausschließlich in der Paketverwaltung. Die sorgt bei der Installation für alle Abhängigkeiten und kann abschließend auch nicht mehr benötigte Pakete wieder sauber entfernen.


Ich habe bisher auch immer noch nicht ganz verstanden, was du eigentlich erreichen möchtest.
Alleine die Installation von einem lauffähigen Arch-System ist für einen Anfänger nicht einfach. Natürlich begrüße ich es, wenn dich das interessiert und du dir das gerne beibringen möchtest. Aber die Installation von Arch ist wieder eine ganz andere Baustelle als das Starten von vms mit vbox. Und wenn es dir wirklich um die vbox-Sache geht, legst du dir mit arch selbst Steine in den Weg und wirst nicht mehr Performance erreichen als mit einem etablierten "Linux-Serversystem".
Das nicht Nachvollziehen können deiner genauen Motivation ist wahrscheinlich auch der Grund, warum dir anfangs alle zu anderen Hypervisorn geraten haben. Es macht objektiv keinen Sinn, vbox zu verwenden. Wenn es dir aber explizit darum geht, wie man ein neues Linux-System aufsetzt und vbox installiert - feel free and do it.
 
Mloki schrieb:
  • 2D/3D Grafiktreiber
  • Netzwerktreiber (Kabel kein Wlan)
  • Soundtreiber
  • I/O (Tastatur/Maus/USB)
  • Paketmanager
  • Virtualbox

https://www.archlinux.org/packages/ und eventuell https://aur.archlinux.org/
oder die package Repositories bei Debian ansehen.

Soundtreiber für die Hosthardware sind im Linux-Kernel.
Das Weiterreichen der Soundausgabe von einem VM-Gastsystem an das Host übernimmt Virtualbox dann bei Linux genau wie bei Windows.
siehe die Doku von Virtualbox:
Audio Settings
Host Audio Driver: The audio driver that Oracle VM VirtualBox uses on the host. On a Linux host, depending on your host configuration, you can select between the OSS, ALSA, or the PulseAudio subsystem. On newer Linux distributions, the PulseAudio subsystem is preferred.

Genauso bei 2D/3D ...sollte alles in der Doku stehen -- diese Features sind außerdem eher experimental - die Changelogs von Virtualbox sollten auch gelesen werden.

Wen du ein Projekt planst, dann vielleicht eher ein stable Release mit Server-Variante nehmen, denn im Grafikstack den du scheinbar benutzen willst, gibt es recht viele Änderungen und immer wieder auch Bugs.

Die Servervarianten sind bei der Softwareinstallation recht minimal. Allerdings wird kein Grafikstack installiert (xorg ... für 2D/3D) .
Fedora Server , Ubuntu Server oder Debian Netinstall. Ubuntu oder Debian wird vom Virtualbox Team vielleicht noch als Host-System getestet im Gegensatz zu Rolling Distros wie Arch. vgl. zB dieser Bug


2 Warnungen:

1: Erwarte keine Performancewunder bei Virtualbox in Vergleich zu anderen Virtualisierern.
Quelle: Virtualbox 6.0 gegen KVM - Test auf Phoronix 2018

2: Bei Bugs bist du eventuell auf Oracle / Virtualbox Forum/Homepage angewiesen - je nach Konfiguration (zB 2D/3D , Hardware-Weiterleitung in VM, USB Weiterleitung ...) kann die Virtualisierung sehr schnell auf Fehler stoßen.
 
  • Gefällt mir
Reaktionen: Mloki
lokon schrieb:
2: Bei Bugs bist du eventuell auf Oracle / Virtualbox Forum/Homepage angewiesen - je nach Konfiguration (zB 2D/3D , Hardware-Weiterleitung in VM, USB Weiterleitung ...) kann die Virtualisierung sehr schnell auf Fehler stoßen.

Danke für die Links.

Wie ist denn die 3D Beschleunigung unter KVM mittlerweile entwickelt ?
Ich werde auch KVM unterstützen, aber Virtualbox soll eben auch möglich sein,
mittlerweile ziehe ich auch in Betracht Debian statt Arch zu verwenden.

Momentan muss ich noch ein paar Details herausfinden damit ich die finalen Entscheidungen machen kann, welches System genau benutzt wird usw. es gibt halt viel zu beachten.
 
Mloki schrieb:
3D Beschleunigung unter KVM
https://wiki.archlinux.org/index.php/QEMU/Guest_graphics_acceleration

Intel klingt mit GVT-g spannend, aber das ist noch sehr experimentell.

Ein weiterreichen von PCIe Grafikkarten via VFIO (= VT-D & Varianten unter Linux) soll mehr oder weniger gut funktionieren - es sind teilweise Hacks notwendig, da Hersteller Marktsegmentation betreiben: teure Profikarten mit Profifeatures (VT-D) im Bios freigeschaltet zB.
Es gibt viele Linuxanwender, die Windows für Gaming virtualisieren und die Grafikkarte in der VM nutzen hier ein Ubuntu LTS Guide - quasi Debian. alte Debian Tests seit 2013

virtio-gpu / virgl in QEMU sollte recht ausgereift sein

Bei stable Distributionen sollte auch wenig im Grafikstack kaputtgehen.
Keine Ahnung bei aktuellen Themen wie Vulkan - Virgil @ phoronix

Theoretisch kann jeder mit piglit den 3D Grafikstack einmal kräftig durchschütteln und es werden immer irgendwelche Fehler herausfallen - ob auf Linux, OSX oder Windows bei den >25.000 Tests. Aber deine Anwendung wird eben nicht alle Features nutzen.

Achja - bei den Guides : es gibt libvirt zur Steuerung von den QEMU Emulator auf Linux - qemu kann auch direkt verwendet werden - vlt. hilft das auch bei den Suchbegriffen.
 
  • Gefällt mir
Reaktionen: Mloki
Also mit KVM und einem Windoof 10 Guest habe ich schlechte Erfahrung was Grafik-Performance betrifft (virtuelle GPU, kein pass-through). Das war vor einigen Wochen unter Arch, also aktuellste Versionen. In Windows natürlich alle Treiber installiert.

Für Windows-Desktops bin ich dann bei VirtualBox gelandet. Wie es mit Windows als Server unter KVM aussieht kann ich nicht sagen, aber das sollte wohl keine Probleme bereiten.

Linux natürlich auf KVM, da es dort viele Vorteile ausspielen kann.

Mloki schrieb:
Ich werde auch KVM unterstützen, aber Virtualbox soll eben auch möglich sein
Afaik geht nur eines zur selben Zeit.
 
Bagbag schrieb:
Afaik geht nur eines zur selben Zeit.

Wieso ?
Muss ich dann definitiv um beide parallel nutzen zu können Docker benutzen ?
 
Was hat das denn mit Docker zu tun und wie sollte Docker da weiterhelfen? Das ist etwas völlig anderes.

Aber nach Googlen könnte das mittlerweile doch gehen, aber nur mit Tricks.
 
Bagbag schrieb:
Was hat das denn mit Docker zu tun und wie sollte Docker da weiterhelfen? Das ist etwas völlig anderes.

Aber nach Googlen könnte das mittlerweile doch gehen, aber nur mit Tricks.

Wäre nett, wenn Du wenigstens den Grund nennen könntest, warum Du annimmst es würde nicht klappen.

Mit Docker kann man einen Container starten in dem Virtualbox installiert ist und läuft, und in einem anderen kann man dann gleichzeitig KVM benutzen. Deshalb habe ich es erwähnt.
 
Docker Container sind nicht virtualisiert. Alles darin läuft direkt auf dem Host Kernel. Der Kernel versteckt einfach nur alle Prozesse außerhalb des Containers vor den Prozessen im Container, "simuliert" einen eigenen PID Bereich, Netzwerk, Filesystem, etc. und verbietet einige sys calls.

Es müsste also trotzdem noch der selbe Kernel und die selbe CPU beides ausführen und macht diesbezüglich daher null Unterschied.

Unter Windows kannst du bspw kein VirtualBox und auch kein VMware mehr nutzen, sobald du Docker installiert hast, da das Hyper-V nutzt und damit die virtualisierung schon "belegt" ist.

Ich weiß, dass es bspw. nested virtualisierung gibt (habe ich mit KVM selbst schon gemach), also technisch ist es an sich durchaus möglich. Aber da das praktisch nicht gebraucht wird (weil es eben nie wirklich sinnvoll ist), wird nirgends der Aufwand dafür betrieben die Hypervisors parallel laufen lassen zu können.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SpicyWolf und Mloki
Bagbag schrieb:
Docker Container sind nicht virtualisiert. Alles darin läuft direkt auf dem Host Kernel. Der Kernel versteckt einfach nur alle Prozesse außerhalb des Containers vor den Prozessen im Container, "simuliert" einen eigenen PID Bereich, Netzwerk, Filesystem, etc. und verbietet einige sys calls.

Es müsste also trotzdem noch der selbe Kernel und die selbe CPU beides ausführen und macht diesbezüglich daher null Unterschied.

Unter Windows kannst du bspw kein VirtualBox und auch kein VMware mehr nutzen, sobald du Docker installiert hast, da das Hyper-V nutzt und damit die virtualisierung schon "belegt" ist.

Ich weiß, dass es bspw. nested virtualisierung gibt (habe ich mit KVM selbst schon gemach), also technisch ist es an sich durchaus möglich. Aber da das praktisch nicht gebraucht wird (weil es eben nie wirklich sinnvoll ist), wird nirgends der Aufwand dafür betrieben die Hypervisors parallel laufen lassen zu können.

Aha, verstehe, danke für den Hinweis.
Ich denke das mit Docker müsste man mal ausprobieren, so wie ich das verstanden hatte sollte Docker es möglich machen, aber kann gut sein, dass Du Recht hast, ich kenn Docker eh erst seit gestern, habe es durch Zufall bei Heise Online gesehen.
 
Mloki schrieb:
Wie baue ich einen Linux Hypervisor, welcher ausschliesslich die Pakete installiert hat, um Virtualbox laufen und warten zu lassen sowie sich selbst zu warten?

Enhalten sein sollen folgende Komponenten :

  • 2D/3D Grafiktreiber
  • Netzwerktreiber (Kabel kein Wlan)
  • Soundtreiber
  • I/O (Tastatur/Maus/USB)
  • Paketmanager
  • Virtualbox

Keine unnötigen Extras, wirklich sonst gar nichts !

genau das suche ich auch, habe aber bis jetzt nichts gefunden. Wie hast du das ganze gelöst?
 
  • Gefällt mir
Reaktionen: Mloki
@Neptun keine fertige Lösung, aber mit Arch Linux lässt sich das realisieren.
 
Neptun schrieb:
genau das suche ich auch, habe aber bis jetzt nichts gefunden. Wie hast du das ganze gelöst?
Leider gar nicht, ich suche immer noch.
 
Das wird auch schwierig da Virtual Box ein Desktop Virtualisierer ist und ein Rattenschwanz an Abhängigkeiten hat.
Sowas würde ich eher mit kvm lösen.
 
Ich verstehe den Threadersteller nicht so richtig - woran hat es denn gemangelt ?

Ein minimales Arch-Linux, ein CLI Virtualbox und dann ist das System "fertig".

Oder liegt es an den fehlenden Features bei Virtualbox ? Lt. Changelog 6.1 funktioniert bei Virtualbox zB kein PCI-Passthrough mehr (in 6.0 ging es wohl lt deren Doku).

Wurde überhaupt mit Linux und Virtualbox (oder KVM) mal experimentiert ?
Warum & Wonach wird weiter "gesucht" ? Der Post von
Neptun schrieb:
genau das suche ich auch, habe aber bis jetzt nichts gefunden.

ist mir auch irgendwie rätselhaft.
Die Programmierer, Maintainer, Projektleiter, Supporter können so nicht einmal erahnen ob das Problem am Code / Features / Bugs / fehlerhafter Dokumentation oder sonst wo liegt - oder welche Komponente nicht ihrem Wunsch entspricht.
 
lokon schrieb:
Ich verstehe den Threadersteller nicht so richtig - woran hat es denn gemangelt ?
Bösartige Unterstellung*: An der Bereitschaft, sich selbst etwas zu erarbeiten, weil es einem niemand auf dem Silbertablett heranträgt...

Wenn es KVM statt Virtualbox sein darf, dann mal Proxmox anschauen oder halt wie @lokon sagt, direkt selber aufsetzen. Da bezahlt man dann halt für die Schlankheit mit dem dazu nötigen Fachwissen.

* man darf mich gern korrigieren, wenn ich falsch liege
 
Zurück
Oben