Virtualisierung und FreeBSD?

[hugly]

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?

[Yamagi]

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.

[TODuke]

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

[crotchmaster]

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.

[Yamagi]

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.

[TODuke]

Hallo und danke für die Informationen.
Ist den seitens der Entwickler einer entsprechende Kernelschnittstelle angedacht?
Und was verstehst unter echtem Hypervisor?

Gruss TODuke

[hugly]

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.

[Yamagi]

Ist den seitens der Entwickler einer entsprechende Kernelschnittstelle angedacht?

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?

Halt so ein Ding, was in seinem eigenen System unterhalb der produktiv eingesetzten Systeme hockt. Xen, ESXi und so halt.

[Yamagi]

Gibt es eine bequeme Möglichkeit die VM zu suspenden?

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.

[hugly]

Zitat von Yamagi

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.

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 ,)

[Yamagi]

Das zu qemu gehörende Tool qemu-img(1) kann Images konvertieren. Aber Windows mag das unter Umständen nicht sonderlich...

[rowa]

Zitat von hugly

Wie schauts aus? Was würdet ihr mir raten?

Hallo,

neben der reinen QEMU-Variante gibt es noch win4bsd. Für den privaten Gebrauch ist es kostenlos. Es basiert auf einer älteren QEMU-Version.

Man kann QEMU und win4bsd auf einen Rechner betreiben. Als GUI für QEMU ist AQEMU zu empfehlen.

Siehe http://qemu-buch.de/d/QEMU_unter_BSD

[Yamagi]

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.

[hugly]

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]

Zitat von hugly

habe jetzt qemu in Bennutzung, mit den aktuellstem FreeBSD Ports für kqemu und qemu selbst.

Welche QEMU-Version ist das?

Aktuell ist QEMU 0.10.2