Virtualisierung und FreeBSD?

H

hugly

Well-Known Member
Ich benutze seit knapp 9 Jahren FreeBSD als Desktop System, der Mensch ist ein
Gewohnheitstier ,)

Durch diverse Progrämmchen bin ich genötigt VMWare2 bzw. 3.21 mittlerweile
ein Windows NT, mittlerweile 2000 zu benutzen.

Das ganze hat kleinere macken, funktioniert aber eigentlich gut.

Allerdings ist es alles andere als Zeitgemäss, vor allem die VMWare 3.2 ist einfach
asbach uralt :=)

Wie schauts denn aus? Ist da in absehbarer Zeit was zu erwarten?

FreeBSD mässig scheint da ja keinerlei Entwicklung mehr stattzufinden.

Muss man auf NetBSD ausweichen wenn man sowas braucht???

Ich benutze das Ports - System sehr häufig für tests etc. (installiere/upgrade/
downgrade/teste andauernd irgendwelche Ports, einfach nur der Software, also
des jeweiligen Ports wegen).

Unter NetBSD wäre das vermutlich eine ziemliche umgewöhnung, hab ich jetz
nicht so wirklich böcke drauf ;)


Wie schauts aus? Was würdet ihr mir raten?
 
FreeBSD wird von den großen Herstellern von Virtualisierungssoftware nicht unterstützt. Das ist in Anbetracht der relativ wenigen Nutzer auch nicht weiter verwunderlich, sogar verständlich.

Aber trotzdem ist nicht alles verloren, denn Qemu gehört sicherlich zu dem am meisten unterschätzten Programmen unter FreeBSD. Er ist gerade in Version 0.10.1 erschienen, in Kombination mit kqemu-devel (Der Code ist zwar experimentell, läuft aber besser als der offiziell freigegebene, aber schon recht alte kqemu) kann er ein Windows XP perfekt virtualisieren. Es läuft inzwischen nicht mehr langsamer als unter Virtualbox oder VMware, man kann die virtuelle Maschine starten und stoppen und so weiter und ist vergleichbar stabil. Halt den ganzen Schnick-Schnack, den man erwartet. Ich lasse darin inzwischen auch sehr rechenaufwändige Anwendungen laufen, läuft schnell (ca. 10% langsamer als nativ) und stabil. Leider ist in den Köpfen immer noch der Qemu der ersten Jahre drin, welcher viele Probleme hatte und noch keinen Nutzen aus Schwesterprojekten ziehen konnte. Unterstützte Gastsysteme sind Windows XP, Linux und Solaris. Bei allen anderen wäre ich vorsichtig, würde mir überlegen, ob ich kqemu nicht rauslassen.

Tja, kommen wir zu den Nachteilen, ist ja kein Werbetext. Qemu kann kein Threading, er läuft immer auf einem Kern / einer CPU. Auch der IO-Durchsatz ist nicht sooo überragend, aber für die Praxis völlig ausreichend. Solange man keine großen Datenmenge auf der der virtuellen Platte herumkopiert. Auch ist die Bedienung nicht ganz eingängig, aber es gibt grafische Frontends. Auch die Unterschiede zwischen qemu, qemu + kqemu und qemu + kqemu + --kernel-kqemu muss man erstmal kapieren.

Abschließend kann man noch sagen, dass sich Qemu von allen Lösungen am besten in das Unix-System und die Opensource-Welt integriert. Man kann ihn problemlos physikalische Festplatten, Partitionen und CDs mitgeben. Man kann ihn auf ca. 10 Wegen in das Netzwerk integrieren, von NAT über Tunneling und tap bis hin zu bpf. Man kann Linux-Kernel direkt booten, serielle Ports auf die Konsole durchschleifen, etc. Nur um einen kurzen Überblick zu geben.

EDIT: Ach ja, wenn dein Host ein FreeBSD/amd64 ist, musst du Version 7.1 oder neuer einsetzen. Sonst wirst du nicht viel Freude haben.
 
Zuletzt bearbeitet:
Hi,

1. Wo liegen den die Unterschiede zwischen qemu, qemu + kqemu und qemu + kqemu + --kernel-kqemu ?

2. Werden die Virtualisierungsfunktionen der Prozessoren mittlerweile unterstützt?


Gruss TODuke
 
Ich will hier auch mal meinen Erfahrungsbericht zu qemu schreiben.

Ich nutze qemu seit ca. 3 Jahren. FreeBSD ist mein Hauptdesktop-System, das ich fast ausschließlich nutze. Wir entwicklen in der Firma Webanwendungen, die auch unter dem IE funktionieren müssen. Dafür starte ich Windows in qemu. Außerdem nutze ich qemu für OpenBSD und schnüre dort meine Pakete für zwei OpenBSD-Systeme. Als grafische Oberfläche nutze ich qtemu, das auch in den Ports ist, allerdings nur beschränkten Komfort bietet.

zur Geschwindigkeit: Ich bilde mir ein, das es mehr als 10% sind, die es langsamer als auf nativer Hardware läuft. Es läßt sich auf jeden flüssig bedienen und ist stabil. Ein aktueller Rechner ist anzuraten. Ich habe es ca. 2 Jahre auf einem P4 genutzt und da war es keine Freude, weder im Host- noch im Gastsystem. Auf meinem aktuellen Quad Core läuft es dagegen super.

Praktisch ist die Konfigurierbarkeit des Netzwerks von qemu.

Und qemu gibt es auch für andere Systeme, wie vor kurzem festgestellt habe, z.B. auch für MacOS X.

Gruß c.
 
Ich bezog mich oben auf qemu 0.10.1, was subjektiv gesehen einen großen Sprung nach vorn gemacht hat. Sowohl was Geschwindigkeit als auch Stabilität betrifft. Allerdings hat die Maschine auch ordentlich Leistung, wie du sagst, eine Multicore-CPU ist anzuraten, denn sonst kommen sich Host und Gast ständig in die Quere.

Zum Unterschied zwischen den drei Varianten:

qemu - Dies ist der Modus, wenn qemu ohne kqemu gebaut wurde oder mit --disable-kqemu gestartet wird. Er ist dann keine Virtualisierung, sondern ein klassischer Emulator, welcher den Prozessor in Software nachbaut. Das ist logischerweise recht langsam, aber dafür auch sehr stabil. Auf Hostplattformen, die von kqemu nicht unterstützt werden, ist dies der einzige Modus. Gleiche gilt, wenn die Zielplattform etwas anderes als i386 ist.

qemu + kqemu - Dies ist der Standardmodus, wenn qemu mit kqemu gebaut wurde und das Kernelmodul geladen ist. Es ist eine teilweise Virtualisierung, wie auch Parallels sie auf Wunsch unterstützt. Der Ring-0 der x86-CPU wird weiterhin in Software emuliert, Ring-1 bis Ring-3 werden auf die Host-CPU durchgeschleift und sind entsprechend schnell. Der Modus ist ein Kompromiss zwischen Geschwindigkeit und Stabilität. Wie schnell er wirklich ist, hängt vom Gastsystem am, tendetiell kernellastige unixoide Systeme machen nicht wirklich Spaß, das eher usermodelastige Windows schon.

qemu + kqemu + --kernel-kqemu - Hier wird auch der x86 Ring-0 auf die Host-CPU durchgeschleift, man hat eine volle Virtualiserung. Ist sehr schnell, so schnell wie VMware und Parallels. Hat aber den Nachteil, dass stabiler Betrieb nur auf Gastsystemen möglich ist, auf die qemu angepasst wurde. Sprich vor allem Windows XP und Linux, teils auch noch Solaris.

Die Virtualisierungsfunktionen der CPU unterstützt qemu unter FreeBSD nicht. Unter Linux geht es, dort sind dank kvm noch ein paar mehr Kombinationen möglich, als die oben genannten drei. Einen wirklichen Einfluss hat das aber nicht, wirklich sinnvoll ist hardwareseitige Unterstützung der Virtualisierung eigentlich nur, wenn es sich um einen echten Hypervisor handelt, denn dann erleichtert es die Arbeit der Software wirklich. Und da sind dann auch AMD-Prozessoren sehr zu bevorzugen, da sie einfach mehr können. Wobei ich selbst Hypervisoren immer noch sehr, sehr, sehr kritisch gegenüberstehe.

Ich meine, ob qemu jetzt wirklich mit aktuellen Versionen von VMWare mithalten kann, sei man dahingestellt. Aber mein gerade mal ein knappes Jahr altes Parallels auf dem Mac schlägt es ganz klar, zumindest was die Stabilität mit Windows XP als Gastsystem angeht. Und wenn hugly vom alten VMWare 3 kommt, muss ihm qemu wie ein Geschenk Gottes vorkommen, da liegen schließlich etliche Generationen der Entwicklung zwischen. ;)
 
Hallo und danke für die Informationen.
Ist den seitens der Entwickler einer entsprechende Kernelschnittstelle angedacht?
Und was verstehst unter echtem Hypervisor?

Gruss TODuke
 
Danke für die Antworten.

OK, also kqemu hatte ich garnicht auf dem Schirm.

Werde es testen, habe es früher paarmal benutzt und es
war immer grottenlahm, aber halt qemu ohne "k" :)

Eine Frage aber hätte ich noch dazu:
Gibt es eine bequeme Möglichkeit die VM zu suspenden?

Denn ich fahre meine Maschine jeden Abend runter vorm
nach Hause gehen.
 
Ist den seitens der Entwickler einer entsprechende Kernelschnittstelle angedacht?
Zum Vergrößern anklicken....
Nein. Es arbeitet im Moment niemand dran. Kib Macy wäre bereit so etwas zu bauen, in Anbetracht des Zeitaufwandes aber nur, wenn er gesponsert wird. Denn sonst würde es in diesem Leben nicht mehr fertig werden.

Und was verstehst unter echtem Hypervisor?
Zum Vergrößern anklicken....
Halt so ein Ding, was in seinem eigenen System unterhalb der produktiv eingesetzten Systeme hockt. Xen, ESXi und so halt.
 
Gibt es eine bequeme Möglichkeit die VM zu suspenden?
Zum Vergrößern anklicken....
Ja, strg-alt-2 drücken um in die Managementkonsole zu kommen und dort "savevm name" eingeben. Später kann man über eine Kommandozeilenoption oder über "loadvm name" wieder laden. Das funktioniert nur mit Images im qcow2-Format, nicht mit Raw-Images oder anderen.
 
Yamagi schrieb:
Ja, strg-alt-2 drücken um in die Managementkonsole zu kommen und dort "savevm name" eingeben. Später kann man über eine Kommandozeilenoption oder über "loadvm name" wieder laden. Das funktioniert nur mit Images im qcow2-Format, nicht mit Raw-Images oder anderen.
Zum Vergrößern anklicken....

aha, kann ich denn mein altes vmware3 image in diesses qcow2 Format
konvertieren?

Qemu Tools muss man vermutlich dann auch noch reininstallieren, hmm
man schauen, erstmal alles upgraden und danach installieren ,)
 
Das zu qemu gehörende Tool qemu-img(1) kann Images konvertieren. Aber Windows mag das unter Umständen nicht sonderlich...
 
Allerdings funktioniert win4bsd nicht auf FreeBSD/amd64 und ist außerdem merklich langsamer als aktuelle qemu-Versionen. Würde ich nur als zweite Möglichkeit sehen, wenn qemu selbst ganz und gar den Dienst verweigern sollte.
 
habe jetzt qemu in Bennutzung, mit den aktuellstem FreeBSD Ports
für kqemu und qemu selbst.

Der Aufruf:

/usr/local/bin/qemu -hdc /home/.vm/Win/win2000.qcow2 \
-k de -vnc 127.0.0.1:10 -usb -usbdevice tablet -monitor tcp::5920,server,nowait\
-m 512 -net nic -net tap,ifname=tap10

Festgestellt habe ich:


+Netzwerk lässt sich supertrivial und stabil einrichten
+Es kann alles unter einem dediziertem VM-User laufen (nicht der Desktop-User)
+Integriert sich wirklich schön ins System
+Auflösung 1280x1024 mit 16bit Farben geht problemlos

-Es ist definitiv einen Tick langsamer als vmware
-kernel-kqemu ist nicht stabil (weder 2000 noch XP)
-Direkt mit der Qemu Konsole arbeiten ist unbequemer und langsamer als über vnc
-Das Feature savevm/loadvm ist quasi Snapshotting, allerdings hängt das ganze
System ziemlich lange, als suspend - Funktion mE. völlig ungeeignet und auch
kein echtes Snapshotting weils so lange dauert
-Durch einen Snapshot reservierter Platz wird trotz delete nicht freigegeben
-vnc kann man zwar ein Passwort setzten, aber das Passwort funktioniert nicht,
eine Abfrage kommt, trotz korrekter Credentials
-man kann den vnc Port auf einen Unix Socket konfigurieren (Performance),
der Socket wird allerdings nicht erstellt, keine Fehlermeldung.

Insgesamt kann ich damit leben, qemu ist noch nicht fertig, aber hat gute Grund-
vorraussetzungen.



Einen Mangel allerdings gibts den ich unbedingt beheben möchte, Cut&Paste vom
Host-System in die VM rein.

Mache ich einen vnc-connect zu einer Windows Maschine (als Test) so geht cut&paste
Problemlos, zum qemu vnc-server allerdings nicht, da geht kein Cut&Paste.
 
rowa schrieb:
Welche QEMU-Version ist das?

Aktuell ist QEMU 0.10.2
Zum Vergrößern anklicken....

kqemu-kmod-devel-1.4.0.p1_2
qemu-0.10.2

Ist ein neues System (Lenovo T500) und alles frisch
installiert an Ports.

Sollten einige der Dinge gehen die bei mir nicht
funktionierten (mit "-" davor)??

Hast du eine Antwort auf die Cut&Paste - Frage?
 
-Es ist definitiv einen Tick langsamer als vmware

Solange es nur ein Tick ist ;-)

-kernel-kqemu ist nicht stabil (weder 2000 noch XP)

Ich habe mit (k)qemu unter BSD noch nicht viel Erfahrung. Unter Linux läuft kqemu stabil.

-Direkt mit der Qemu Konsole arbeiten ist unbequemer und langsamer als über vnc

Besser ist ein Login über ssh, wenn vorhanden. Siehe dazu

http://qemu-buch.de/d/Netzwerkoptionen/_Virtuelle_Netzwerke_konfigurieren#Port-Redirect

-Das Feature savevm/loadvm ist quasi Snapshotting, allerdings hängt das ganze
System ziemlich lange, als suspend - Funktion mE. völlig ungeeignet und auch
kein echtes Snapshotting weils so lange dauert

Hier muss qemu noch aufholen.

-Durch einen Snapshot reservierter Platz wird trotz delete nicht freigegeben

Muss ich mal testen. Ich arbeite lieber mit Overlay-Dateien.

http://qemu-buch.de/d/Speichermedien/_Images_anlegen#Overlay-Images_anlegen

-vnc kann man zwar ein Passwort setzten, aber das Passwort funktioniert nicht,
eine Abfrage kommt, trotz korrekter Credentials

Bei qemu 0.9.1 hatte ich damit keine Probleme.

-man kann den vnc Port auf einen Unix Socket konfigurieren (Performance),
der Socket wird allerdings nicht erstellt, keine Fehlermeldung.

Muss ich mal testten.

- Cut&Paste vom Host-System in die VM rein.

Das ist was ich am meisten vermisse. :-(
 
rowa schrieb:
Es ist definitiv einen Tick langsamer als vmware
Solange es nur ein Tick ist ;-)
-kernel-kqemu ist nicht stabil (weder 2000 noch XP)
Ich habe mit (k)qemu unter BSD noch nicht viel Erfahrung. Unter Linux laeuft kqemu stabil.
Zum Vergrößern anklicken....

Hat jemand bereits irgendwo Benchmarks finden können?

kqemu laeuft stabil, die ring0-Erweiterung "kernel-kqemu" war gemeint.

-Direkt mit der Qemu Konsole arbeiten ist unbequemer und langsamer als ueber vnc

Besser ist ein Login ueber ssh, wenn vorhanden. Siehe dazu

http://qemu-buch.de/d/Netzwerkoptionen/_Virtuelle_Netzwerke_konfigurieren#Port-Redirect
Zum Vergrößern anklicken....

?
Ueber ssh habe ich keine GUI, und genau darums gings in erster Linie.

-Durch einen Snapshot reservierter Platz wird trotz delete nicht freigegeben
Muss ich mal testen. Ich arbeite lieber mit Overlay-Dateien.
Zum Vergrößern anklicken....

Ja, die Funktion mit den Overlay Files ist nicht schlecht!

-vnc kann man zwar ein Passwort setzten, aber das Passwort funktioniert nicht,
eine Abfrage kommt, trotz korrekter Credentials
Bei qemu 0.9.1 hatte ich damit keine Probleme.

-man kann den vnc Port auf einen Unix Socket konfigurieren (Performance),
der Socket wird allerdings nicht erstellt, keine Fehlermeldung.
Muss ich mal testten.
Zum Vergrößern anklicken....

Mach mal, ist ja nie auszuschliessen das ich hier nen Fehler drinnen habe.
Unix Sockets sollten bisschen Performance bringen, und ein Passwort kann
ja wohl niemals schaden :)

- Cut&Paste vom Host-System in die VM rein.
Das ist was ich am meisten vermisse. :-(
Zum Vergrößern anklicken....

Das ist einfach ein "must have".

Es gibt eine Loesung fuer den qemu Monitor, habe den link jetz nicht zur
Hand, da musste man irgendwas installieren.

Was ich aber braeuchte ist cut&paste fuer vnc.




Es gibt ja viele verschiedene Tools die dies (und vieles mehr, synergy
z.B.) ermoeglichen, sowas fehlt in qemu noch, keine Ahnung ob es sich
irgendwie machen laesst ohne das man im Gast System was installieren muss.

Das waere ideal.



Ansonsten ist qemu schon klasse, man kann es im Hintergrund laufen lassen,
eine Maschine scriptgesteuert ueberwachen, falls was crasht scriptgesteuert
neu starten usw. usf. - das ganze ist sicher mehr in Richtung Entwicklung
gebaut worden, aber ich finde einige der Features koennten auch fuer andere
Bereiche interessant sein...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben