A few people have reached out and asked me to comment on this post.
Its probably worthwhile clarifying a few things first.
In the context of VVols, the VASA provider should ideally be stateless. In other words, if it goes away for some reason, this should have no impact on your VM I/O. Yes, it will impact certain operations such as creation of new VMs, snapshots, etc, but will not impact the current running VMs. This is because the VASA API calls are currently out of band from ESXi to the storage array via the VP. Now a VASA provider can be configured in a HA mode, so that one VP is the primary and the other(s) are backups. This is what we have done with VSAN which also uses a VP. So this would be a good question to ask your storage vendor .. can your VP be setup in a HA configuration? If not, then you would just need to deploy out a new one. Now, I prefaced the start of this response by saying "ideally", the VP would be stateless. There is no need to storage anything on the VP. However that is not to say that any of our storage array partners have put something into their VPs that would no longer make them stateless. Yet another question to ask your storage vendor.
The other query is in relation to vCenter server. The VVol information that is stored by vCenter server is related to the policies (SPBM) that the VMs are using. Again, if vCenter goes away, this has no impact on the running VMs. The policy information associated with the VM continues to be used by the VMs. The issue is that if you do not have a vCenter server backup and you deploy a new vCenter, then it will not have the policy information for your running VMs. So these policies will need to be recreated, which is possible, though it might be a little tedious/manual. Again, we have ways of doing this for VSAN, and I suspect it is the same for VVols (though I admit I have not tried this scenario). I suspect that this might be why it is a good idea to backup your vCenter (or the VC db).
I'm a bit confused as to why people feel that failures in either of these components can lead to data loss in VVols. I/O to VVols does not depend on vCenter or the VASA Provider. These are components needed for configuration and management, but should not lead to any sort of data loss issues if they are not present. The paradigm with the VVol architecture is that the storage is the source of truth, whilst the VP is your guide. We would hope that the storage vendors do due diligence on their respective implementations, but just like the VAAI implementations of the past, that will probably vary from vendor to vendor.
Hope this helps.