MAX Anzahl CPU´s die genutzt werden ?

[GTRDRIVER]

Hallo Leute

Ich habe folgende Config:

Debian mit 2.6.33er Kernel
VMWARE Server 2.x (aktueller Download von VMWARE)

Maschine.
Server mit 2x Xeon Quadcore (8reale Kerne)
12GB RAM

VMWARE Server ist installiert und läuft - ich bin ein wenig verwirrt, das mir das ADMIN Interface (WEB) nur 1 CPU mit 4 Kernen anzeigt.

ist das korrekt - kann VMWARE SERVER nur 1 CPU mit X kernen ansprechen oder habe ich einen Config-Fehler ?

Bin für jeden Hinweis dankbar.
CU

[Dayworker]

VMware nutzt alle dem Host-OS bekannten und eingeloggten Kerne.
Die Frage lautet für mich daher eher, wie du den VMserver2 zu einer funktionalen Inst auf Debian mit Kernel 2.6.33 bewegen konntest

[GTRDRIVER]

Hi

ich habe auch ein wenig gesugt da das install-Script immer abgebrochen hatte - habe dann aber einen Workaround gefunden:

http://www.fedorawiki.de/index.php/VMware_Server

Ich entnehme deiner Frage einige Skepsis ? - was passt nicht ?

CU

[Dayworker]

Meine persönliche Meinung dazu?
VMserver und Linux sind seit Kernel 2.6.26 kein gutes Bündnis mehr, da sich sich beide Versionen nur mit Hilfe der Any-Any- oder sonstiger Patches vernünftig in Betrieb nehmen lassen. VMware macht halt den Kernelwahn nicht mit und verlangt auch unter Linux nach einer richtigen Server-Version ala RHEL, CentOS etc pp.
Richtig witzig wird es aber dann, wenn das Host-Linux schon auf KMS (mit Ubuntu 8.10 erstmals im Consumer-Einsatz) setzt und die "Xorg.conf" deshalb entweder leer oder nicht mal mehr vorhanden ist. Dann fehlen im Gast auch gerne mal einige Keyboardtasten. Diesem Umstand hat VMware im Server2-Manual auch ein Extrakapitel gewidmet...

[Dayworker]

Der letzte Absatz im verlinkten Wiki (Anmerkungen zum Zugriff auf physikalische Partitionen) enthält in meinen Augen einen bösen Schnitzer:

Windows als VM mit physik.Device-Zugriff als Datenträger läßt sich später meistens auch wieder an den Start bringen, aufgrund der vielen geänderten HW ist dann aber zumindest eine Reaktivierung bei M$ nötig. Nicht vergessen werden darf dabei, daß VMware diesen phys.Diskzugriff offiziell bei der Version 2 nicht mehr bewirbt. So wie die Meldungen im VMTN waren, hat es VMware wohl nur nicht mehr rechtzeitig vor dessen Veröffentlichung geschafft, alle Tests abzuschließen. D.h., die Funktionalität sollte bei Version 2.00 auf jeden Fall noch vorhanden gewesen sein. Es wurde nur die Möglichkeit dazu per GUI entfernt und du bist auf manuelle Einträge direkt in der VMX-Datei angewiesen. Dennoch könnten sich dort böse Bugs versteckt haben und mit den neueren Windows-Versionen fällt der phys.Diskzugriff sowieso aus. Aber das wurde hier ja auch schon öfter mal behandelt.

Linux ist bei solch umfassenden HW-Änderungen zwischen VM und nativ meist nicht so gnädig und stellt dann schon mal ganz gerne komplett die Zusammenarbeit dauerhaft ein.

[GTRDRIVER]

Hi

Oha - da hab ich mir ja was angetan....
Hatte VMWARE Server testweise auf einer anderen Maschine für 2 Monate aufgesetzt (2.6.2x Kernel) - das lief problemlos - war restlos begeistert und daraufhin wild entschlossen, einen Neuen Server zu bestellen um VMWARE Server 2.2 auf einer schnellen Hardware einzusetzen... - zu früh gefreut...

Der nun eingesetzte Server ist hardwaretechnisch natürlich relativ up to date - daher weiss ich nicht, ob ich mit 2.6.2x die Hardware komplett angesprochen bekommen - währe evtl einen Versuch wert..

Ganz ehrlich: Was würdest du mir raten ?

[Dayworker]

Uiiii. 'tschuldigung, daß wird jetzt etwas länger.

Da VMware ein Server-OS als Betriebssystem vorsieht, spricht auch nichts gegen eines der von mir zuvor genannten, wenn es denn unbedingt Linux sein soll...
CentOS5.4 setzt dabei sogar noch auf den damals auch bei Suse10.2 zum Einsatz gekommenen Kernel 2.6.18-XXX und wurde aufgrund seiner langen Reifezeit auch als Grundlage für den aktuellen XenServer5.5 genommen. Soweit also zum Thema neue HW und alte Kernel-Versionen.
Das Host-OS muß ja nur eine zuverlässige Basis für den Virtualisierungseinsatz darstellen und laut VMware sollte es gleichzeitig auch für nichts anderes (...) genutzt werden, also interessieren dort auch keine flackerfreie Umschaltung der Bildsschirmmodi (KMS) oder sogar 3D-Support in der GUI. Aus dem gleichen Grund bringen richtige Server auch ihren eigenen meist schon uralten Grafikchip gleich onboard mit. Dafür bringt jedes Server-OS noch Treiber mit und für die Ausgabe von Statusinformationen reicht das auch völlig aus.

Auch wenn ich keine Zahlen, Meßwerte oder dergleichen vorlegen kann, aber mit einem unterstützten Server-Windows als Host-OS läuft der VMserver irgendwie runder und auch performanter. Dazu umgeht man damit auch einige Probleme mit dem Linuxkernel. Bei Linux gebietet der Kernel allein über alle Belange und gestattet den laufenden Programmen nur wenige Eingriffsmöglichkeiten. Als Beispiel sei dort die Einstellung "Fit all virtual RAM into Host RAM" genannt. Unter Windows wird damit die Auslagerung allen VM-RAMs durch das Host-OS verhindert, dagegen hat Linux etwas und lagert ungeachtet dieser Einstellung immer bei hoher Host-RAM-Auslastung den Speicher aus. Durch dieses Swappen steht für weitere Anwendung natürlich freier Speicher zur Verfügung, allerdings bricht gleichzeitig auch die Leistung in der(den) VM(s) zusammen und da das Host-OS nur (...) zum Hosten der VM(s) genutzt werden soll...

...und JA für die kostenpflichtige Workstation ab Version 7 soll VMware dafür auch eine Lösung mitbringen. Das hilft aber beim VMserver1 und auch noch bis zum VMserver2.02 nicht weiter, diese sind näher mit der WS-Version 6.5 verwandt und da existiert dieses Problem auch noch.

[Mystefix]

Uiiii. 'tschuldigung, daß wird jetzt etwas länger.

Als Beispiel sei dort die Einstellung "Fit all virtual RAM into Host RAM" genannt. Unter Windows wird damit die Auslagerung allen VM-RAMs durch das Host-OS verhindert, dagegen hat Linux etwas und lagert ungeachtet dieser Einstellung immer bei hoher Host-RAM-Auslastung den Speicher aus. Durch dieses Swappen steht für weitere Anwendung natürlich freier Speicher zur Verfügung, allerdings bricht gleichzeitig auch die Leistung in der(den) VM(s) zusammen und da das Host-OS nur (...) zum Hosten der VM(s) genutzt werden soll...

Das Swappen kann man Linux aber auch teilweise abgewöhnen.

wenn man mal "sysctl -a | grep vm" in der linux console eingibt befindet sich auf folgender Parameter darunter.

vm.swappiness = 60 (dies ist der Standardwert)

setzt man nun diesen Wert mittels "sysctl -w vm.swappiness=0" , dann lagert Linux nur noch dann Speicher in den Swap-Bereich aus wenn es absolut notwendig ist.

Durch diese Befehl wurde allerdings diese Parameter nur für die Laufzeit gesetzt und ist nach einem Reboot wieder verschwunden.

Soll dies dauerhaft so sein, einfach die Datei /etc/sysctl.conf um folgenden Eintrag erweitern.

vm.swappiness = 0

[e-e-e]

Hallo,

darüber diskutieren wir hier schon seit Jahren. Gib' mal hier in der SuFu swappiness ein und Du findest die aus meiner Sicht optimalen Parametereinstellungen, aber wie Du schon sagtest:

Das Swappen kann man Linux aber auch teilweise abgewöhnen.

.
Linux hat den Vorteil, dass reguläre Programme keine "Macht" über das OS / Rechner / Resourcen bekommen können, das ist aber u.U. in unserer Situation ein Nachteil, wobei meine Möhre mit den erwähnten Einstellungen sehr sehr gut läuft.