VMware Server 2.0.2 erkennt nur 1 QuadCore CPU

[akyl]

Hallo,

ich habe hier einen IBM x3650 M2 Server auf dem ich ein CentOS 5.2 und einen VMware Server 2.0.2 installiert habe.
Dieser hat 16GB RAM und 2 x QuadCore Xeon E5504 2.00 GHz CPU.

Die Weboberfläche des VMware Servers zeigt nun aber nur 1 x QuadCore CPU an und wenn man im hostd Logfile nachschaut dann sieht man folgendes:

2009-11-04 11:38:22.886 'Libs' 47972205844704 info HOSTINFO: Seeing Intel CPU, numCoresPerCPU 8 numThreadsPerCore 2.
2009-11-04 11:38:22.886 'Libs' 47972205844704 info HOSTINFO: numPhysCPUs is 0, bumping to 1.
2009-11-04 11:38:22.886 'Libs' 47972205844704 info HOSTINFO: This machine has 1 physical CPUS, 4 total cores, and 8 logical CPUs.
2009-11-04 11:38:22.889 'Libs' 47972205844704 info LOCALE en_US.UTF-8 -> NULL

Das bedeutet für mich das der VMware Server wirklich nur 1 CPU erkennt.
Im Linux sehe ich per cat /proc/cpuinfo aber beide CPUs und alle 8 Kerne.

Hat dieses Problem noch wer anders oder kann mir wer einen Tipp zur Lösung des Problems geben?

Danke schon mal!

Grüße

[Dayworker]

Wieviele Kerne hattest du denn für die Lizenz angegeben?

[akyl]

Hat man das bei der Lizenzierung angeben können?
Ich habe nämlich noch einen weiteren VMware Server laufen - allerdings ist die Serverhardware ein wenig älter (IBM x3650 Xeon E5430 CPU 2.66GHz) - und dort erkennt er die beiden QuadCore CPUs.

Ich kann mich allerding nicht erinnern das ich da für den Lizenzschlüssel die Anzahl der Kerne angegeben habe.

[Dayworker]

"2009-11-04 11:38:22.886 'Libs' 47972205844704 info HOSTINFO: This machine has 1 physical CPUS, 4 total cores, and 8 logical CPUs. "
Der Nehalem E5504 ist ein reiner Quadcore ohne HT und wird vermutlich durch die Version 2.02 nur falsch als Singlesockel mit HT erkannt. Ich hab leider keine Ahnung wie ein einzelner Nehalem mit HT im VMserver eingeloggt wird.

[akyl]

Also schaut es so aus als ob der VMware Server eh alle Kerne erkennt und das nur falsch darstellt? Ist das korrekt?

Ich dachte die CPUs sind QuadCore mit HT....

[Dayworker]

Nö, nur einfache Quads. Siehe auch http://processorfinder.intel.com/detail ... Spec=SLBF9

[irix]

Also schaut es so aus als ob der VMware Server eh alle Kerne erkennt und das nur falsch darstellt? Ist das korrekt?

Ich dachte die CPUs sind QuadCore mit HT....

Deine Einstiegs Nehalems haben weder "Turbo" noch HT. Gibts einen Grund warum VMware Server 2 und nicht ein vSphere ESXi zum Einsatz kommt?

Gruss
Joerg

[akyl]

Die Verwaltung ist für den VMware Server 2 schon eleganter über die Weboberfläche gelöst.
Ist die Verwaltung für den ESXi nicht kostenpflichtig? vSphere ist ja nur begrenzt gratis oder habe ich das falsch verstanden?

[Dayworker]

Wenn ich das richtig mitbekommen habe, firmieren auch alle ESX(i)4 unter vSphere. Von daher redet Jörg über den ESXi4.

[irix]

Ja ich meine den Free ESXi. Bei so potenter Hardware wie du mit deinen 2 Nehalems will man doch normal alles herausholen oder nicht?

Also mit einem VI Client komme ich besser zurecht als ueber die VMware WebAccess Geschichten. Aber wenn man kein Windows hat ist das natuerlich eine K.O Kreterium.

Gruss
Joerg

[Dayworker]

Jörg hast du mal probiert, dich mit dem VI-Client vom ESXi4 auf den VMserver2 zu verbinden? Kannst du da auch VMs mit der v.HW-Version 7 vollständig bearbeiten oder meckert er?

[irix]

Jörg hast du mal probiert, dich mit dem VI-Client vom ESXi4 auf den VMserver2 zu verbinden? Kannst du da auch VMs mit der v.HW-Version 7 vollständig bearbeiten oder meckert er?

Das hab ich nur frueher mal ausprobiert.. und da meckerte er. Aber frag mich mal ob ich da schon vSphere hatte oder nicht. Auf meiner Arbeitsstation hab ich beide Clients.. da ich Kunden mit beiden Versionen habe. Aber der Client passt sich entsprechend immer an.

Gruss
Joerg

[Dayworker]

OT:
Also beim VI-C vom ESXi3.5 gehts nur bei v.HW=4 und bei 7 meckert er logischerweise. Beim 4er VI-C komm ich mangels ausreichend Speicher immer noch nicht weiter...
Wie hast du es eigentlich geschafft, beide Clienten auf einer Station zu installieren? Ich wollte den 3.5er zu Testzwecken in einem anderen Verzeichnis neben dem originalen vom Server2.00 installieren und scheiterte. Der 3.5er hat eiskalt den vom 2er deinstalliert und dann mein neu erstelltes Verzeichnis alleine mit dem 3.5er belegt.
Blöd dabei ist nur, daß ich den 2er nicht noch woanders gespeichert hatte und der VMserver2.00-Download bei VMware auch nicht mehr funktioniert.

[cron]

Hallo Forum,

Ich habe derzeit des gleiche Problem, nur dass der Server unter Win2008 R2 läuft.
Gibt es da schon eine Lösung für?
Tools wie cpuid HWMonitor zeigen mir 2 CPUs mit jeweils 4 Kernen an, im Windows Taskmanager sind 8 CPU-Graphen zu sehen, daher schätze ich, dass das Problem eher auf Seiten des VMware Servers zu suchen ist?
Bei voller Auslastung der VMs werden (laut Taskmanager) auch nur 4 Kerne belastet; In der Summary zeigt mir das VMware Admin-Panel "Intel(R) Xeon(R) CPU E5504@2.00GHz , 1 CPU x 4 Cores"

Hat jemand eine Idee?

Vielen Dank schonmal und Grüße

[Dayworker]

Mal davon abgesehen, daß W2k8-R2 offiziell als Host-OS nicht unterstützt wird, da der VMserver2.02 noch vor dem R2 herauskam und auch keinerlei Anpassungen mehr bekommen wird, kannst du bitte mal die Ausgabe von MPdetect verlinken. Vielleicht sieht man daran ja schon das Problem.

[cron]

sehr gerne:

Hardware information:
OEM ID: 0
Number of processors: 8
Page size: 4096
Processor type: 586
Active processor mask: 0xff
CPUID GenuineIntel ID= 0x106a5
cpu 0, Initial APIC-ID 0, Package-ID 0, Core-ID 0, SMT-ID 0
cpu 1, Initial APIC-ID 2, Package-ID 0, Core-ID 1, SMT-ID 0
cpu 2, Initial APIC-ID 4, Package-ID 0, Core-ID 2, SMT-ID 0
cpu 3, Initial APIC-ID 6, Package-ID 0, Core-ID 3, SMT-ID 0
cpu 4, Initial APIC-ID 16, Package-ID 1, Core-ID 0, SMT-ID 0
cpu 5, Initial APIC-ID 18, Package-ID 1, Core-ID 1, SMT-ID 0
cpu 6, Initial APIC-ID 20, Package-ID 1, Core-ID 2, SMT-ID 0
cpu 7, Initial APIC-ID 22, Package-ID 1, Core-ID 3, SMT-ID 0

Bei der Suche zu diesem Thema habe ich auch Hinweise gefunden, dass man in der vmx selbst die CPU/Kern-ID manuell vergeben kann, und damit die 'Auto'-Erkennung des VMware-Servers quasi übergeht. Ich fände es allerdings irgendwie natürlicher, wenn das System von vornherein 8 Kerne entdeckt und auch nutzt.

Danke und Grüße

[Dayworker]

Ich hatte es fast befürchtet. W2k8 loggt die Kerne komplett anders ein als alle OS bis einschließlich Win2003. Damit sind meine verlinken Screenshots nicht direkt vergleichbar.
Wenn ich mir jedoch deine Ausgabe so ansehe, geben die Werte einen Sinn und es scheint auch kein Bios-Problem vorzuliegen. Die Package-ID gibt den Sockel, die Core-ID die Kerne und die SMT-ID >0 den Hyperthreading-Kern an, nur aus der APIC-ID werde ich nicht ganz schlau.
Hmmm. Die VMware-EW sind wohl von der Tatsache ausgegangen, daß HT beim Nehalem immer an Board sein würde und wenn es Probleme bei dessen Erkennung durch ein fehlerhaftes Bios gibt, würden irgendwelche sinnlosen Einträge erscheinen. Das würde auch den Log-Ausschnitt des OP "akyl" mit CentOS5.2 als Host-OS erklären. Da taucht der E5504 ja ebenfalls als Einsockel Quad mit HT auf.
Auch wenn VMware an dieser Misere jetzt nichts mehr ändern wird, würde mich mal das "vmware.log" aus dem VM-Ordner interessieren. Darin erscheint dann vielfach die CPU direkt mit ihren erkannten Architektur-Namen. Kannst du das bitte noch verlinken, am einfachsten auf einen Freehoster wie den in meiner Sig.

Bei der Suche zu diesem Thema habe ich auch Hinweise gefunden, dass man in der vmx selbst die CPU/Kern-ID manuell vergeben kann, und damit die 'Auto'-Erkennung des VMware-Servers quasi übergeht. Ich fände es allerdings irgendwie natürlicher, wenn das System von vornherein 8 Kerne entdeckt und auch nutzt.

Die VMX-Datei ist nur für die VM und hat keinen Einfluß auf die Erkennung auf dem Host. Aus Lizenzgründen von SW auf Sockelbasis kannst du jedoch der VM per cpuid.coresPerSocket = "2" einen Singlesockel Dualcore-Rechner präsentieren. Höhere Werte als 2 machen auf dem VMserver1/2 keinen Sinn, dieser unterstützt nur 2 vCPUs in einer VM. Höhere Werte werden erst von der WS7 und Player3 akzeptiert. Die dann dazu auf WS7/Player3 nötige v.HW-Version 7 wird zwar auch vom VMserver2 unterstützt, allerdings beruhen VMserver2 und WS6.5 bzw Player2.5 anscheinend noch auf derselben Codebasis. WS7/Player3 sind dort wesentlich weiter.

[continuum]

Wie hast du es eigentlich geschafft, beide Clienten auf einer Station zu installieren?

das ist einfach - funktioniert sogar auf meiner LiveCD.

Vor der Installation des neueren Clients den Ordner der vorhandenen Installation kopieren. Dann den neuen installieren.

Anschliessend kann man die alte Version starten in dem man einfach den launcher direkt aufruft.

Viclients laufen ohne Registry-eintraege !

[Dayworker]

Uli die Frage an Jörg stammte noch aus dem November 2009. Wenn man dort zuerst den beim VMserver2.00 noch mitgelieferten Vi-Client oder den vom ESX(i)3.5 installierte und dann den vom ESX(i)4 drüberbügelte, hattest du nachher die Unterverzeichnisse 2.5 und 4.0 und diese enthalten dann die dort üblichen Einträge. Damit konnte ich dann auch problemlos den ESXi3.5 als VMserver2-VM administrieren. Einzigster Haken an der Sache blieb trotz v.HW-Version 7 und vSphere-Client, daß du trotzdem keine VM mit einer v.HW-Version >4 auf dem VMserver2 vollständig bearbeiten konntest. Schuld daran sind fehlende Einträge im Unterverzeichnis "SDK" und "Client". Den Verbindungsaufbau hatte ich schon mal im Thread VI-Client oder neuer mit Server 2.0x beschrieben.

Also der Vi/vSphere-Client greift auf dem Host auf die Datei "clients.xml" per url = https://<IP_des_ESXi>/client zu und lädt dann dort ggf für die angegebene Version den in der DownloadUrl hinterlegten Verwaltungs-Clienten runter. Danach greift er per url = https://<IP_des_ESXi>/sdk auf die Dateien "vim.wsdl", "vimService.wsdl" und "vimServiceVersions.xml" zu und entscheidet daran wahrscheinlich (kann mit keinem ESX4 testen) welchen Zweig er nutzen muß. Beim VMserver2 findet sich die Dateien übrigens im Programme-Ordner unter "VMware\VMware Server\hostd\docroot\client" und "VMware\VMware Server\hostd\docroot\sdk".

Wenn man jetzt die Dateien durch deren Pendants vom ESX(i)4 ersetzen würde, könnte die vollständige Adminstration der v.HW-Version 7 doch noch per vSphere-Client gelingen. Leider läuft der vSphere4 nicht als VMserver1/2-VM und vermutlich aus demselben Grund, wie das auch schon bis zu WS6.51 oder 6.52 der Fall war. Mit der 6.52 oder 6.53 wurde das meines Wissens geändert, leider wurde ja seitdem nichts mehr am VMserver2 gemacht...

[cron]

hier die vmware.log aus einer gerade erstellten VM:
http://ifile.it/901xlif/vmware.log

Es scheint so als würde er die Anzahl Kerne halbieren, weil er meint, es seien HT-Cores...

[Dayworker]

Aug 16 17:17:13.362: vmx| hostCpuFeatures = 0x4c4001fd
Aug 16 17:17:13.362: vmx| hostNumPerfCounters = 4
Aug 16 17:17:13.362: vmx| CPU0: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| CPU1: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| CPU2: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| CPU3: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| CPU4: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| CPU5: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| CPU6: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| CPU7: PMC: IA32, Nehalem-C or later [c:0 f:1 e:0]
Aug 16 17:17:13.362: vmx| MONITOR MODE: allowed modes : BT HV HWMMU
Aug 16 17:17:13.362: vmx| MONITOR MODE: user requested modes : BT HV HWMMU
Aug 16 17:17:13.362: vmx| MONITOR MODE: guestOS preferred modes: HWMMU HV BT
Aug 16 17:17:13.365: vmx| MONITOR MODE: filtered list : HWMMU HV BT
Aug 16 17:17:13.365: vmx| HV Settings: virtual exec = 'hardware'; virtual mmu = 'hardware'

Also vom Log her sieht er eigentlich alle Kerne und stellt auch von sich aus die performanteste Virtualisierung für alle CPUs mit integriertem RAM-Controller (virtual exec = 'hardware'; virtual mmu = 'hardware') ein.

Laut VMTN Vmware server not recognize my cpu jedoch, erkennt er sogar nur einen Dualcore beim E5504.

If you check the compatible processors in the vmware server 2 user's guide you will see vmware server just supports until the Intel Xeon Quad Core 5300 series, not the newest 5400 or 5400 series. This is the reason vmware server 2 recognizes your Quad Core E5504 as Dual Core. Because it doesn't support your CPU.

Von der Warte muß du schon zufrieden sein, daß du 2 Quads installiert hast und so wenigstens 50% nutzen kannst.

[edit]
Quoting

[cron]

Danke für die Info. Wenns auch leider nicht ermutigend ist.

Zudem habe ich jetzt gelesen, dass VMware Server wahrscheinlich auslaufen wird und daher kann man wohl auch auf kein Update mehr hoffen. Davon bin ich ja am meisten enttäuscht.

Was kann ich jetzt am besten machen, um die Ressourcen des Rechners ein wenig besser zu nutzen? Kann ich eine VMware Workstation oder Player zusätzlich laufen lassen?
Ich könnte natürlich auch alle Windows Gäste in Hyper-V auslagern.
hmpf.
Das System ist ein gemieteter Server, auf den ich keinen physikalischen Zugriff habe, daher auch von vornherein die Wahl der Kombi Win2008+Server statt ESXi.

Bin dankbar für jederlei Ideen...

[Dayworker]

Wenn du keinen phys.Zugriff darauf hast, bist du leider etwas gekniffen. Vielleicht kannst du den Hoster mal darauf ansprechen, weil das Produkt VMserver in Kombination mit W2k8-R2 als Host-OS und Dual-Quad Nehalem funktioniert so nicht.

Einzigster möglicher Ausweg, wenn der Hoster mitspielt, wäre der ebenfalls kostenlose VMware-Player oder die Workstation/Player-Kombi im Eval-Modus. Bei der Kombi verlierst du dann zwar nach 30 Tagen den größten Teil der Workstation-Features allerdings wird der Player auch mitinstalliert und bleibt auch voll funktional.

Die WS/Player-Kombi ist auch die einzigste mir bekannte Möglichkeit, zwei verschiedene VMware-Virtualisierungsprodukte gleichzeitig auf demselben Host installiert zu haben.



PS:
Kannst du vielleicht noch etwas ausprobieren? Setz allerdings Bios-Zugriff auf dem Host voraus. Wenn du dort mal eine CPU komplett abschalten und dann bitte nochmal ein "vmware.log" der VM hochladen könntest, hätten wir eine Vergleichsmöglichkeit.

[cron]

Da der Server derzeit schon läuft und genutzt wird und ich zudem noch nicht in einen echten Performance-Engpaß laufe, muss ich Änderungen, die eine (längere) Downtime erfordern derzeit auf Eis legen.
Vor allem die Tatache, dass der Server eingestellt wird, lässt mich derzeit über non-VMware-Alternativen nachdenken, da ich das Thema wohl eher nicht aussitzen kann. Allerdings gehe ich davon aus, dass diese Forum nicht der richtige Ort für Diskussionen über Hyper-V und XEN und Co ist.

Vielen Dank nochmal für die Unterstützung und Fehleranalyse!

[Dayworker]

Ich würde VMware nicht komplett den Rücken kehren, dazu gibt es den kostenlosen Player und die kostenpflichtige Workstation, in der ebenfalls auch der kostenlose Player mitgeliefert wird. Damit kannst du also die Workstation kostenlos im Eval-Zeitraum von 30 oder 60 Tagen komplett nutzen und danach machst du alles, mit Einschränkung von Hot-Clones (mehr Unterschiede sind mir beim Draufschauen nicht aufgefallen), über den mitgelieferten Player. Workstation und Player sind beide wesentlich aktueller im Bezug auf unterstützte Host- und Gast-OS sowie neue CPUs. Auch nicht zu Unterschätzen ist die Tatsache, daß die VMserver1/2-VMs sich direkt auf Workstation und Player weiterbetreiben lassen. Du brauchst da also nichts konvertieren, bei OEM-Lizenzen müßte einzig nach dem Einspielen der aktuelleren VMware-Tools ggf neu aktiviert werden, da die Tools ja eine große v.HW-Änderung darstellen.