VMware-Forum

Verfasst: **14.03.2015, 13:26**

Hi,

irgendwie ist eine VM auf einem ESX 5.5 U1 snaptechnisch verstrubbelt und möchte konsolidiert werden.
Dummerweise endet das immer wieder mit einer Fehlermeldung (timeout).

Seltsam finde ich folgendes:
Die Windows VM hat drei vdisks. einmal 40GB für OS dann 730GB für eine DB und 100GB für exports aus der DB. Wie kann es eigentlich passieren, dass die Platten unterschiedlich viele snaps haben?
Die OS Platte hat keine Snapshot Datei, die DB Platte 3 snaps und die export platte wieder nur 2 snapshots.
Ist das das Resultat der abgebrochenen Konsolidierungsversuche?

Gruß
Klaus

Verfasst: **14.03.2015, 13:36**

Die Platten haben unterschieddliche Anzahlen an Snap je nach Zeitpunkt wann das Problem oder der Abbruch des Comits aufgetreten ist.

Pruefe erstmal ob die vDisk an irgendeiner anderen VM angehaengt ist. Also sprich hast du ein Backupprodukt was den Hot-Add Mode verwendet. Erst dann darf man Consolideren.

Auch ein vMotion einer VM wenn sie so einen undefinierten Zustand hat ist unguecklich da ein anderer Hosts evtl. Locks haelt. Dann hilft ein vMotion wieder auf den Ausgangs Host und ein erneuter Versuch.

Poste die relevanten Abschnitte aus dem vmware.log und vmkernel.log wenn du den Prozess startest und bis Auftreten des Fehlers.

Gruss
Joerg

Verfasst: **14.03.2015, 15:00**

Hi,

danke für die Unterstützung

Im Moment läuft noch mal so eine Konsolidierung - aber schon seit 12:54.
Ich habe eine KB gefunden, nach der man in den Einstellungen der VM

snapshot.asyncConsolidate.forceSync = TRUE

hinzufügen sollte.
Das habe ich vor dem letzten Konsolidierungsstart eingetragen.
Im vCenter wird nur "In Progress" ohne Fortschrittsbalken angezeigt.
Aber immerhin hat die große db vdisk immerhin schon mal einen geänderten Timestamp (14:29) - das war vorher nicht so.
Das vmware.log ist rel. unspektakulär. Heute Morgen begann das Desaster ja mit einem vollen Datastore. Daher steht da drin auch nur die entsprechende Warung.

Ein Kollege hat dass die LUN auf der XIV vergrößert und ich den Datastore.
An die vmkernel.log komme ich nicht so einfach dran. Remote über remote auf remote

Aber mal sehen was ich hin bekomme ...

Gruß
Klaus

Verfasst: **14.03.2015, 15:12**

So was findet sich im vmkernel.log

2015-03-14T13:20:41.647Z cpu11:35362)<4>hpsa 0000:05:00.0: cp 0x410b4ecab000 has status 0x2 Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2
2015-03-14T13:20:41.647Z cpu6:33036)NMP: nmp_ThrottleLogForDevice:2321: Cmd 0x85 (0x412e43cbba00, 34390) to dev "naa.600508b1001c4cbbe7bd39a166e6f917" on path "vmhba0:C0:T0:L1" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0. Act:NONE
2015-03-14T13:20:41.647Z cpu6:33036)ScsiDeviceIO: 2337: Cmd(0x412e43cbba00) 0x85, CmdSN 0x9 from world 34390 to dev "naa.600508b1001c4cbbe7bd39a166e6f917" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.
2015-03-14T13:20:41.657Z cpu11:35362)<4>hpsa 0000:05:00.0: cp 0x410b4ecab000 has status 0x2 Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2
2015-03-14T13:20:41.657Z cpu6:33036)ScsiDeviceIO: 2337: Cmd(0x412e43cbba00) 0x4d, CmdSN 0xa from world 34390 to dev "naa.600508b1001c4cbbe7bd39a166e6f917" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.
2015-03-14T13:20:41.658Z cpu11:35362)<4>hpsa 0000:05:00.0: cp 0x410b4ecab000 has status 0x2 Sense: 0x5, ASC: 0x24, ASCQ: 0x0, Returning result: 0x2
2015-03-14T13:20:41.658Z cpu6:33036)ScsiDeviceIO: 2337: Cmd(0x412e43cbba00) 0x1a, CmdSN 0xb from world 34390 to dev "naa.600508b1001c4cbbe7bd39a166e6f917" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

Das ist aber nicht der SAN Datastore, sondern nur die lokale "Bootplatte" mit ein Bisschen Datastore für Templates etc.

die letzten Einträge so wie eigentlich fast alles sehen so aus:

2015-03-14T14:00:00.023Z cpu16:36166)World: 14296: VC opID hostd-220d maps to vmkernel opID 4b2e49e1
2015-03-14T14:00:01.704Z cpu20:34064)World: 14296: VC opID hostd-6940 maps to vmkernel opID 583aabd9
2015-03-14T14:00:20.023Z cpu10:34016)World: 14296: VC opID hostd-0932 maps to vmkernel opID 439962bc
2015-03-14T14:00:40.023Z cpu18:34014)World: 14296: VC opID SWI-565aad61 maps to vmkernel opID 770f95f0
2015-03-14T14:00:42.941Z cpu10:34065)World: 14296: VC opID hostd-a514 maps to vmkernel opID c663b6cb
2015-03-14T14:00:53.111Z cpu16:36166)World: 14296: VC opID FF0A30AE-0000F952-5c-6a maps to vmkernel opID 978754a0
2015-03-14T14:01:00.024Z cpu0:35595)World: 14296: VC opID FF0A30AE-0000F952-5c-6a maps to vmkernel opID 978754a0
2015-03-14T14:01:06.756Z cpu4:34016)World: 14296: VC opID hostd-52ce maps to vmkernel opID 1eeb53b7
2015-03-14T14:01:20.024Z cpu10:34065)World: 14296: VC opID hostd-093d maps to vmkernel opID 3010e293
2015-03-14T14:01:23.101Z cpu20:36166)World: 14296: VC opID hostd-5336 maps to vmkernel opID 60fa2a3a
2015-03-14T14:01:27.050Z cpu6:34017)World: 14296: VC opID hostd-2c88 maps to vmkernel opID b3e82b10
2015-03-14T14:01:40.023Z cpu8:35595)World: 14296: VC opID SWI-958c8bec maps to vmkernel opID c561b3f5
2015-03-14T14:01:48.315Z cpu8:34065)World: 14296: VC opID hostd-1341 maps to vmkernel opID de4b707b
2015-03-14T14:02:00.024Z cpu6:34065)World: 14296: VC opID hostd-f40e maps to vmkernel opID 9de5b782
2015-03-14T14:02:20.023Z cpu8:34017)World: 14296: VC opID hostd-4bc4 maps to vmkernel opID 2c65d096

Verfasst: **14.03.2015, 15:58**

... jetzt ist gerade der Fortschrittsbalken aufgetaucht 1%

Das kann ja dauern ...

Verfasst: **14.03.2015, 17:48**

Der Fortschritsbalken ist zu ignorieren. In aeltern Versionen ist der Prozess in einen Timeout gelaufen und hat aber im Hintergrund auf dem Host bis zum Ende gearbeitet. In neueren Versionen ist mir der Timeout nicht mehr begegnet.

Logge dich auf die Kommandozeile ein und gucks in das Verzeichnis.

Gruss
Joerg

Verfasst: **15.03.2015, 13:35**

Hey, heute um 11:30 war die Konsolidierung dann abgeschlossen.
Man darf es eben nur nicht eilig haben ...

Danke für den Beistand !!!

VMware-Forum

Virtual machine disk consolidation needed

Virtual machine disk consolidation needed