simplivity ovc error thrift SSLSocket could not connect

[J-Philippe]

Hi, following a mother board replacement on a SimpliVity node I'm facing the following :

The svt-federation-show return the Node Faulty.

I'm able to SSH the concerning OVC but any command return : error thrift SSLSocket could not connect to "ip adress :9190 (Connection refused)

In the vCenter the OVC did not get the third IP for the storage network: (Mgt and Fed are ok)

Any idea ?

Regards,

Jean-Philippe

[J-Philippe]

To keep this post updated : 

Seems that replacing the motherboard have turn the OVC in a bad state. 

SimpliVity Support try many things to make it start again but without success, even :

tiacli --enableOmniCubeAcceleratorpciereboot && reboot

Zeus script and so on...

The solution is to remove the node from the federation to redeploy it (not fun) => unbelievable ! I'm a huge fan of SimpliVity but I need to undertstand why replacing a  motherborad can make the OVC out of order.  

For IT guys, mind that is you have that kind of intervention planed on your nodes, make sure to have enough space to handle the removal of a node inside your federation.

Best Regards.

[W-Internal]

Hello Jean-Phiippe,

When system boards are replaced they sometimes chnage the ID of the host and there are some commands that might need to be run to correct the issue.  Restarting the OVC multiple times could cause data inconsistency and eventually a re-deploy needed.  These are rare scenarios and I would urge anyone with a Motherboard replacement to call Support after replacement for a health-check to ensure there are no bad eventualities.   

Thank you!

[Kashyap02]

Yes, sometimes system board replacement will result in this kind of situation. We need to verify the database logs to identify what had happened. Also, if the node is not up we can try bringing the node up by repair OVC without redeploying. 

I suggest you to open a case with SimpliVity Support if you have not done yet. 

[J-Philippe]

Hi, thanks it have been done in the meantime, steps at glance :

- unassign zone in order to avoid the space issue rearding the storage usage in my case

- remove the node from federation

- remove the node from the vCenter Inventory

- rebuild the node with the tiny.img

- redeploy the node

- assign zone