SQL Server issue after FI reboot

[ITforever]

Hello,

I have had to reboot the subordinate FI yesterday and the reboot affected SQL Servers. All other hosts/servers in the same UCS chassis were all good. I expected them to still be able to communicate over primary FI. 

Anyone knows what/why/how?

Earliest thanks. 

[Kirk J]

Greetings.

So what specifically about your SQL server was impacted, storage, networking?

Is this a bare metal, GuestVm, etc?  

For VMware unexpected guest networking outages, we frequently see VMNIC to vnic misnumbering (vmnic number is off, and the assumed side A/B as well).

Do/did your other non SQL servers show active dual a/b paths prior to the reboot of the FI?

We get service requests from customers for similar issues, and it is usually a design or config issue that doesn't actually have dual paths.

If you open a TAC service request they will normally look at the FI logs of the un-rebooted FI, and see if any of the vif paths (veth, vfc) went down during the other FI's reboot period, and can also check the adapter logs to see if more than one path went down.

Getting a definitive RCA will need log review.

Thanks,

Kirk...

[ITforever]

Thanks Kirk. See the answer below:

So what specifically about your SQL server was impacted, storage, networking? - Some RDM disks reported busy: The system failed to flush data to the transaction log.

This servers in question have shared RDM disks in physical mode served up by netapp.

Is this a bare metal, GuestVm, etc?  -  VMS in a windows SQL cluster

For VMware unexpected guest networking outages, we frequently see VMNIC to vnic misnumbering (vmnic number is off, and the assumed side A/B as well). - No issues were reported on vcneter except a loss in redundant path which was expected.

Do/did your other non SQL servers show active dual a/b paths prior to the reboot of the FI? - Non SQL cluster server had no problems. They were fine on a single path. Only the ESXI hosts have the dual paths the non SQL VMs are fine on those hosts. I believe this is an Netapp RDM issue. We also have Hitachi RDM disks I think these were ok

We get service requests from customers for similar issues, and it is usually a design or config issue that doesn't actually have dual paths. - how do I verify this?

Thanks.