• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Erfahrungen mit Oracle Virtualbox

Andy_m4

Well-Known Member
#26
Verweise ihn bloß nicht aufs Handbuch. Sonst druckt er es aus und schlägt es Dir um die Ohren mit den Worten, dass er natürlich das Handbuch bereits in und auswendig gelernt hat.
Stimmts, ralli? :-)
 

ralli

BSD Fanboy
Themenstarter #28
Verweise ihn bloß nicht aufs Handbuch. Sonst druckt er es aus und schlägt es Dir um die Ohren mit den Worten, dass er natürlich das Handbuch bereits in und auswendig gelernt hat.
Stimmts, ralli? :-)
Das Handbuch zu lesen reicht ja nicht, und es gibt manchmal Bereiche, die ich nicht verstehe oder falsch verstanden habe. Leider bin ich nicht perfekt wie ...... manch Andere hier. Den Anspruch habe ich aber auch nicht, und den habe ich auch nie gehabt. Aber wenn alle alles könnten, wäre es auch langweilig, gell?;)
 

mr44er

Well-Known Member
#30
Vorweg: Ich habe den Thread nur aufmerksam überflogen ;)

@ralli
Ich hab immer mal wieder mitgelesen, dass du zwischen BSDs und DEs hin- und herwechselst. Machst du das auf deinem Hauptrechner und richtest dich dann wieder komplett ein? Falls ja...klingt jedesmal nach ner Menge Einrichtungsarbeit.
Ich hab das in Teenagerjahren zwangsläufig aus Geldmangel und Hardwarebeschaffungsmangel so machen müssen. Ebay steckte schon in den Kinderschuhen, aber dazu brauchte man Internet und die Angebotsvielfalt war nicht so breit wie heute. Jedenfalls gab es auch noch keinen solchen Luxus wie Virtualisierung.
Worauf ich hinauswill: Schnell mal ein OS testen oder eine bestimmte Software -> Dafür ist eine virtuelle Maschine prädestiniert.

Jedenfalls brauche ich mindestens einen physikalischen PC als meine Workstation, damit ich immer 'handlungsfähig' bin. Experimente mache ich auf einem ZweitPC virtualisiert und wenn ich ganz grob auf Blech testen will/muss, dann auf einem DrittPC...physikalisch getrennt eben und ich muß auf nichts Rücksicht nehmen oder mich mit Multiboot rumärgern. Das mache ich schon immer so und da tun es auch die mir geschenkten, ausgedienten Kisten aus dem Bekanntenkreis.
Funfact: habe vor ein paar Monaten mal meinen gesammelten Berg an Rechnern und Hardwareteilen ausgemistet und beim Elektroschrott entsorgt, weil da nichts mehr verwendbares dabei war. Bevor jetzt jemand heult: für ebay-Verkauf sinnlos und wieder nicht alt genug, um als raritätische Sammelstücke zu gelten oder gar exotisches mit Firmengeschichte. Es waren dann 14 PCs und ich war erstaunt, wie schnell man den Überblick verliert. Cyber-Messie ist noch nicht im Duden angekommen. :D

So als kleiner Ratschlag, wo ich zwar mehr Zeit verbrösel, aber besser nachvollziehen kann: VirtualBox habe ich damals auf einem Testrechner unter Windows installiert. Weil es einfaches Geklicke ist, ich mir bewußt werden konnte, in welchem Modus physikalische NWKs laufen können und auch die virtuellen. Einfach alles neue Stück für Stück lernen, ohne drüber nachdenken zu müssen wie das unter dem jeweiligen OS zum laufen zu bringen ist.
Gewisse Programme gehen einem ja irgendwie in Fleisch und Blut über, man weiß, was das Programm kann und wie es reagiert. Wenn es dann unter einem anderen OS dann nicht so reagiert, weiß man, dass noch was fehlt. ;)

Edit: Gerade die Gasterweiterung kannst du mal unter Windows in einem virtualisierten Windows ausprobieren. Einmal virtualisiertes Windows ohne Erweiterung und dann mal mit. Garantierter "Whoa, geil!-Effekt"
 

ralli

BSD Fanboy
Themenstarter #31
Ich muss Dich doch auch mal necken, ralli. Es passte grad so gut. :-)
Ist schon in Ordnung, ich bin nicht so empfindlich, wie es aussieht.:)

Aber mal im Ernst, ich käme niemals auf die Idee, aus Bequemlichkeit die Zeit unserer Communitymitglieder in Anspruch zu nehmen, denn eine angemessene Portion Eigeniniative sollte man schon erwarten dürfen. Und genau die habe ich, ich habe wirklich das Handbuch gelesen. Aber manchmal bin ich zu ungeduldig und auch zu schnell. Und ich bin nicht der Techniker vor dem Herrn. Da haben viele Andere eine Kompetenz, die ich nur bewundere.:)
 

ralli

BSD Fanboy
Themenstarter #32
Ich hab immer mal wieder mitgelesen, dass du zwischen BSDs und DEs hin- und herwechselst. Machst du das auf deinem Hauptrechner und richtest dich dann wieder komplett ein?
Ich bin halt immer noch neugierig und probiere Vieles aus. Das hat den Vorteil, das ich mir selbst einen besseren Überblick verschaffe. Eine zweite Festplatte dient mir als Spielwiese. Meinen vorherigen Rechner habe ich verschenkt, der wäre auch für diese Zwecke noch ausreichend gewesen. Aber Deine Vorgehensweise gefällt mir auch.:) Ich werde darüber nachdenken. Zeit habe ich ja genug, denn ich bin ja im (Un)ruhestand.
 

Andy_m4

Well-Known Member
#33

ralli

BSD Fanboy
Themenstarter #34
Ich habe hier auch einen interessanten Überblick über cbsd gefunden:

Guckst Du hier:

cbsd

Macht einen sehr guten Eindruck und könnte auch mein Favorit werden..... :)

Und ja, ich habe den Warnhinweis nicht übersehen, das der deutsche Artikel veraltet ist und der englische aktuell. Aber er bietet trotzdem schon mal ab, um was es genau geht und was der Zweck und das Ziel von cbsd ist.
 

Vril

Well-Known Member
#35
auf "latest" liegt die gleiche Version binär (5.2.22 r126257) und arbeitet bei mir problemlos. Passende Gasterweiterungen für meine wichtigsten Systeme gibt es dafür auch....
Gut, dass Du das erwähnt hast - ich hatte das inzwischen komplett ausgeblendet bzw. vergessen, dass per default "quarterly" und nicht latest eingestellt ist ....

und ich wundere mich, wieso pkg die 5.18 zeigt - während der sourcecode von 5.22 in den Ports ist ;-)

Danke & Gruss nach Frankreich
 

medV2

Well-Known Member
#36
Im Prinzip aus dem gleichen Grund, warum man keine zwei Kernel parallel betreiben kann, weil die sich halt gegenseitig behindern. Sie greifen auf die gleichen Ressourcen zu.
Man stelle sich nur mal vor, man lässt mehrere Anwendungen gleichzeitig laufen, die benötigen ja auch alle die gleichen Ressourcen...
Ernsthaft du stellst eine Behauptung auf und bleibst technische oder zumindest praktische Begründungen schuldig.


Und wenn das so ist, warum vergleichst Du dann diesen ganzen Stack mit bhyve?
Der TE will offensichtlich unter FBSD virtualisieren, daher habe ich bewusst in meinem ersten Post (der ja VBOX vs KVM ist) die schwächen von VBOX gegenüber KVM nicht näher betrachtet, die es auch zu bhyve geben würde. Ich denke das bringt dem TE wenig. Da bin ich erst konkret geworden, nachdem du nachgebohrt hast. Und mehr als bhyve gibt es nunmal nicht unter BSD.

Ansonsten hat ja Yamagi schon sehr gut den Stand um bhyve beschrieben, ich denke auch nicht, dass bhyve mehr KVM werden muss (KVM gibt es ja schon), brauchbarer IO wäre aber schon wünschenswert. Ich würde es, wenn ich nur FBSD zur Auswahl hätte, aber immer VBOX vorziehen.
 
#37
Ernsthaft du stellst eine Behauptung auf und bleibst technische oder zumindest praktische Begründungen schuldig.
Weil man damit ganze Bücher füllen kann und das auch Grundwissen ist, wenn man sich mit virtualisierung beschäftigt. Mit diesem Hinweis kann man sich alle benötigten Hintergrundinformationen im Internet selbst zusammen suchen.
 

turrican

Well-Known Member
#38
warum man keine zwei Kernel parallel betreiben kann
Nach meinem Verständnis:

Idee:
2 Kernel gleichzeitig auf 1 Hardware

Gedanken dazu:
Was macht ein Kernel? Er macht die zugrundeliegende Hardware (für Programme) nutzbar.
Würde es einen Konflikt geben, wenn 2 Kernel auf die gleiche Hardware zugreifen würden? Vermutlich ja, bzw müssten die beiden Kernel Funktionen eingebaut haben, um a) voneinander zu wissen und b) damit umgehen zu können - um Konflikte (beide greifen konkurrierend auf die gleiche Hardwarekomponente zur gleichen Zeit zu) zu vermeiden

[Edit]: Was würde es für einen Sinn machen, 2 Kernel gleichzeitig auf einer HW zu betreiben?
Man könnte ggf im weitesten Sinne den Grafikkartentreiber (weil heutzutage hinreichend komplex) als Kernel ansehen, somit wären in einem modernen PC 2 "Kernel" am laufen; aber der OS Kernel behält die Oberhand über das System und dessen Ressourcen, der GraKa-Treiber hängt von diesem ab und kann nicht autonom/separat davon laufen.

Es is vermutlich wie in der Ehe - beide (sie und er) sind gleichberechtigt, aber nur sie bestimmt, was gemacht wird :D

meine 2 Pfennige...
 

pit234a

Well-Known Member
#39
das ist ein wenig ein unglückliches Beispiel, das mit den beiden Kerneln und dann auch der Vergleich, mit der GraKa als quasi eigenständiger Kernel. Man könnte dann auch sagen, dass eine moderne GraKa quasi schon ein eigenes Betriebssystem hat oder quasi schon ein eigener PC ist. Alles nicht so ganz daneben, aber doch weit genug von der Realität, um irgendwo hin zu führen.
Es wird ganz sicher spannend bleiben, die weitere Entwicklung zu verfolgen.
Man hat mir neulich noch erzählt, dass einige Firmen schon ihre Produkte nur noch virtualisiert laufen lassen, weil sie damit wohl Entwicklungskosten sparen, denn sie können wohl immer "gleiche HW" wählen. Außerdem kann das Installieren eines Systems damit fast so einfach werden, wie das zurück-spielen einer Sicherung. Bei neuer Funktionalität gibt es einfach ab Werk eine neue VHD, oder so in der Art.
Erlebt habe ich das selbst noch nicht. Könnte mir aber tatsächlich vorstellen, das da was dran ist.
 

turrican

Well-Known Member
#40
ein wenig ein unglückliches Beispiel
Ja, das mit der GraKa ist weit hergeholt, geb ich zu.
Der GraKa-Treiber kann, wie ich ja schrieb, nicht ohne OS Kernel auf der HW alleine existieren.

ihre Produkte nur noch virtualisiert
Bei meinem vorherigen AG waren über die letzen 10 Jahre zum Schluss auch zahlenmäßig mehr Server virtuell, als physische vorhanden waren - u.a. auch (aber nicht nur) um bei einem Recover-Szenario die gleiche HW zur Verfügung zu haben (was sich aber auch als nicht ganz zu Ende gedacht erwiesen hat, da bei dem eingesetzten Virtualisierer sich zwischen den Major-Versionen natürlich auch die "virtuelle" Hardware geändert hatte und ein altes Backup eben nicht "mal eben so" zurückspielbar war)

Aber auch bei ner Virtualisierung läuft immer nur ein Kernel auf der Hardware; der in der untersten Schicht gleich über der Hardware - die Virtualisierer sind vereinfacht gesagt entweder Schnittstellen zu diesem bzw laufen auf höheren Schichten als dieser eine Kernel und nutzen die Hardware über eben diesen.
Die Virtuelle Maschine kriegt im Idealfall da dann aber nichts davon mit - die läßt brav ihren eigenen Kernel laufen, das kann man aber nicht mit dem angesprochenen 2-Kernel-Szenario vergleichen.

So, aber jetzt genug den Thread mit meinem Geseier gekapert bzw OT genommen, bin schon schweig :D
 

medV2

Well-Known Member
#41
Weil man damit ganze Bücher füllen kann und das auch Grundwissen ist, wenn man sich mit virtualisierung beschäftigt. Mit diesem Hinweis kann man sich alle benötigten Hintergrundinformationen im Internet selbst zusammen suchen.
Der nächste Virtualisierungprofi... Es gibt genau keinen Grund wieso sich mehrere Typ2 Hypervisors nicht vernünftig vertragen, wir haben nicht mehr 2000 und Virtualisierung ist keine Magie mehr.. Der einzige Grund sind schlechte Hypervisors aber das ist kein technischer Grund.
 

Rakor

Administrator
Mitarbeiter
#42
Ohne jemand speziell anzusprechen möchte ich euch bitten dennoch bitte sachlich zu bleiben und euch nicht anzugiften.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#44
Die Unterscheidung zwischen Typ 1 und Typ 2 Hypervisor ist auch sehr ... sagen wir mal 1973. Von einigen sehr speziellen Anwendungen mal abgesehen, fahren alle verbreiteten Hypervisor ein Betriebssystem hoch, in oder auf dem sie laufen. Die Frage ist nur, ob oder in wie weit dieses Betriebssystem sichtbar ist.
 

ralli

BSD Fanboy
Themenstarter #45
Ohne jemand speziell anzusprechen möchte ich euch bitten dennoch bitte sachlich zu bleiben und euch nicht anzugiften.
Respektvoller Umgang miteinander sollte ja auch eine Selbstverständlichkeit sein. Niemand hat das Recht auf eine absolute Wahrheit. Allerdings sehe ich diesen Thread dann doch als überwiegend positiv an, es kommt zumindest zeitweilig zu einem inspirierenden und echten Dialog und das gefällt mir außerordentlich. Das Ringen um die Wahrheit ist ja ehrenhaft, wenn es nicht ausschließlich um die Deutungshoheit oder Rechthaberei geht. Jedenfalls habe ich viel Neues hinzu gelernt, und das war auch meine Absicht.:) Was die Kompetenz und Sachlichkeit angeht, das geht es hier vergleichsweise immer noch sehr human und moderat, ja geradezu vorbildlich zu.:)

Und deshalb bin ich allen Beteiligten zu Dank verpflichtet.
 

Andy_m4

Well-Known Member
#46
Man stelle sich nur mal vor, man lässt mehrere Anwendungen gleichzeitig laufen, die benötigen ja auch alle die gleichen Ressourcen...
Ja. Über den Trick, dass man den Anwendungen die Ressourcen nicht direkt zuteilt, sondern die Verteilung vom Betriebssystem vorgenommen wird.
Ein Hypervisor verschiebt das Prinzip um eine Ebene nach oben. Er übernimmt die Zuteilung der Ressourcen lässt aber die virtualisierten Betriebssystemkerne in dem Glauben, die greifen direkt auf die Hardware zu.
Klar kann man das Spiel noch weiter treiben und jetzt wiederum einen Hypervisor drüber setzen der dann mehreren (Gast-)Hypervisoren vorgaukelt das sie die Ressourcen exklusiv haben.
Aber mehrere Hypervisoren so einfach nebeneinander ist eben genauso schwierig wie mehrere Betriebssysteme nebeneinander.
Insbesondere dann, wenn die auf Hardwareunterstützung zurückgreifen. Bei x86 gibts zwar inzwischen Unterstützung für verschachtelte Virtualisierung aber nicht für mehrere Hypervisoren parallel.

Möglich ist es prinzipiell aber trotzdem. Zumindest wenn man einen Hypervisor hat, der im Host-Betriebssystem selbst läuft und sich in die dortige Prozessstruktur einfügt.
Trotzallem dürfte man sich damit Performanceprobleme einfangen. Das kann man vielleicht mal als Spielerei machen (so man es überhaupt zum laufen bringt, was schwierig genug sein dürfte). Aber man wird nicht allzu oft auf eine solche Konstellation in der Praxis treffen.

Ernsthaft du stellst eine Behauptung auf und bleibst technische oder zumindest praktische Begründungen schuldig.
Ich kann nix dafür, wenn Du sie nicht verstehst. Aber es steht Dir ja frei nachzufragen. Und das hast Du ja auch artig gemacht. ;-)

Der TE will offensichtlich unter FBSD virtualisieren, daher habe ich bewusst in meinem ersten Post (der ja VBOX vs KVM ist) die schwächen von VBOX gegenüber KVM nicht näher betrachtet
Ähm. Andersrum wird auch Schuh draus. Für das was der Threadersteller machen will sind die angeblichen Schwächen von KVM keine Schwächen. Daher ist es unnötig zu erwähnen. Und wenn man es unbedingt machen möchte, dann sagt man halt "KVM kann zwar mehr aber bringt in Deinem Szenario keine nennenswerten Vorteile".

Da bin ich erst konkret geworden, nachdem du nachgebohrt hast.
Dann mache keine Andeutungen. Dann bleiben auch keine Unklarheiten zurück.

Und mehr als bhyve gibt es nunmal nicht unter BSD.
Warum bringst Du dann überhaupt KVM zur Sprache?
Wie du festgestellt hast, hat der Threadersteller FreeBSD. Und wie du weiterhin festgestellt hast, gibts da nur VirtualBox und bhyve.
Das passt doch alles hinten und vorne nicht.
Es sei denn man will unbedingt Werbung für KVM machen. :-)

Ich würde es, wenn ich nur FBSD zur Auswahl hätte, aber immer VBOX vorziehen.
Auch hier wieder keine Begründung.

Aber pass auf. Ich liefere Dir mal eine.
Wenn es Desktop-Virtualisierung sein soll, dann würde ich zu VirtualBox greifen. Es ist einfach zu bedienen und liefert gute Grafikperformance.
Meiner Erfahrung nach gibt es aber mit VirtualBox manchmal Stabilitätsprobleme. Auch die Integration in FreeBSD ist nicht so gut wie bei bhyve.
Wenns also ein virtualisiertes System ist, welches eine gewisse Zuverlässigkeit braucht (Serverbetrieb) würde ich eher zu bhyve tendieren.
 

turrican

Well-Known Member
#47
Ich muss dann wohl doch noch was zu Bhyve sagen:
Der große Schwachpunkt von Bhyve ist I/O. Es ist meiner Erfahrung nach schneller als unter VirtualBox, aber deutlich langsamer als unter den meisten Konkurrenten.
Weiß man, wie das mit I/O und USB Ports ausschaut? Ich würd gern ein Win-Programm (*seufz*) ausführen; früher hatte ich unter Linux VBox bzw KVM/QEMU dazu installiert, aber die Performance am USB war grottig - unter VBox sowieso (dabei hätte ich da gerne von dessen "Seamless Mode" für die Applikation profitiert) und mit KVM liefs auch ned gescheit;
Ich hätte quasi ne Hardware am USB (nen SDR Stick bzw ne SDR-Play) und würd gern das Programm SDR-RADIO ausführen - und das is leider WIn-only :/
Ist unter bhyve was zum USB-Throughput bekannt?
 

schorsch_76

FreeBSD Fanboy
#48
Das werde ich mir jetzt vorknöpfen. Arbeitet hier jemand erfolgreich mit der Virtualisierungslösung bhyve?
Hallo @ralli,
Ja ich nutze bhyve mit vm-bhyve. Sowohl auf dem Server als auch auf dem Desktop. Jedesmal mit UEFI loader. Das gibt eine VNC Sitzung die sich verhält wie du es gewohnt bist. ABER: Per VNC gibt es keymap Probleme. Am besten ist es wenn du im Gast die Keymap aus us lässt. Das bedeutet auch das ich beim Passwort bei ASCII bleibe und kein y oder z nutze. Nur Standard. Deshalb starte ich so früh wie möglich RDP bei Windows und ssh bei Linux und *Bsd.

Gruß Georg
 

ralli

BSD Fanboy
Themenstarter #49
Hallo Georg,

danke für dein Feedback.:) Mit bhyve kann ich mich erst tiefer beschäftigen und einarbeiten, wenn ein neues Motherboard eingebaut ist. Mein jetziger Rechner ist zu leistungsschwach für Virtualisierung.

Gruß Ralph