To add to this -

Jim, if you're on the serial connection as the service account and able to run service scripts, you could also run 'svc_sysstatus' and attach the output here. That would indicate why each SP is in service mode, and if there are associated service code hints on either SP that would help EMC support get your system back up and running faster.

I have now resolved the issue, but had to have EMC support lending a helping hand.

Are there any reasons why a EMC partner cannot or should not use all the svc_ commands...

Because the only thing support did was run one more command than the ones we had already tried...including the ones mentioned in the 2 earlier posts.

Hi

Would these issues not be shown by the svc_diag -state= extended command.

Hi Jim,

Great question. The service scripts that ship on the VNXe are intended to be used in service-engaged situations where either an authorized support person is running the service scripts themselves (locally or via remote access) OR a customer is running the scripts under the direction of an authorized support person.

A subset of the service script functionality is intended for end customer use and those commands are also exposed via the Unisphere GUI on the Service page. You need the service account password to access that page and those commands, but once in you can see the state of both SPs (if in service mode, explains why and gives hint codes for what specifically is failing) and you can perform common service operations like Data Collection ("Collect Service Info"), reboot the SPs, enable SSH, and a handful of others.

The functionality that lies in the service scripts/tools which are not on the Service GUI page in Unisphere are accessible by anyone with the service password, but should not be used unless a support person is engaged as there is a good chance there could be unintended consequences.

Oh, and one other thing to mention - any time that one or all/both of the SPs in a VNXe are in service mode, the first thing to do should be to pull up the Unisphere GUI and look at the service page to see what is wrong. Simply clearing the rescue state and rebooting the SPs will often mask some serious problem and it's important to first know the mode/state of each SP, and if any service hint codes are registered on either SP. Those will pinpoint the problem for authorized service personel and speed up the time it takes to resolve the situation.

The "rescue reason" codes that put the SP into service mode would be shown, and the hint code would be shown as well... but the Unisphere GUI is able to do a translation of the rescue reason codes into a Problem statement and an Action statement that is intended to be user-actionable. Besides that, you're right - it's roughly the same set of information.