Seite 1 von 1
vSphere 5.1 The source detected that the destination failed
Verfasst: 07.05.2013, 08:05
von MatthiasO
Moin zusammen.
Folgendes Problem ist, dass sich einige VMs nicht per Storage vMotion von einem Datastore in den anderen verschieben lassen.
Ich habe das mal mit einer betroffenen W2k8R2 VM (Domaincontroller) ausgetestet. Wenn die VM ausgeschaltet ist,
dann funktioniert SvMotion, wenn sie eingeschaltet ist und ich den Task starte geht er recht schnell auf 32% hoch und bricht nach 20 Minuten mit dieser Meldung ab:
„Ein allgemeiner Systemfehler ist aufgetreten: The source detected that the destination failed to resume.”
Auf dem ESXi Host ist im hostd.log nichts Aussagekräftiges zu finden.
Im vmware.log der VM steht diese Meldung:
SVMotionMirroredModeThreadDiskCopy: Found internal error when woken up on diskCopySemaphore. Aborting storage vmotion.
Ich hatte die VM schon auf einen anderen Host migriert, brachte aber auch nichts.
Es ist vSphere 5.1 im Einsatz und die VM (HW Version 9) hat kein RDM und steht auch nicht unter Last.
Alle Datastores kommen von einer NetApp via FC.
Weiß jemand Rat?
Viele Grüße, Matthias
Links wie diese hier brachten auch keinen Erfolg:
http://www.vmdamentals.com/?p=633
http://kb.vmware.com/selfservice/micros ... Id=1010045
Verfasst: 07.05.2013, 09:08
von MarcelMertens
Dein erster Link zeigt ein Problem mit vMotion. Du machst aber svMotion.
Schau mal im vmkernel log nach ob dort noch was steht.
Verfasst: 07.05.2013, 10:49
von MatthiasO
Es stehen jede Menge dieser Meldung im vmkernel.log:
NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x83 (0x41244117d640, 1038858) to dev
"naa.60a9800050336e376b6f6848454f3441" on path "vmhba3:C0:T0:L5" Failed: H:0x2
D:0x2 P:0x0 Possible sense data: 0xa 0xd 0x2. Act:EVAL
Das ist auch exakt die LUN wohin ich migrieren will. Es gibt einen KB Artikel in dem
ThrottleLogForDevice beschrieben ist:
http://kb.vmware.com/selfservice/micros ... Id=2007427
Allerdings ist das EnableBlockDelete standardmäßig bei 5.1 deaktiviert, so wie auch
in meinem Fall.
Verfasst: 08.05.2013, 17:42
von Dayworker
Verlinke mal bitte das vollständige "vmkernel.log" soweit vorhanden. Mit dem Ausschnitt kann niemand so richtig etwas anfangen, da die wahrscheinlich entscheidenderen Einträge früher oder später gemacht wurden.
Verfasst: 08.05.2013, 18:07
von MatthiasO
Würde ich ja gern, aber ich bekomme diese Meldung nachdem ich das Attachment ausgewählt hatte:
Attachment kann nicht hinzugefügt werden, da die maximale Anzahl von 0 Attachments in dieser Nachricht erreicht wurde

Verfasst: 08.05.2013, 18:36
von Dayworker
Meine Signatur zur Thematik Dateianhänge scheint wohl immer noch zu klein zu sein.

Verfasst: 08.05.2013, 18:38
von Dayworker
Das Log ist ja wieder gekürzt, da die Foren-SW nach ca 60k-Zeichen das Posting abschneidet. Verlinke das Log einfach auf einen Freehoster oder eignen Webspace.

Verfasst: 08.05.2013, 18:39
von MatthiasO
Ich habe keinen eigenen Webspace..
Und ich habe Deine Signatur schon richtig verstanden.
Verfasst: 08.05.2013, 18:43
von Dayworker
Dropbox.com, Load.to und FileCloud.io sind schon mal drei Möglichkeiten.
Wir wissen auch, daß die Dateianhänge-Situation unschön ist. Aber damit leben wir schon seit längerem und der Foreninhaber umgeht damit auch irgendwelchen Abmahnärger oder noch schlimmeren.
Die ganze Story zu Dateianhängen kann man übrigens im Thread
... hier kann man files hochladen nachlesen...
Verfasst: 08.05.2013, 19:01
von MatthiasO
Ja, danke. Das konnte ich nicht wissen.
Ich bin erst seit ein paar Tagen hier angemeldet und habe mich mit diesen
Feinheiten noch nicht auseinander gesetzt. Ebenso wenig damit, wie ich irgendwo
im WWW irgendwelche Dateien hochladen kann/muss, damit diese in einem Forum wie
diesem zu sehen sind. Ich kenne das anders...
Sei´s drum, hier der Link:
https://www.dropbox.com/s/so0bc8t84xcrpmj/vmkernel.log
..
Verfasst: 26.11.2013, 11:21
von tbmunich
Hallo zusammen, ich habe ebenfalls genau dieses Problem...auch mit NetApp und FC.
Habt ihr das irgendwie gelöst.
Für einen Hinweis wär ich dankbar in welche Richtung ich suchen muss...
Verfasst: 26.11.2013, 11:27
von continuum
Das Problem konnte damals schon nicht abschliessend durchgekaut werden - wegen Mangel an Beweisen ...
Gib uns Details zu deinem konkreten Problem
Verfasst: 26.11.2013, 11:46
von tbmunich
Storage vMotion hängt bei 32% und bricht dann ab. (Timeout).
(an vc5.1u1 mit esxi 5.1u1 Hosts)
in diesem Fall haben wir VMs mit normalen .vmdk über FC LUN an ESX und NetApp Storage.
Ausserdem funktioniert vMotion nicht für Windows VMs (Server 2008R2) die Snapdrive installiert haben und die Disks über RawDevice angebunden haben.
Test VMs die im Windows zwar Raw Device gemappt haben aber kein SnapDrive installiert haben funktionieren in der gleichen Umgebung.
Evtl sperrt SnapDrive da etwas ? Hat jemand eine Idee oder ähnliches gesehen?
(auch offline Migrationen dieser SnapDrive VMs scheitern).
Danke jedenfalls im Voraus für jeden kleinen Hinweis, ansonsten werde ich über die Hersteller Hotlines weitermachen.
Verfasst: 06.12.2013, 12:59
von tbmunich
Disable VAAI im ESX hat das Problem gelöst (bzw. umgangen).
http://kb.vmware.com/kb/1033665
Under Software, click Advanced Settings.
.Click DataMover.
Change the DataMover.HardwareAcceleratedMove setting to 0.
Change the DataMover.HardwareAcceleratedInit setting to 0.
Click VMFS3.
Change the VMFS3.HardwareAcceleratedLocking setting to 0.
Click OK to save your changes.