VMs unter FreeBSD-10.3 ... ein Drama in 3 Akten

luftschloss

New Member
Hallo liebe (?Mit-)Leidende,

ich hatte die wahnsinnige Idee, mal eben, eine VM unter FreeBSD einzurichten.

Mein erster Gedanke war VirtualBox, weil ich das in letzter Zeit fast nur noch nutze - kann ja so schlimm nicht werden, dachte ich...

1.) VirtualBox
Code:
# pkg install virtualbox-ose
schlägt fehl, wegen eines nicht zu lösenden Konfliktes: mesa-dri verursacht einen Konflikt mit dri, also hab ich Letzteren einfach entfernt
Code:
# pkg -f delete dri
Danach klappte die Installation reibungslos. Noch schnell eine Gruppe 'vboxusers' erstellt und bevölkert und los geht's
Code:
% VirtualBox
VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/local/lib/virtualbox/VirtualBox.so",) failed: /usr/local/lib/libGL.so.1: Undefined symbol "drmGetDevices2"
..oder auch nicht :-(

Ein Blick in /var/log/Xorg.0.log zeigt, dass AIGLX gestartet wurde, also sollte die GL Unterstützung doch vorliegen?

Der nachfolgende Versuch, virtualbox-ose-nox11 zu installieren lieferte dann folgende Fehlermeldung / Hinweise:
Code:
pkg: libGLU has a missing dependency: libGL
pkg: cairo has a missing dependency: libGL
pkg: xf86-video-r128 has a missing dependency: libGL
pkg: xf86fs-video-openchrome has a missing dependency: libGL
pkg: xf86-video-mach64 has a missing dependency: libGL
pkg: xf86-video-ati has a missing dependency: libGL
pkg: xdriinfo has a missing dependency: libGL
pkg: xf86-video-intel has a missing dependency: libGL
pkg: libepoxy has a missing dependency: libglesv2
pkg: xorg-server has a missing dependency: libGL
Wenn ich das richtig verstehe, sind das Nachwehen, des ursprünglichen meta-dri vs dri Problems - da wurden wohl einfach mal ein paar Pakete umbenannt?
Code:
# pkg set -n OLD:NEW
könnte das wohlmöglich lösen, oder noch mehr kaputt machen. Da ich die Auswirkungen nicht wirklich überblicke, habe ich an dieser Stelle erstmal abgebrochen.

2.) bhyve

Dass sich inzwischen auch etliche Fremd-OSse ganz wohl fühlen im Bienenkorb, hatte ich wohl vernommen, und dachte, nun ist die Zeit, sich damit zu beschäftigen.

Erfreulicherweise war das viel unkomplizierter, als mit der VirtualBox, kurz und knapp liess mich pkg wissen, dass meine CPU nicht unterstützt würde - ein kurzer Blick auf die, für mich, kryptisch anmutenden Befehle in der manpage taten ein Übriges.

3.) *qemu

Da gab es doch mal was mit GUI für qemu? Ach ja, Aqemu.
Beim Erststart werde ich gebeten, mir eine Sprache auszuwählen - aber ganz gleich, welche der ca. ein Dutzend Sprachen ich wähle, Menüs und Knöpfe bleiben in kyrillisch beschriftet :-(
Wenig hiflreich, wenn man zuvor noch nie mit dem Programm gearbeitet hat.

Dann also klassich, denk ich trotzig - ging ja jahrelang, als wir noch nichts anderes hatten - der gute alte qemu mit cli.

Problemlose Installation und das Programm läuft tadellos, bis auf eine Kleinigkeit:

Das Tastatur-Layout ist heillos durcheinander. Nach viel Rumprobiererei konnte ich folgendes rausfinden:

6 = TAB
F3 = HOME
F11 = END
F12 = DOWN
SHIFT+7 = ENTER
^^ aber Achtung! 7 alleine tut nichts, es muss SHIFT+7 sein, allerdings fördert der Druck der Shift-Taste in Eingabefeldern direkt eine 1 zutage, und Backspace konnte ich nicht finden.

Wer sich jetzt zu erinnern meint, dass qemu doch so einen -k switch hatte ... der ändert leider überhaupt nichts.

So verbleibe ich einigermassen konsterniert, und hoffe, Ihr könnt mir mit Tipps und Tricks weiterhelfen :-)

Mit besten Grüßen

virtual.realty
 
Bezgl. VirtualBox muss ich zustimmen - meine Erfahrungen sind aehnlich.

Ich habe letzte Woche mit bhyve begonnen - und komme damit ganz gut zurecht.
Wenn Du natuerlich einen Prozessor ohne Features2(AMD),POPCNT(AMD), VT-x(INTEL), EPT(INTEL) oder UG(INTEL) ...oder wie das auch alles heissen mag ..
hast ... ist es natuerlich mit bhyve bloed.

Gruss walter
 
Das sind ja eine ganze Reihe Fragen. :) Also:

Virtualbox: Dein Problem hier ist das Paketmanagement. Ich kann nur raten was schief gegangen ist, daher erst einmal die grundsätzliche Frage. Wie viele Linux-Paketmanager ist auch pkg ein "alles oder nichts"-Ansatz, sprich die lokal installierten Pakete müssen (idealerweise) durchgehend auf dem Stand des Repos sein, sonst gibt es Chaos. Hast du vielleicht einfach ein "pkg install" gemacht, nachdem das letzte "pkg upgrade" schon ein wenig zurück lag? Das würde erklären, wieso er keinen konsistenten Zustand finden konnte.

Bhyve: Bhyve ist nur ein Hypervisor. Damit er komfortabel zu benutzen wird, braucht man ein Management-Script oder ein GUI. FreeBSD selbst liegt mit /usr/share/examples/bhyve/vmrun.sh eine ganz brauchbare Lösung bei. Es gibt in den Ports noch ein paar mehr, außerdem kann man libvirt und seine diversen Frontends nutzen. Interessant wäre zu wissen, welche CPU du hast. Das Bhyve sie nicht unterstützt kann natürlich sein, aber inzwischen sind so alte CPUs doch recht selten geworden.

Qemu: Qemu ist unter FreeBD ein reiner Emulator. Dafür gibt es seine Anwendungszwecke, aber um Gastsysteme auszuführen ist das einfach zu langsam. In der vollständigen Emulation erreicht man ungefähr 5 bis 15 Prozent der Leistung des Hosts, mit Usermode-Emulation bis zu 75 Prozent. Usermode-Emulation verlangt aber, dass das Gast-System gleich dem Host-System ist.
 
Virtualbox: Dein Problem hier ist das Paketmanagement.

Sieht so aus - ich habe nochmal zur Sicherheit

# pkg update -f && pkg upgrade

durchgeführt. Ergebnis: xterm-330.txz not found. Ich habe nachgeschaut, und tatsächlich ist es in quarterly nicht drin, weshalb ich quarterly gegen release_3 erstetzt und obigen Befehl erneut ausgeführt habe. Das lief inklusive Downgrade einiger Pakete fehlerfrei. Danach bin ich wieder auf quarterly und habe immer noch xterm not found. Forcen läßt pkg sich da auch nicht - er bricht dann einfach ab.

Und nun? Über updating iterieren und alles aktualisieren, was gefunden wird?

Irgendwo scheint da der Wurm drin zu sein.

P.S.: Alternative Repos in /usr/local/etc existieren nicht.

Bin für jeden Tipp dankbar :-)

Gruss

virtual.realty
 
ich lese nur halbherzig mit, aber mein 32Bit System aktualisiert gerade die Pakete und steht auf Latest und wenn ich das richtig gesehen habe, war da auch ein xterm-330 dabei.
 
das ist natürlich latest und nicht Latest, aber das siehst du ja.

ich wollte noch ergänzen, dass ich wegen des Beitrags mal eben meine VirtualBox auf dem adm64 FreeBSD 11-RC3 angeworfen habe, die letztens auch upgedatet wurde und sie funktioniert noch immer, derzeit mit einem alten WinXP und einem nicht mehr neuen Ubuntu als Client. Lediglich mit dem Netzwerk scheint sich was ergeben zu haben.
Ich hatte die Installationsmeldungen natürlich wie immer nicht gelesen. Sowas hat ja Zeit, bis man es dann wirklich mal braucht und sieht, was nicht geht.
 
wenn ich die Binaries von von cdrtools-devel installiere, verliere ich VB:

Code:
pkg install cdrtools-devel
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating Synth repository catalogue...
Synth repository is up to date.
All repositories are up to date.
Checking integrity... done (1 conflicting)
  - cdrtools-devel-3.02a07,1 [Synth] conflicts with cdrtools-3.01 [installed] on /usr/local/bin/btcflash
Checking integrity... done (0 conflicting)
The following 2 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
    virtualbox-ose-5.1.22_1

New packages to be INSTALLED:
    cdrtools-devel: 3.02a07,1 [Synth]

Number of packages to be removed: 1
Number of packages to be installed: 1

The operation will free 351 MiB.

Proceed with this action? [y/N]:
 
mein 32Bit System aktualisiert gerade die Pakete und steht auf Latest und wenn ich das richtig gesehen habe, war da auch ein xterm-330 dabei.
Wie kann mein quarterly von dem neuen xterm wissen, und warum verlangt es danach? Jedenfalls vielen Dank für den Hinweis. Inzwischen hatte ich die glorreiche Idee, den Downgrade nochmal per -f zu erzwingen. Lustigerweise kann die pkg 1.6.n aus release_3 wohl nicht mit dem aktuellen db Format umgehen.

Momentan erwäge ich, die pkg Namen aus dem letzten db Backup zu ziehen, und dann alles mit latest neu zu installieren.

Ich hatte die Installationsmeldungen natürlich wie immer nicht gelesen. Sowas hat ja Zeit, bis man es dann wirklich mal braucht und sieht, was nicht geht.

Meinst Du das jetzt ernst, oder ist das beißender Spott? Ich halte es genauso, und es "ergibt" sich dann immer gerade dann was, wenn ich es am wenigsten brauchen kann, was mir in der Folge die Schweißperlen auf die Stirn, und die Zornesröte ins Gesicht darunter appliziert. ;-)

Gruss

virtual.realty
 
Meinst Du das jetzt ernst, oder ist das beißender Spott?
ein Stückchen Selbstironie.
Ich mache das tatsächlich immer so und hatte deshalb auch schon oft, sagen wir, gewissermaßen "Abenteuerreisen" hinter mich zu bringen. Eigentlich sollte ich es im Laufe der Jahre gelernt haben und es besser machen.

Wie kann mein quarterly von dem neuen xterm wissen, und warum verlangt es danach?
ja, das ist nicht zu erklären, woher die Abhängigkeiten kommen und ich wollte und will mir darum gerade keinen Kopf machen und deshalb auch der Hinweis, dass ich nur halbherzig mitlese. Dass "latest" das geforderte Paket auf meinem kleinen Rechner eben installiert hatte, schien mir nur gerade in den Zusammenhang zu passen.

Insgesamt ist es so, dass die Repos inzwischen wesentlich konsistenter sind, als sie es früher zu Weilen manchmal gewesen sind. Sie sollten eigentlich immer korrekt laufen, aber ich habe auch in den letzten Wochen immer mal wieder erlebt, dass es da ganz offenbar ein gewisses Chaos gab, das ich mir nicht erklären kann. Ich bin überhaupt nur wegen eines solchen Umstandes mit dem einen Rechner auf "latest" gelandet.
Generell kann es eine gute Taktik sein, das nicht zu ernst zu nehmen (ich weiß, das ist nun furchtbar ausgedrückt) und es einfach etwas später wieder zu probieren.
 
Zurück
Oben