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!
vSphere 5.1 The source detected that the destination failed
vSphere 5.1 The source detected that the destination failed
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
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
-
- Member
- Beiträge: 360
- Registriert: 13.07.2011, 15:33
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.
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.
-
- King of the Hill
- Beiträge: 13651
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
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...
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...
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
..
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
..
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.
(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.
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.
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.
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste