XEN Desktop Hardware

lockdoc

lockdoc

Well-Known Member
Hallo,

ich haett in naechster Zeit ein groesseres Project vor und wuerd mich vorab schonmal schlau machen wollen.


TLDR:
NetBSD Xen mit 3 gleichzeig laufenden dom1 (winXP, FreeBSD, Ubuntu) fuer Ruckelfreies arbeiten und spielen.


Volltext:
ich in nicht allzuferner Zukunft endlich mal meinen Desktop PC zu modernisieren.
Dazu soll dann frische Hardware ins Haus kommen. Das ganze wird noch 2-3 Monate Zeit haben, ich bin allerdings
jetzt schon an der Planung, damit ich mich schon mal gruendlich mit der Materie beschaeftige und nach dem Kauf alles Ruck-Zuck gehen kann.

Ich plane das ganze dann mit XEN als zu virtualisieren, damit ich mehrere OS's gleichzeitig laufen lassen kann,
und ganz auf die Schnelle ziwschen denen switchen kann, so wie zwischen normalen Applikationsfenstern.

Es sollte schon eine Virtualisierungsloesung sein, den ich wuerde mir gerne images machen von den Systemen in verschiedenen Stadien,
so dass ich beispielsweise schnell mal eins auswechseln kann, wenn es zu sehr zugemuellt ist.

Hier mal der geplannte Aufbau

Code: 
+ dom0:        NetBSD
+ dom1 Nr.1:   FreeBSD mit Fluxbox (o.a. leichtgewichtigtes)
+ dom1 Nr.2:   Windows XP
+ dom1 Nr.3:   Ubuntu


Die Homeverzeichnisse aller Guest Systeme werden uebers LAN (1Gbit/s) auf einen Server ausgelagert,
damit ich egal in welchem System ich gerade bin, auf die Daten zugreifen kann (NFS/Samba).
Darum wird der Festplattenplatz auch kein ausschlaggebenes Kriterium sein.


Die ersten 3 Systeme sollen gleichzeitig laufen und ich will nicht durch Langsamkeit im Arbeitsfluss genervt werden.
Ich gebe mal ein paar typische arbeitsmuster, um euch ein Bild zu machen, was die Kisten so leisten sollen.
+ Windows:
Code: 
__ Eclipse
__ Visual Studio
__ MS Office
__ Photoshop
__ halbwegs normale Spiele
__ HD Videos kucken
__ Flashvideos ruckelfrei kucken
__ Skype, Msn, QQ (sollten immer laufen)
__ iTunes

+ FreeBSD&Ubuntu:
Code: 
__ FreeBSD: http, svn, mysql server
__ Ubuntu mit der Gnome3 Shell
__ beide: HD Videos kucken
__ beide: Gimp, Office
__ beide: Eclipse



Natuerlich werden nicht alle Programme auf allen Systemen gleichzeitig laufen,
darum hier mal ein Beispiel wie es aussehen koennte.
(Scenario-1)
(von der Story her bin ich gerade nach Ubuntu gewechselt um mir von der Arbeit eine Pause zu goennen und jetzt einen Film zu kucken):
+ Win: Skype, Msn, QQ, iTunes, Outlook, Chrome (ca. 10-20 tabs)
+ FreeBSD: Eclipse, Apache+MySQL Server, Firefox+Chrome (jeweils ca. 10 tabs)
+ Ubuntu: Bittorrent Client (Vuze), streamripper, Edonkey (mlnet) und nebenbei ein Film in VLC oder mplayer

(Scenario-2)
Ein anderes Scenario waere, dass ich unter Windows ein halbwegs (kein mega brandneues) Spiel spielen moechte, und es sollte nicht anfangen zu ruckeln.
[Frage 01]: Angenommen, dass Spiel hat die Anforderungen: 2Ghz, 2GB Ram und Grafikkarte X, wieviel muesste ich wegen der Virtualisierungsloesung dazu rechnen, damit es den Anforderungen gleich kommt?


[Frage 02]: Benutzt man den dom0 eigentlich auch zum normalen arbeiten, oder sollte dieser sich wirklich nur um die Guest-OS's kuemmen und sonst nix machen?
[Frage 03:] Ist das Vorhaben so ueberhaupt moeglich?
[Frage 04]: Wie sieht es mit der Grafikkarte aus, wird diese beispielsweise unter Windows XP als ganz normal erkannt, so dass ich die normalen Windows Treiber installieren kann und ein paar spielchen zocken kann, oder nutzt man dann irgend ein Pseudo-Device von Xen?
[Frage 05]: Wenn ich eine Webcam/USB Stick anstecke, ist diese fuer die Systeme sichtbar
[Frage 06]: Sollte das Hostsystem 32 Bit oder 64 Bit sein und kann bei einem 32 Bit Host auch 64Bit Guests und umgekehrt betrieben werden? Kann ich das generell mixen?
[Frage 07]: Was wuerdet ihr mir an Harware fuer die Kiste empfehlen, damit ich gut arbeiten kann.


[Frage 08]:
Zudem habe ich noch einen relativ kraftvollen Server (FreeBSD8 64bit, ZFS Raid-Z mit 4 x1TB, 8GB Ram, Core 2 Duo E7400 2.8Ghz).
Angeschlossen werden Beide im Lan ueber 1Gbit/s Leitung mit IntelPro NICs.
Kann ich den Server irgendwie nutzen, um XEN-seitige Rechenaufgaben oder sonstiges an den virtuellen Guests zu unterstuetzen?

[Frage 09]: Sind die Gast Systeme berechtigt beispielsweise die eingebaute Netzwerkkarte in den Monitormode zu setzen?
[Frage 10]: Hat jemand schon aehnliches in Angriff genommen und evtl. das ganze dokumentiert?
[Frage 11]: Optional hatte ich mir ueberlegt, dass spaeter noch ein Hackintosh als dom1 Nr. 4 kommen koennte, da ist allerdings die Frage inwiefern das ueberhaupt unterstuetzt wird.


Danke erstmal fuers Lesen des langen Textes!
Wer jetzt noch motiviert ist die ein oder andere Frage zu beantworten, oder eventuell einen Tip hat,
oder mir sagt, dass ich was uebersehen habe, der ist natuerlich gern wilkommen.

LG
lockdoc
 
3D Grafik verträgt sich in der Praxis nicht mit Virtualisierung. Die Grafikkartentreiber brauchen Zugriff auf die GPU. Die GPU hat unbeschränkten Zugriff aufs RAM d.h. ein bösartiger Shader und Xen ist machtlos. IOMMUs könnten das in der Theorie lösen.
 
zocken mit ner xen domu^^, damit wirste da nicht gluecklich. Was du ehern in betracht ziehen solltest wäre Virtualbox. Setzte dir nen Windows oder Linux als Unterbau auf, da kannste zocken wie de lustig bist und in die VMs hauste dir dein FreeBSD/Ubuntu/Hackintosh^^ und/oder Netbsd.
Aber auch bei der Variante 64 bit als Unterbau und 32 bit Gäste sind kein Problem, bei Xen genauso.
USB Passthrough funktioniert bei Xen und bei Virtualbox soweit ich gehoert hab auch.
 
@DerMoench,

hmm, wenn ich mir den Link deines Vorposters angucke, dann scheint das ganze doch in Xen 4.0 ueber IOMMUs geloest zu sein, wenn man das richtige Mainboard und den entsprechenden CPU besitzt und das OS nicht paravirtualisiert sondern ein fully virtualized OS drauss macht.

Da bei mir der Hardware Kauf noch vor der Tuer steht, werde ich die entsprechenden Komponenten natuerlich beruecksichtigen.

Oder habe ich da was ueberlesen?
 
Du hast schon recht, mit Xen 4 wurde GPU-Passthrough voll und ganz implementiert. Setzt halt VT-d / IOMMU auf der Hardware voraus ... ;)
 
Das Problem ist, dass Vt-d dank Intels komischer Produktpolitik auf dem Desktop kaum zu realisieren ist. Zwar kann eine ganze Reihe Prozessoren es inzwischen, die zugehörigen Chipsätze aber nicht. Als ich vor einigen Wochen geschaut habe, gab es kein einziges Board, was neben einer brauchbaren Ausstattung auch Vt-d bot. Bei AMD sieht es da im High-End ein wenig besser aus. Schon einige 890FX-Boards unterstützten IOMMU, die 990FX sollen es alle tun. Und zumindest bei Gigabyte weiß ich, dass es die Optionen im BIOS gibt. Ob sie wirksam sind, ist allerdings eine andere Frage...
 
Kommt auf den Xeon an:

- Bei den LGA1155 Xeons stellt sich das gleiche Problem wie bei den Desktopvarianten. Das einzige Board war Vt-d könnte wäre das Asus P8B WS mit C206-Chipsatz. Leider unterstützt es Vt-d laut Aussage vom Asus-Support Anfang Mai auf Xeon-Prozessoren derzeit nicht. Die Nachfrage, ob es denn auf den Desktopmodellen ginge, habe ich mir selbst mit "Nein" beantwortet.

- Die "richtigen" Xeon-Boards für die diversen größeren Sockel (NICHT die Kiddie-LGA1366-Boards!) können es meist. Allerdings ist natürlich sehr zu empfehlen im Einzelfall zu recherchieren und zur Not auf einfach den Support des Herstellers anfragen.

----

- Bei AMD können es wie oben schon gesagt einige 890FX-Boards für AM3. Für AM3+ unterstützen alle Chipsätze der 900er Serie IOMMU. Allerdings muss dafür BIOS-Support existieren.

- Bei Sockel G34 und C32 gilt das Gleiche wie bei Intels Xeons. Alle sollten es können, man muss aber im Einzelfall recherchieren und notfalls fragen.
 
Danke schon mal jetzt weiss ich wenigstens, dass es realisierbar ist, solange ich die richtige Hardware nehme.

Wie siehts mit den anderen Punkten aus, beispielsweise die generelle Hardware Anforderung, damit fluessiges Arbeiten dann auch moeglich ist.
 
Ich habe ein ähnliches Setup:
  • Desktop (Windows 7)
  • Fileserver (Solaris wg. ZFS), auf dem auch die VMs liegen
  • Virtualisierungsserver (bei mir VMware ESXi)
Letzter ist erst später dazugekommen, weil ich die Performance von XEN auf dem Desktop (ohne 3D) unter Last nicht so prickelnd fand (der Desktop fühlte sich dann sehr träge an, trotz eigener Festplatten für das Desktop-OS, aber das ist auch schon wieder 2 Jahre her).

Es sind alles AMD-Kisten (wg. ECC-Support auf normalen Mainboards, gibt es bei Intel nur auf den kostspieligen Workstation- und Serverboards).
Prinzipiell würde ich viele Kerne (auch langsamer getaktet) und so viel RAM wie möglich empfehlen.

Auf die VMs (Linux, *BSD, Windows) greife ich im Alltag mit ssh mit X-Forwarding, VNC (im LAN noch erträglich) und RDP zu.

Die Rechenleistung des Fileservers würde ich lieber für ZFS Compression verwenden. Der Performancegewinn ist - je nach Workload - beachtlich.

In Anbetracht der wenigen (eher negativen) Erfahrungsberichte im Netz zu Xen und 3D würde ich davon eher Abstand nehmen.
Falls du es doch ausprobierst, lass uns das Ergebnis wissen. :)
 
Zuletzt bearbeitet:
Azazyel schrieb:
Auf die VMs (Linux, *BSD, Windows) greife ich im Alltag mit ssh mit X-Forwarding, VNC (im LAN noch erträglich) und RDP zu.
Zum Vergrößern anklicken....

Also ich will mich direkt vor die XEN Kiste setzen und diese direkt als Desktop nutzen und nicht via Netzschnittstele darauf zugreifen.

Danke fuer die Links
 
Naja, intern wird bei KVM und auch Xen das VNC-Protokoll zur VM-Darstellung eingesetzt ...

Wenn ich irre, bitte korrigieren ... ;)
 
Also gut, den Processor und das Mainboard werde ich wohl anhand der IOMMU Kretierien kaufen. Wie sieht es mit dem benoetigtem RAM aus. Ich haett mir ueberlegt, dass ich erstmal 4GB verbaue.
Macht es da einen Unterschied ob ich ECC oder keinen ECC nehme?

Hat noch Jemand ein paar Ideen zu den anderen Fragen?
 
Ja ECC RAM muss vom Board (und CPU) unterstützt werden. Intel hat die bescheuerte Produktpolitik ECC RAM Support sich extra bezahlen zulassen. Bei AMD kann es fast jede CPU nur die Mainboardhersteller sparen es gern ein, weil die meisten Kunden den Unterschied nicht kennen. ECC RAM kostet im Einkauf etwas mehr. Dafür reduzierst du das Risiko der unbemerkten Datenkorruption (Alphastrahlung, Spannungsschwankungen, Pech) im RAM aufs praktisch vernachlässigbare. Bei den aktuellen RAM Preisen würde ich lieber etwas weniger RAM und dafür ECC RAM haben statt eines Datenschredders. Wenn du Intel CPU und Chipsatz mit Vt-d (IOMMU) kaufst könnte es sein das du sogar ECC RAM brauchst.
 
Bei AMD unterstützt Asus auf fast allen (nicht allen, in die Spezifikation schauen!) Mainboards ECC. Bei Intel sagt Crest es, der C206 und damit auch das Asus P8B WS als einziges Board mit diesem Chipsatz kann ECC. Nur gibt's da das Vt-d Problem... Es gäbe da noch die beiden kleineren Chipsätze C202 und C204, wobei man da auf dem Desktop in meinem Augen doch schon gegen Ausstattungsprobleme läuft. Haben halt Fokus auf Single-CPU-Server. Außerdem sind die Boards mit diesen recht teuer.
 
lockdoc schrieb:
Also gut, den Processor und das Mainboard werde ich wohl anhand der IOMMU Kretierien kaufen. Wie sieht es mit dem benoetigtem RAM aus. Ich haett mir ueberlegt, dass ich erstmal 4GB verbaue.
Zum Vergrößern anklicken....
Das ist m.E. definitiv zu wenig. Ich habe auf meinem Notebook 3GB, auf meinem Desktop 4GB und da läuft jeweils nur ein OS drauf. Bei dem Setup würde ich *mindestens* 8GB nehmen. RAM ist wirklich kritisch, bei sovielen gleichzeitigen Prozessen.
Macht es da einen Unterschied ob ich ECC oder keinen ECC nehme?
Zum Vergrößern anklicken....
ECC gibt dir halt höhere Ausfallsicherheit. Ist bei einem Desktop m.E. nicht entscheidend. Lieber doppelt so viel normalen RAM nehmen, wenn du das Geld hast.

Bez. Registergröße: Der Host sollte auf jeden Fall 64Bit sein, bei den Gästen kannst du es dir dann aussuchen.

Frage: Warum brauchst du überhaupt FreeBSD und Ubuntu gleichzeitig? Außer zum testen von Applikationen leuchtet mir das nicht ein...
 
Wenn du Mehr ausgeben kannst und willst kannst du einen mac pro kaufen und dann ich glaube vmware fusion wars.
 
Na ich wuerd das ganze schon gern mit XEN machen und NetBSD, da ich mit beiden noch nicht gearbeitet habe und mich sozusagen dann damit nebenbei befasse.

Und mac (als Hackintosh), soll ja dann oben drauf laufen und nicht als Server, genauso wenig will ich windows als Server haben. xD

Aber Danke fuer den Tipp
 
lockdoc schrieb:
Na ich wuerd das ganze schon gern mit XEN machen und NetBSD, da ich mit beiden noch nicht gearbeitet habe und mich sozusagen dann damit nebenbei befasse.

Und mac (als Hackintosh), soll ja dann oben drauf laufen und nicht als Server, genauso wenig will ich windows als Server haben. xD

Aber Danke fuer den Tipp
Zum Vergrößern anklicken....

Kurzantwort: Sinnlos was du vorhast, schminks dir ab.

Langantwort: Ich versuche es immer mal wieder seit nunmehr fast 3 Jahren. GPU Passthrough läuft in Xen 4 auf Linux mittlerweile, aber nicht so gut, dass man es wirklich nutzen will, denn das drumherum ist großes Gefrickel. Vor allem solltest du dann 2 GPUs benutzen. Was dir da dann auch gut reinfickt ist das Virtuelle USB Geraffel - das stinkt einfach. Als Hardware kommt da bei mir ein Core i7 auf einem Supermicro X58 Board zum Einsatz. Der Chipsatz kann VT-d, _aber_ das BIOS hatte ich erst nach Kontakt zum Supermicro Support, welcher mich direkt an einen BIOS Entwickler weitergelietet hat mit mehrwöchigem Gefrickel so weit, dass Xen mit VT-d wollt, denn das Bios hat in seiner initialen Version damals etwas mit Informationen gegeizt auf die Xen zugriff haben wollte.
Ende vom Lied: Ja, nach 2 Jahren des versuchens ist es mittlerweile möglich, aber wollen tue ich es nichtmehr weil es nach wie vor zu viel gefrickel ist.
 
Nutzt man denn die Dom0 als regulaeres System (so dass ich darin normal arbeite) oder ist das nur zum verwalten der anderen Systeme da
 
dom0 ist im Grunde das Hostsystem, das in die Rolle einer VM gezwängt wurde. Ja, damit arbeitet man dann wie bisher (so ziemlich) ...
 
Angenommen es laeuft NetBSD dom0 und es laufen 2 dom1, wobei eine dom1 auch ein NetBSD mit dem selben Xorg Setup ist.
Laeuft die dom0 dann performanter oder macht es kein Unterschied zur dom1?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben