VMware-Forum

Hallo,

ich habe hier einen ESX Server 3.0.1 32039.

Eine VM reagierte heute Morgen nicht mehr und es kam die Meldung:
error connection: vmx connection handshake failed for mks ...

daraufhin habe ich folgende Befehle ausgeführt:
service mgmt-vmware restart
service vmware-vmkauthd restart

mit dem Ergebnis dass die VM beim Starten bei 95% stehen bleibt.

Ich habe danach versucht die VM auf einen anderen Server per Veem Backup zu kopieren, aber leider schlug auch das fehl.
(Failed to copy file *-flat.vmdk)

Hat jemand eine Idee?

ja: die VM läuft noch....

schau mal mit esxtop und vm-support -x bzw. -X welche VMs auf dem Server noch laufen.
Mit vm-support kannst Du die dann auch hart abschießen (der last-resort vor nem Reboot des ESX).

Viele Grüße,
Jörg

Man, DANKE!!!!

Die VM lief noch und mit vm-support -X <WID> konnte ich Sie beenden.

Mir ist nur aufgefallen, dass jetzt meine Platte etwas voll ist, obwohl ich laut VIC noch gut 10% frei haben müsste




Danke

Das ist die Root-Partition, die da so voll ist... gibts noch weitere Partitionen?
ansonsten solltest Du mal in /var/log schauen, ob irgendwelche Logfiles besonders große geworden sind...

Irgendwelche 3rd-party-agenten installiert?
viele grüße,
jörg

Habe gerade auf diese Weise eine VM abgeschossen... anschließend ließ sie sich nicht wieder starten: "Unable to access file <unspecified filename> since it is locked".

vmkernel-Log sagt:

Jan 12 10:01:55 esx5 vmkernel: 48:19:13:49.976 cpu8:15554)WARNING: Swap: vm 15555: 2457: Failed to open swap file '....vswp': Busy
Jan 12 10:01:55 esx5 vmkernel: 48:19:13:49.976 cpu8:15554)WARNING: Swap:vm 15555: 4356: Failed to initialize swap file '....vswp': Busy

VMware Support eingeschaltet - die sind von meiner Vorgehensweise nicht gerade begeistert und empfehlen einen Reboot des Hosts...

Georg.

Der Swap-File wird wahrscheinlich noch gelockt sein.

kannst Du die vswp-Datei per hand löschen (solange die VM aus ist)?
ansonsten ein vmkfstools -D (undokumentierter Parameter), der loggt infos über die Locks ins VMkernel log...
näheres hier:
http://vi3.org/download/guides/english/ ... gFiles.pdf

viele grüße,
jörg

Beim nächsten Mal... bin der Anweisung des Supports schon gefolgt.

Mich interessiert auch, was dazu geführt haben könnte, dass die VM nicht mehr ansprechbar war (gleiche Symptomatik wie beim OP).

Georg.

Georg,
was für eine VM hattest du denn am Laufen?
Windows reagiert je nach Version bei voller Platte auf keinerlei Anfragen mehr und endet dann kurze Zeit später im BSOD oder hängt sich komplett auf. Für Linux fehlen mir die Dauererfahrungen, allerdings wird auch Linux eine volle Platte nicht so cool finden.

Die Maschine war ein XP SP3 aus einem automatisierten Desktop-Pool. Keine Plattenprobleme. Keine Antwort auf ping, keine Reaktion auf Aktionen aus dem VI-Client, sondern die Meldung "Unable to connect to the MKS: VMX connection handshake failed for mks of /vmfs/volumes/..."

Ach ja: Wir sind hier zwar im ESX 3-Forum - ich habe vSphere 4 mit View 4 im Einsatz.

Georg.

"Unable to connect to the MKS: VMX connection handshake failed for mks of /vmfs/volumes/..."

Naja. Jeder Verbindungsversuch auf eine VM wird auch mitgeloggt und erfordert somit auch einen Schreibzugriff. Wenn dann die Disk fast voll ist, verhindert möglicherweise das OS jeden weiteren Zugriffsversuch.

was hat denn der support gesagt?
oder anders gefragt: woran lags denn?

war die VM ein linked clone?

viele grüße,
jörg

Bislang hat VMware Support nur beklagt, wie ich vorgegangen bin. Ursachenforschung wurde noch nicht betrieben.

Ja, die VM war ein Linked Clone, an der wir PCoIP ausgetestet haben. Den Aussagen meines Kollegen zufolge benahm sich die VM sehr merkwürdig: Beim Umschalten von Youtube-Flash-Videos in HD-Modus crashte teilweile der Browser, teils änderte sich die Auflösung, und die Maschine zeigte sich nur noch in VGA. Die Maschine selbst crashte mehrfach, zuletzt etwa einen Tag vor dem Stillstand. Genaueres weiß ich noch nicht, weil ich mich bislang noch nicht wirklich darum kümmern konnte...

Nein, es gab, soweit ich erkennen kann, keine Plattenprobleme - weder in der VM noch auf dem VMFS.

Das Log der Maschine ist extrem groß: 2 MB. Ich kann die Einträge nicht wirklich interpretieren, zu VMware habe ich sie noch nicht geschickt. Die letzten Einträge im Log:

Jan 08 10:29:54.876: vcpu-0| Guest: vmx_fb: Driver compiled against: 2.0.
Jan 08 10:29:54.877: vcpu-0| Guest: vmx_fb: DrvGetDirectDrawInfo: Overlay flags set
Jan 08 10:29:54.984: mks| HostOps hideCursor before defineCursor!
Jan 08 10:29:55.007: mks| SVGA: enabling escape command
Jan 08 10:29:55.007: mks| HostOps hideCursor before defineCursor!
Jan 08 10:29:55.007: vcpu-0| Guest display topology changed: numDisplays 1
Jan 08 10:29:55.035: mks| HostOps showCursor before defineCursor!
Jan 08 10:29:55.189: mks| HostOps showCursor before defineCursor!
Jan 08 10:29:56.046: mks| Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip
Jan 08 10:29:58.406: mks| HostOps showCursor before defineCursor!

Sehr häufig kommen folgende Einträge

Dec 18 14:32:22.176: mks| Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip

und dies hier in Abständen von Millisekunden im zeitlichen Zusammenhang mit BSOD:

Jan 05 09:33:59.069: vcpu-0| GuestRpc: Channel 4, conflict: guest application vdiagent tried to register, but it is still registered on channel 1
Jan 05 09:33:59.070: vcpu-0| GuestRpc: Channel 4 reinitialized.
Jan 05 09:33:59.070: vcpu-0| GuestRpc: Channel 4 reinitialized.

Georg.