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
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Virtual machine disk consolidation needed
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
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
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
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
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
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
So was findet sich im vmkernel.log
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-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
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
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
Logge dich auf die Kommandozeile ein und gucks in das Verzeichnis.
Gruss
Joerg
Zurück zu „vSphere 5.5 / ESXi 5.5“
Wer ist online?
Mitglieder in diesem Forum: Google [Bot] und 7 Gäste