VMware-Forum

Kurz zum Setup:
Host: Win 7 X64 SP1 16GB Ram alles andere ist Standard. i5-2400 4Kerne, Bios aktuell und VT ist dort ebenfalls aktiviert.

VMWare Workstation 9.0.2 1031769 (also die neueste)

Gast:; Ubuntu 12.04 TLS X64 , VMTools sind installiert (schon mehrmals gemacht, keine openvm tools!)

Egal was ich einstelle, immer wenn ich die VM mit mehr als einer vCPU oder VCore versorge bleibt die nach einer gewissen Zeit hängen.Damit meine ich das diese Maschine einfriert. TaskMGR zeigt dann für diesen Task, Vollast an.

Andere Gäste (Windows) funktionieren einwandfrei.
Logdatei ist nix brauchbares drin.
Jetzt das große WTF!?! :/

Verlinke mal bitte das soweit vorhanden, ungekürzte "vmware.log" auf einen Freehoster.
Laufen irgendwelche Virenscanner, Sec-Suiten oder eine Firewall abseits der Win-Beilage?

https://dl.dropboxusercontent.com/u/20012855/vmware.log
Hängen geblieben bei 2013-08-14T21:36:XX

Virenscanner und Firewall hab ich natürlich schon gecheckt.
Habe in der Zwischenzeit mit ein paar Startparametern von Linux gefummelt. Aber ohne Wirkung: clocksource=acpi_pm und notsc bringen nichts und noapic nolapic apic=off schießt mich wieder auf einen Kern = Stabil

Dachte auch erst es stimmt was mit meiner Ubuntu Installation nicht, aber eine 2. Ubuntu Installation hat das selbe verhalten. Ubuntu auf Virtualbox mit 4 VCore läuft dagegen stabil.
Nur VmWare und virbox vertragen sich nicht zusammen auf einen host.

2013-08-14T21:07:53.032+02:00| vmx| I120: Log for VMware Workstation pid=8860 version=9.0.2 build=build-1031769 option=BETA

Installiere dir mal die Vollversion und keine Beta...

Das sich zwei Virtualisierer auf einem Rechner in die Quere kommen, sollte jedem klar sein. Das Virtualisierungsprogramm muß zu seiner Fuktion sehr tief im System ansetzen.

Hab halt auf die neueste Beta geupdatet , aber hatte auch da den Bug :/

Ob du nun die neueste oder eine ältere Beta einspielst, macht hier keinen Unterschied. Beta ist und bleibt Beta, da sind Probleme doch normal und als Beta-Version sind diese auch nicht für den produktiven Betrieb freigegeben.

Was Du sagen willst ist also, Du weist auch nicht warum ich das Problem habe. Toll, bin ich wieder der einzige mit dem Fehler! :/

Was willst du denn jetzt hören, daß die Beta-Version einen oder eher viele Fehler hat und du anscheinend trotzdem nicht gewillt bist, eine offizielle Vollversion zu installieren

Es wird sich hier wahrscheinlich niemand finden, der sich mit Beta-Versionen herumschlägt. Ich hab jedenfalls dein Log nach dem gefundenen Beta-Eintrag überhaupt nicht mehr durchgesehen. Erfahrungsgemäß sind 50 Prozent der Einträge irgendwelcher Debug-Log-Kram, der in dieser Form in keiner Vollversion zu finden ist und sich daher auch keine Fundstellen oder irgendwelche Ansatzpunkte im Web finden lassen.

Auch nicht vergessen sollte man bei der Sache, daß eine Lösung für eine Beta-Version nachher abseits einer Beta-Version zu ganz neuen Problemen führen kann. Im Idealfall ignoriert das jeweilige VMware-Produkt unnütz gewordene oder ihm unbekannte VMX-Einträge. Das muß aber nicht immer so sein.

Hallo!

Habe ein ähnliches bwz. eventuell das gleiche Problem. Habe unter VMware Workstation 9.0.2 eine Ubuntu VM mit mehreren vCPUs laufen (habe es mit 2 und 4 vCPUs getestet) und wenn ich die VM etwas fordere bzw. unter Last setze, hängt sie die VM auf und die Host CPUs laufen permanent auf 100%.

Hier der Log der VM:
https://gist.github.com/thasmo/bdcced0e ... tfile1.txt

Was mir hier auch schon auffällt ist, dass im Log " The VMware Tools package is not running in this virtual machine." steht, obwohl die VMware Tools installiert sind. Shared Folder funktionieren z.B.

Wenn ich der VM nur einen vCPU gebe, dann läuft alles wie geschmiert.

Habe das Ganze schon mit Ubuntu 13.04, 12.10 und 12.04 getestet, jeweils mit 32bit und 64 bit. Das Problem taucht immer auf sobald mehr als 1 vCPU konfiguriert wird.

Kann mir bitte jemand weiterhelfen? Das wäre wirklich toll!

Wie kommts, dass der gleiche Build ein Release und einmal Beta ist? Kann doch irgendwie nicht stimmen oder? Oder hast du Beta durch release ersetzt?

Ansonsten: Bei VmWare Workstation sind auch Releases oft auf Beta-Stadium und teilweise fast Alpha. Wer also Beta produktiv einsetzt sollte sich wundern wenn überhaupt was gscheit läuft. Nur meine Meinung dazu. Zeit in sowas zu investieren lohnt aber nicht wirklich.

Nene, ich hab mir VMware Workstation gekauft und installiert. Beta hab ich keine installiert.

2013-08-26T14:20:49.397+02:00| vmx| I120: Log for VMware Workstation pid=2824 version=9.0.2 build=build-1031769 option=Release

Schon mal keine Beta.

2013-08-26T14:20:49.569+02:00| vmx| I120: hostCPUID codename: Sandy Bridge
2013-08-26T14:20:49.569+02:00| vmx| I120: hostCPUID name: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz

Du hast nur eine Quad-CPU...

2013-08-26T14:20:49.725+02:00| vmx| I120: DICT numvcpus = 4

...und vergibst trotzdem 4 CPU-Kerne bzw in deinem Fall 4x CPU-Sockel mit jeweils einer Singlecore-CPU.
Das ist extrem unproduktiv, da das Host-OS auch etwas CPU-Leistung braucht und in jedem Fall das Rennen um die HW gewinnt. Wenn allerdings im Hintergrund noch eine Anwendung läuft, die alle verfügbaren CPU-Kerne in Beschlag nimmt, wird auch das Host-OS ausgebremst und es gibt eine Abwärtsspirale bei der Gesamtsystemperformance. Als weiteres Problem kommt noch hinzu, daß eine VMware-VM nur dann CPU-Ressourcen zugeteilt bekommt, wenn die Anzahl an vCPU/Kernen auch wirklich frei ist und das ist bei einer Quadcore-VM auf einem Quadcore-CPU nur selten der Fall. Ergo konfiguriert man prinzipiell nur Single- bzw maximal Dualcore-VMs, damit das Host-OS noch genügend CPU-Ressourcen über hat.


Hinsichtlich der VMware-Tools hätte ich die Frage, welche Inst-Methode du gewählt hast?
Möglich wären die automatische Inst mit dem Klick auf den Menueintrag "VMware-Tools installieren", bei der dann wirklich auch die Tools-Inst komplett durchläuft oder die manuelle, bei der VMware im Endeffekt nur du die Tools-CD/ISO einlegt und du mounten der CD, auspacken der tar.gz-Datei und Ausführen des VMware-Perl-Scripts selbst ausführen mußt.

Hallo dayworker,

danke für deinen Input, das mit den CPUs werd ich beherzigen - mit einem einizelnen vCPU klappt es ja auch, mit zwei vCPUs wieder nicht.

Die VMware tools werden mit Hilfe eines build-tools installiert, über die Kommandozeile.
Das zuständige Script ist dieses:
https://github.com/thasmo/packer.templa ... /vmware.sh

Die Zeilen betreffend "Apply patch" habe ich von hier:
http://erikbryantology.blogspot.it/2013 ... ra-18.html

Von dort wende ich auch nur den Patch unter Punkt (3) an,
da ohne den Patch die Shared Folder nicht funktionieren.
Punkt (1) und (2) werfen bei der Installation keine Fehler bei mir.

Wenn ich in der VMware Workstation GUI die Option "VMware-Tools installieren..." auswähle, werden die VMware Tools im CD-ROM eingebunden, aber die GUI sagt mir dann ich muss das Ganze manuell mounten, entpacken und ausführen - also genau das was auch das Script macht.

Was ich gerade herausgefunden habe ist, dass das irgendwie mit einem gemounteten Verzeichnis zu tun hat, sprich mit einem Shared Folder.

In meiner VM wird das Verzeichnis /var/www gemountet auf .host:/-var-www (via vmhgfs), welches wiederum der shared folder ist, der somit am Host-Rechner zugänglich ist, indem die Web-Hosts liegen.

Wenn ich jetzt folgendes ausführe, hängt sich die VM auf:
"ab -c 10 -n 10000 http://local/test.txt"

"local" zeigt auf einen Apache Vhost, der unter "/var/www/local" liegt.

Das kuriose daran ist, wenn ich das Verzeichnis "/var/www" umounte, woanders wieder mounte, und das gemountete Verzeichnis auf "/var/www" symlinke, dann funktioniert's.

Sprich diese Konstelation macht keine Probleme:
/var/www -> (symlink) /home/user/www -> (mount) .host:/-var-www

Aber das hier verursacht CPU Probleme:
/var/www -> (mount) .host:/-var-www

Und das Problem taucht nur auf wenn ich mehr als einen vCPU konfiguriere.

Irgendjemand eine Idee was da sein kann? Danke!

Die SharedFolders sind bekannt für ihr instabiles Verhalten. Wann immer möglich würde ich normale Netzwerkfreigaben bevorzugen und in deinem Fall heißt das dann möglicherweise den Samba-Server aufzusetzen...