Were these devices presented to VMware servers at one time? These may be stuck VAAI sessions... if you open a case with EMC Support, the PSE lab should be able to dial-in and clear them.
Yeah, if it is indeed a stuck VAAI XCOPY session you will need to engage PSE. You can check though by doing a symdev show on the device and seeing if there is a session listed in the "Extent Based Clone" field. If there is a hung session it may list as "Target" or "Source". The symdev list -held command can sometimes expose this too.
Note that both of these may prove negative but a VAAI session could still persist as occasionally Solutions Enabler may be cleared of the session, but Enginuity still has a hung session but not reporting it correctly to SE. So there can be false negatives in SE with this method, but if it lists something in Extent Based Clone you can be sure that is the issue.
Yes, these were ESX datastores that are no longer needed. We have unmounted and detached them from all the ESXi hosts already. Is there a command we can issue to release stuck VAAI sessions or do we need the PSE?
Regarding the symclone suggestion, I don't see any pairing information in the symdev output but we have done symclone list and that returns "No Copy sessions found".
The problem was a hung XCOPY VAAI session. The day after I opened the case, our account SE called to say there is a code upgrade to fix an issue with snaps and clones that can result in hung sessions that should also fix hung VAAI sessions. He recommended we upgrade to 5876.163.105.
seancummins
2 Intern
•
226 Posts
1
June 20th, 2013 12:00
Were these devices presented to VMware servers at one time? These may be stuck VAAI sessions... if you open a case with EMC Support, the PSE lab should be able to dial-in and clear them.
dynamox
9 Legend
•
20.4K Posts
0
June 20th, 2013 12:00
run symdev show on that device and look at its pairing ..if you see another device, add them to a file and run symclone terminate
seancummins
2 Intern
•
226 Posts
0
June 20th, 2013 13:00
You'll need a PSE for this one.
codyhosterman
286 Posts
0
June 20th, 2013 13:00
Yeah, if it is indeed a stuck VAAI XCOPY session you will need to engage PSE. You can check though by doing a symdev show on the device and seeing if there is a session listed in the "Extent Based Clone" field. If there is a hung session it may list as "Target" or "Source". The symdev list -held command can sometimes expose this too.
Note that both of these may prove negative but a VAAI session could still persist as occasionally Solutions Enabler may be cleared of the session, but Enginuity still has a hung session but not reporting it correctly to SE. So there can be false negatives in SE with this method, but if it lists something in Extent Based Clone you can be sure that is the issue.
You_Want_How_Ma
53 Posts
0
June 20th, 2013 13:00
Yes, these were ESX datastores that are no longer needed. We have unmounted and detached them from all the ESXi hosts already. Is there a command we can issue to release stuck VAAI sessions or do we need the PSE?
Regarding the symclone suggestion, I don't see any pairing information in the symdev output but we have done symclone list and that returns "No Copy sessions found".
sauravrohilla
859 Posts
0
June 20th, 2013 19:00
was this device expanded recently using protect bcv option?
You_Want_How_Ma
53 Posts
0
June 26th, 2013 06:00
The problem was a hung XCOPY VAAI session. The day after I opened the case, our account SE called to say there is a code upgrade to fix an issue with snaps and clones that can result in hung sessions that should also fix hung VAAI sessions. He recommended we upgrade to 5876.163.105.