Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

Unrecoverable error

Hilfe bei Problemen mit der Installation und Benutzung des VMware Player.

Moderatoren: irix, stefan.becker, continuum, Dayworker, Tschoergez

Member
Beiträge: 31
Registriert: 11.06.2013, 08:12

Unrecoverable error

Beitragvon Dave » 18.04.2015, 13:30

Nachdem ich hier bereits kompetente Hilfe bekommen habe, schreibe ich einmal über ein neues Problem.

Bei hoher Auslastung des Gesamtsystems, sei es weil der Host ewig die Festplatte beansprucht oder weil eine zweite VM ein ewig dauerndes Windows Update fährt, mit entsprechender Festplattenaktivität, kommt es in einer VMware Player Instanz zu Abstürzen.

Die Fehlermeldung lautet: Unrecoverable error (.mks) Mouse thread did not respond to grab request

Vielleicht hat jemand eine Idee, was genau dahinter steckt und ob es Möglichkeiten gibt, diese Abstürze zu verhindern.

Experte
Beiträge: 1772
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 18.04.2015, 14:12

Was ist das für eine Festplatte? Eine normale Consumer-S-ATA?

Guru
Beiträge: 2466
Registriert: 27.12.2004, 22:17

Re: Unrecoverable error

Beitragvon rprengel » 18.04.2015, 14:32

Dave hat geschrieben:
Vielleicht hat jemand eine Idee, was genau dahinter steckt und ob es Möglichkeiten gibt, diese Abstürze zu verhindern.


Lies mal mit smart Tools den Zustand der Festplatte aus.
Neben Überlastung könnte auch eine angeknackste Festplatte in Betracht kommen.

Gruss

Benutzeravatar
King of the Hill
Beiträge: 12046
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 18.04.2015, 16:21

Der MKS-Fehler besagt nur, daß die VM nicht rechtzeitig geantwortet hat. Solange du die Verbindung zur VM nicht komplett verlierst, sprich das VM-Fenster schließt sich, würde ich auch nichts weiter machen. Lediglich die Updates würde ich nur noch dann Einspielen, wenn keine VM läuft.


Da die aktuelleren Workstation/Player-Versionen auf möglichst unkompliziertes Starten von Gast-Systemen optimiert wurden, greifen unsere langgedienten Optimierungen zur Verringerung der Datenträgeraktivitäten leider nicht mehr. Daher lautet jetzt umso mehr der dringende Rat, einer VM nur soviel vHW zu geben, wie unbedingt nötig ist. Das bedeutet dann auch, daß eine Singlecore-VM mit nur 512MB für ein 32bittigen und mit 1GB vRAM für einen 64bittigen Gast genau richtig ausgestattet ist. Alles was darüber hinausgeht, wird von VMware bei seinen Desktopprodukten immer als auslagerungsfähig gekennzeichnet und das Host-OS verschiebt diesen direkt in den virtuellen Arbeitsspeicher, sprich je nach Betriebssystem entweder Auslagerungsdatei oder Swap-Laufwerk. Vom vRAM eines Gastes verbleiben dann nur noch ~500MB im pRAM des Hosts, überprüfbar über "top" oder den Taskmanager, und sämtliche vRAM-Aktivitäten bedingen dann eine deutlich verstärkte Aktivität des Host-Datenträgers. Entkoppeln läßt sich das nur, indem man entweder die VMs auf einem weiteren Datenträger des Host, d.h. keine weitere Partition auf dem Systemdatenträger, auslagert oder, falls der Host keine Platzmöglichkeit für einen zweiten Datenträger bietet, zumindest eine SSD nutzt.

Member
Beiträge: 31
Registriert: 11.06.2013, 08:12

Beitragvon Dave » 20.04.2015, 08:33

Zunächst einmal Dank für die vielen schnellen Antworten. Die Vms verliere ich komplette, d.h. die schalten sich ab und müssen neu gestartet werden. Was außerordenglich nervig ist, da man nicht voraussehen kann wann es passiert.

~thc hat geschrieben:Was ist das für eine Festplatte? Eine normale Consumer-S-ATA?

Ja und die ist tatsächlich relativ langsam. Ich hatte die VMs vorher auf einer WD Raptor, da trat dieses Problem nie auf. Demnächst werden sie wieder auf einer Raptor liegen, dann sollte sich das Problem vielleicht wieder erledigen.

Dayworker hat geschrieben:Der MKS-Fehler besagt nur, daß die VM nicht rechtzeitig geantwortet hat. Solange du die Verbindung zur VM nicht komplett verlierst, sprich das VM-Fenster schließt sich, würde ich auch nichts weiter machen. Lediglich die Updates würde ich nur noch dann Einspielen, wenn keine VM läuft.

Da die aktuelleren Workstation/Player-Versionen auf möglichst unkompliziertes Starten von Gast-Systemen optimiert wurden, greifen unsere langgedienten Optimierungen zur Verringerung der Datenträgeraktivitäten leider nicht mehr. Daher lautet jetzt umso mehr der dringende Rat, einer VM nur soviel vHW zu geben, wie unbedingt nötig ist. Das bedeutet dann auch, daß eine Singlecore-VM mit nur 512MB für ein 32bittigen und mit 1GB vRAM für einen 64bittigen Gast genau richtig ausgestattet ist. Alles was darüber hinausgeht, wird von VMware bei seinen Desktopprodukten immer als auslagerungsfähig gekennzeichnet und das Host-OS verschiebt diesen direkt in den virtuellen Arbeitsspeicher, sprich je nach Betriebssystem entweder Auslagerungsdatei oder Swap-Laufwerk. Vom vRAM eines Gastes verbleiben dann nur noch ~500MB im pRAM des Hosts, überprüfbar über "top" oder den Taskmanager, und sämtliche vRAM-Aktivitäten bedingen dann eine deutlich verstärkte Aktivität des Host-Datenträgers. Entkoppeln läßt sich das nur, indem man entweder die VMs auf einem weiteren Datenträger des Host, d.h. keine weitere Partition auf dem Systemdatenträger, auslagert oder, falls der Host keine Platzmöglichkeit für einen zweiten Datenträger bietet, zumindest eine SSD nutzt.


Interessante Info. Die Ram-Anforderungen scheinen mir aber sehr sehr niedrig. Windows 10 lief mit 2GB so schlecht, dass es unbenutzbar war. Erst mit 4GB konnte man etwas damit anfangen und die Startzeiten haben sich erträglich gestaltet. In einem anderen Heavy-Use Gastsystem bekomme ich regelmäßig Meldungen von zuwenig Arbeitsspeicher wenn ich der Vm weniger als 10GB zuteile.

Verhält sich Workstation in dieser Frage günstiger? (Wobei ich überlege, wenn ich wechsle, ob dann nicht Hyper-V, KVM, XenServer oder Sphere) sinnvoller ist, da ich dann eigentlich einige Passthrough-Dinge realisieren will.

Experte
Beiträge: 1772
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 20.04.2015, 08:55

Dave hat geschrieben:Ja und die ist tatsächlich relativ langsam. Ich hatte die VMs vorher auf einer WD Raptor, da trat dieses Problem nie auf. Demnächst werden sie wieder auf einer Raptor liegen, dann sollte sich das Problem vielleicht wieder erledigen.

Wenn du regelmäßig viele VMs betreibst, entbrennt ein heißer Kampf um die mickrige IOPS-Leistung deiner Festplatte. Stark vereinfacht brauchst du bei einem Host und 3 VMs praktisch die vierfache Leistung - und das kann keine S-ATA. Ich kann dir nur eine SSD empfehlen.

Dave hat geschrieben:In einem anderen Heavy-Use Gastsystem bekomme ich regelmäßig Meldungen von zuwenig Arbeitsspeicher wenn ich der Vm weniger als 10GB zuteile.

10 GB RAM mindestens muss man auch erst mal hin bekommen. Sollten deine VMs wegen Speichermangel auf die vDisk auslagern, verschärft sich das Problem noch.

Benutzeravatar
King of the Hill
Beiträge: 12046
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 20.04.2015, 14:05

Zwischen VMware-Workstation und VMware-Player gibt es keinen wirklichen Unterschied. Im Lieferumfang der Workstation befindet sich immer auch der Player. Der Player als Einzelanwendung ist keine eigenständige Entwicklung sondern eine abgespeckte Workstation.
Von daher kann die Antwort auf deine Frage, ob sich die Workstation in dieser Frage günstiger verhält, nur verneint werden. Das betrifft in diesem Zusammenhang alle VMware-Desktopprodukte sprich Player, Workstation (beides Linux und Windows) und Fusion (MacOSX).


In der vollvirtualisierten VMware-Welt gilt die Devise: "Nur soviel (vRAM, vDISK, vCPU) wie nötig und nicht wie möglich" und da macht auch VMware-vSphere keinen Unterschied.


Win10 enthält momentan noch viel Debug-Code, der den Speicherverbrauch erhöht. Da der Kernel bei Win10 aber bereits jetzt kleiner als der von Win8.1 ist, reichen 2GB locker aus und auch die üblichen Büroarbeiten sprich Office & Co lassen sich damit problemlos betreiben.


Was sind denn bei dir Heavy-Use-VMs?
Der VMware-Marketingspeech für seine Desktopprodukte (64GB vRAM, 16 vCPU etc) ist nur als solches Marketinggeschrei zu verstehen, damit VMware gegenüber seinen Wettbewerbern beim Funktionsumfang nicht an Boden verliert. Sinnvoll arbeiten läßt sich damit aber nicht. VMs mit viel vRAM werden genauso langsamer, wie viele vCPUs eine VM in der Ausführung behindern. Da VMware Desktopprodukte ab einer gewissen vRAM-Grösse durch die Bank weg den Großteil als auslagerungsfähig kennzeichnen, macht viel vRAM diese VM logischerweise nur noch langsamer. Zumal viel RAM jeden Rechner erstmal langsamer macht, da der Verwaltungsaufwand für diesen RAM ansteigt. Falls also eine Anwendung keinen Nutzen aus viel RAM ziehen kann, war die Investition darin umsonst. VMare kann prinzipiell von viel RAM profitieren, allerdings hatten VMwares Desktopprodukte einige Probleme mit einigen Host-OS-Versionen, die letztendlich zu Gast-Instabilitäten führten, sobald in Summe mehr als 30% des Host-RAMs an Gäste ausgeliehen wurde. Aus diesem Grund und aus Gründen der Binärkompatibilität hatte sich VMware für die rigorose Auslagerung bei sämtlichen Desktopprodukten entschieden.
Betrachten wir mal die CPU-Kerne. Eine VMware-VM bekommt prinzipiell nur dann Ausführungszeit zugewiesen, wenn die konfigurierte Anzahl an vCPUs also Kerne der Host-CPU auch wirklich frei ist. Damit sind bei VMware in einem Gast auch nie mehr Kerne abbildbar, als der Host selber verfügt. Steht diese Anzahl also nicht zur Verfügung, wird die VM auch nicht ausgeführt (oder startet überhaupt nicht erst). Die VM hakelt dann und sowas wird meist am Springen des Mauscursors sichtbar. Eine Singlecore-VM bekommt unweigerlich immer deutlich mehr Ausführungszeit zugewiesen als jede Dual- oder Quadcore-VM. Hyperthreading mit seinen logischen Kernen ist hierbei auch keine vollständige Lösung, da die Arbeit letztendlich doch wieder von den physikalischen Kernen erledigt werden muß. Es kann allerdings die Situation etwas entschärfen, wobei HT in Abhängigkeit zur auszuführenden Arbeit innerhalb der VM auch nicht mehr als ~30% einbringt. Aber bei Virtualisierung gehts auch nicht um die höchste CPU-Leistung sondern um die Konsolidierung bestehender, häufig im Leerlauf befindlicher Rechnerfarmen bei höherer Auslastung der verbleibenden HW-Rechner/Server oder um den von der Host-HW losgelösten Betrieb von Gast-Betreibssystemen. Wenn es dir also um maximale CPU-Performance geht, bist du bei Virtualisierung komplett falsch aufgestellt.


PCI/PCIe-Passthrough geht bei VMware nur mit vSphere. Die Desktopprodukte können nur Geräte durchreichen, die per USB-, Serial- oder Parallelport angeschlossen sind.

Member
Beiträge: 31
Registriert: 11.06.2013, 08:12

Beitragvon Dave » 21.04.2015, 08:32

Nein, mir geht es nicht um maximale Performence im Vergleich zu bare metal. Mir geht es aber um eine maximal performante virtuelle Maschine. Grundsätzlich ist die Performance, die ich mit Player erlebe völlig ausreichend.
Ich glaube dir jedes Wort, das du geschrieben hast, ich kann es nur in meinen Fällen nicht nachvollziehen. Lange Zeit machte ich mit einem Windows 8 Gast rum, dessen Performance mich nicht überzeugte. Erst bei 2 vCores lief es gut.

Windows 10 hatte ich ja schon geschrieben, das lief in den ersten Versionen der Technical Preview mit 2Gb hervorragend. Dann irgendwann nicht mehr und inzwischen nur mit 4 GB annehmbar schnell.

Ich will gar nicht ausschließen, dass ich einen HDD-Flaschenhals habe, den ich beseitigen kann. Mich hat es nur irritiert, dass offensichtliche in Timeout des Maus dazu führt, dass die gesamte virtuelle Maschine abstürzt. Das hätte ich jetzt nicht erwartet und sehe programmiertechnisch dafür keinen offensichtlichen Grund. Etwas zu warten, wenn Windows meint etwas dringendes erledigen zu müssen, kennen wir doch wahrscheinlich alle. Der Player scheint von ungeduldigen Programmierern hergestellt zu werden.
:grin: :D

Der Virtualisierung bleibe ich mit Sicherheit treu, ich seh da für mich nur Vorteile. Workstation werde ich dann aber wohl überspringen und mich eher in Richtung Servervirtualisierung orientieren.

Benutzeravatar
King of the Hill
Beiträge: 12046
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 21.04.2015, 17:59

Kannst du dich noch an die ersten SSDs und deren extrem lange Schreiblatenz im hohen Sekunden- statt heutigen niedrigen Millisekundenbereich erinnern?
Damit kamen die meisten OS auch nicht zurecht. Wenn beispielsweise Windows auf den Datenträger schreiben mußte und dieser aus welchen Gründen auch immer nicht ansprechbar war, hat sich das OS gern mit einem BSOD verabschiedet und genauso verhält es sich in einer VM. Und JA, VMwares Desktopprodukte waren schon mal deutlich schneller sowohl beim VM-Start als auch erst recht beim VM-Suspend.


Viel ist von den alten Tuningmöglichkeiten nicht mehr übriggeblieben, aber folgender Eintrag in die VMX-Datei sollte immer noch funktionieren:
Windows-Host:
mainMem.useNamedFile = "FALSE"

Linux-Host:
mainmem.backing = "swap"
Damit verhinderst du, daß die VM beim Start eine vmem-Datei in der Grösse des konfigurierten vRAMs anlegt. Bei einer VM mit 4 und erst recht 10GB vRAM dauert das auch bei aktuellen SSDs eine Weile und solange scheint die VM beim Start zu hängen, was sie aber erkennbar an der dauerleuchtenden HDD-Lampe nicht tut.


Zurück zu „VMware Player“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste