Gastsystem (Win XP) bleibt einfach stehen)

[WLemmy]

Hallo,

VM WS 9 auf Linux, Gastsystem ist XP SP3.

nicht immer, aber leider viel zu oft (2-3x im Monat), bleibt das System bzw. das ausgeführte Programm beim Zugriff auf ein Laufwerk bzw. auf ein Verzeichnis (Doppelklick im OpenDialog auf das Verzeichnis) einfach stehen. Das Verzeichnis liegt dabei lokal, Verbundene Netzlaufwerke hatte ich alle auch schon mal getrennt, kein Unterschied.

Ich kann zwar noch mit ALT+Tab durch die offenen Programme blättern, aber ich kann nicht mehr umschalten. STRG+ALT+ENTF oder STRG+ALT+EINFG zeigen keine Wirkung, auch nicht wenn ich über den entsprechende Menüfunktion gehe.

Hier hilft nur noch die VM abzuschalten (PowerOff) und neu zu starten.

Hat jemand ne Idee was das sein könnte?

Grüße

[Dayworker]

Die WS9 hat schon genug Fehler. Gabs da einen verdammt guten Grund diese Baustelle auch noch auf Linux als Host-OS zu verlagern?
Nutzt du SharedFolders oder sind das normale Netzwerkfreigaben?
Sind die vDISKs preallocated oder mitwachsend/Sparse? Werden die Sparse-Disks regelmäßig geshrinkt?

Ein vollständig, verlinktes "vmware.log" auf einen Freehoster ohne Zwangsanmeldung oder Flash-Müll würde uns schon mal wesentlich weiterhelfen.

[WLemmy]

warum? ganz einfach weil ich die 8er auf dem 3.2er Kernel nie zum laufen gebracht habe, ebenso die 7.xer, die bei mir gut 2 Jahre ohne Murren (auf 2.6) ihren Dienst verrichtet hat!

Ich nutze keine Shared Folders (die sind auch in den Einstellungen abgeschaltet). Die aktuell noch eine verbundene Netzwerkfreigabe ist ein Samba-Share (hatte ich aber auch mal abgeschaltet), die andere Freigabe war eine Remote-Freigabe über ne VPN-Verbindung, die ist aber schon lange deaktiviert.

Die vDisks sind mitwachsend und werden von Zeit zu Zeit geshrinkt (1-2x pro Jahr, soll das öfters passieren?)

VMWare.log - reicht da ein "normales" oder nur eins von einem solchen Hänger? Da habe ich aktuell nichts zur Hand

Grüße

[Dayworker]

Du bekommst mit dem zur Kernel-Version passenden Patch eigentlich jeden Linux-Kernel zur Zusammenarbeit mit propitärer SW überredet und genau da liegt das Problem. Der Patch muß immer zur Kernel-Version passen.

Dadurch das jedes Kernelupdate aufgrund der vielen Veränderungen an grundlegenden Systemschnittstellen ein neues OS darstellt, mußt du zumindest die Rekompilation der VMware-Kernel-Module nach jedem Update durchführen. Mit dem Kernel "3.5.0-17-generic" von *buntu12.10 aka "Quantal Quetzal" düfte die WS9 schon nicht mehr zurecht kommen und VMware veröffentlicht bekanntermaßen nicht jeden Monat eine neue Version, nur um der Kernelversionitis Herr zu werden.
Das die WS9 mit dem 3.2er Kernel zusammenspielt, bedeutet daher überhaupt nichts. Es ist nur eine Frage von Wochen, wann eine Kernel-Änderung wieder diesen Frieden stört und ein Patch für VMware benötigt wird.

Wenn die Sparse-Disk eine hohe Schreibrate haben, sollten diese bedeutend häufiger geshrinkt werden. Ein wöchentlicher Rhythmus ist dann nicht verkehrt.

Es würde schon Sinn machen, ein Log mit dem beschriebenen Hänger präsentiert zu bekommen.
Was passiert denn zur selben Zeit auf dem Host, werden dort irgendwelche Messages im Kernel-Log gelistet?
Verlinke mal bitte trotzdem eines der 4 möglichen "vmware.log", wobei du schon einige Schreib-IOs produziert haben solltest.
Nutzt du eigentlich auch Snapshots und löst du die, wie von VMware vorgesehen, auch regelmäßig wieder auf?

[WLemmy]

Guten Morgen,

hier das log von gestern:
http://www.load.to/R8XlxmXMkU/vmware.log.zip

da das Gastsystem ohne Einschränkung nutzbar war habe ich nie in die Logs geschaut, werde ich das nächste mal machen.

Snapshots setze ich in dieser VM nicht ein.

Sollte sich die Maschine wieder erhängen poste ich das entsprechende Log.

Grüße

[WLemmy]

Hi,

so, eben wieder hängen geblieben...

Hier aus dem Kernel log:

Code: Alles auswählen

24.10.2012 16:12:15   wlehome   kernel   [35402.410637] device eth0 left promiscuous mode
24.10.2012 16:12:15   wlehome   kernel   [35402.410773] bridge-eth0: disabled promiscuous mode
24.10.2012 16:12:15   wlehome   kernel   [35402.428717] NET: Unregistered protocol family 39


Hier das VMWarelog:
http://www.load.to/OwXZjTSlTc/vmware.log.zip

Grüße

[Dayworker]

Keine Ahnung was mit load.to los ist, ich bekomm ein Log leider wieder mal nicht geladen. Ich habs probiert mit Maxthon, IE und FF...

Ausgehend vom Kernel-Log, hat die eth0-Nic entweder einen Knacks weg oder wurde in einen Energiesparzustand geschickt. Da die anderen "VMnetX" meines Wissens nach immer an der ersten Nic festgemacht werden, werden diesen somit auch die Grundlage entzogen.
Was ist die eth0-Nic eigentlich für eine? Hoffentlich kein WLan-Adapter...

[WLemmy]

dann versuchs mal mit dem hier:

http://www.lemmermeyer.info/vmware.log.zip

das ist das log vom Hänger.


Nein eth0 ist kein WLAN - schönes CAT5.

Grüße

[Dayworker]

Zum Zeitpunkt deines Kernel-Logs sehe ich nur folgendes:

2012-10-24T16:10:41.021+01:00| svga| I120: SVGA: Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip
2012-10-24T16:12:15.507+01:00| vmx| I120: VMXVmdbCbVmVmxExecState: Exec state change requested to state poweredOff without reset, hard, softOptionTimeout: 0.
2012-10-24T16:12:15.507+01:00| vmx| I120: Stopping VCPU threads...
2012-10-24T16:12:15.508+01:00| svga| I120: Async SVGA thread is exiting
2012-10-24T16:12:15.802+01:00| mks| I120: X11-Backend: stopped by HWinMux to do window composition.
2012-10-24T16:12:15.802+01:00| mks| I120: MKS thread is exiting
2012-10-24T16:12:15.816+01:00| vmx| I120: USB: Disconnecting device 0x400000040e0f0003
2012-10-24T16:12:15.816+01:00| vmx| I120: Vix: [3603 mainDispatch.c:1096]: VMAutomation_PowerOff: Powering off.

Hattest du die VM abgeschaltet oder ist die selbst runtergefahren?
Was gibt das Kernel-Log um diesen Zeitpunkt herum sonst noch preis?

Nein eth0 ist kein WLAN - schönes CAT5.

Was ist das für eine Nic?
Hast du deren Energiezustand mal gecheckt?

[WLemmy]

Hi,

die VM habe ich dann abgeschaltet - ich habe da auch mal ne gute halbe Stunde gewartet ob sich da noch was tut...

Kernel-log gibts sonst nix: um 15:51 Uhr, dass ich keine CD eingelegt hatte und dann um 16:17 Uhr der stündliche Cron-Job. Also nix was mit dem Zeugs zu tun hat.

NIC. Ist ne OnBoard, muss mal eben das Board suchen...

dann erst Energieeinstellungen: Gibts keine da es sich bei der Kiste um nen Tower handelt (also kein Notebook und damit auch keine Energiespareinstellungen).

so und hier das Board:
http://www.msi-computer.de/product/mb/K ... v=Overview
ist ein NVidia Chip (MCP55 Ethernet)

Grüße

[Dayworker]

NIC. Ist ne OnBoard, muss mal eben das Board suchen...

dann erst Energieeinstellungen: Gibts keine da es sich bei der Kiste um nen Tower handelt (also kein Notebook und damit auch keine Energiespareinstellungen).

Das stimmt so nicht ganz. Du kannst eigentlich in jedem OS einstellen, daß fast jedes Gerät deaktiviert werden kann, um Energie zu sparen. In Windows-Gerätemanager heißt es da ganz lapidar: "Computer kann Gerät ausschalten, um Energie zu sparen".

so und hier das Board:
http://www.msi-computer.de/product/mb/K ... v=Overview
ist ein NVidia Chip (MCP55 Ethernet)

Alles klar, wieder mal ein nVidia-Chipsatz.
Die sind nicht gerade für Zuverlässigkeit bekannt und einige brachten dazu auch noch eine normalerweise extrem nützliche HW-Firewall im Nic-Chip mit. Leider gab es damit nur Probleme.
Ich würde dir daher jede andere Nic empfehlen und die im Chipsatz deaktivieren.