SimpliVity datastores inaccessible while Upgrading from 3.7.2 to 4.0.1

[bhwong]

My company has paid HPE to upgrade our SimpliVity from 3.7.2 to 4.0.1 and during our 2nd hop from 3.7.6 to 3.7.9 yesterday, we have already encountered all SimpliVity datastores inaccessible, causing all our VMs in the SimpliVity cluster to freeze up.

It was only when we shutdown the upgraded OVC that has incomplete services running that the failover finally take place and all our VMs recovered.

Thus, I would like to take this opportunity to request for further enhancement to the SimpliVity reliability by auto trigger a failover if vCenter detected inaccessible datastores.

btw, is there a manual way of triggering a failover when similar issue happen again?

P.S >Admin >  This post was moved as a new Topic from Upgrading To 4.0 From Previous Versions **Important Information Before Upgrading** 

[tonymcmillan]

I have had a similar experience with SVT datastore inaccessible but for a different reason that I will explain later. 

What I'd like to know is how did you end up with running VMs on a host with a defective OVC? We've always made sure to vMotion all running VMs to other hosts before upgrading the OVC. 

In regard to our issue, it was actually quite simple, the boot controller that houses ESXi and the OVC failed, causing the OVC to fail. We ended up powering off the node with the failed boot controller and VMware HA kicked in and restarted the VMs on the host. We're wondering if the OVC can trigger an HA event upon detecting such a failure. This issue happened on 3.7.10, we are going to test on 4.0.1.

[MikeSeden]

There is a difference between SimpliVity HA and VMware HA.

SimpliVity HA occurs when the VM has a Primary hive (copy) on the node where the VM is located and a Secondary hive (copy) on another node.  Or to put it another way , when there are 2 copies of the VM on 2 SimpliVity nodes. If the node the VM is on (and the primary copy) goes down the secondary realizes it and becomes the primary. SimpliVity is in HA.

VMware HA service must be turned on for a new VM to be failed over to.
VMware HA at this point kicks in. It realizes the VM is down, sees the new primary copy and creates a new VM from the new primary copy. VMware HA creates the VM, not SimpliVity.

The 2 HA's work together with simpliVity keeping the 2 copies (hives) in sync with the VM's I/O changes. If it is written on both copies so all 3 are the same, it has done it's job. VMware HA service is what spins up the new VM to be the failover.

[DaveOb]

APD should not occur when an OVC is powered off and should be investigated there are some failover improvement in 4.0.1 but each case is different and an analysis is impossible in such a forum.The HPE team responsible  for the upgrade can open a ticket with support to provide an analysis of the event.