May observe repeated error messages in the vCenter Server sps.log files:
YYYY-MM-DDTHH-MM-SS.672Z [pool-12-thread-10] INFO opId=sps-VICNotifier-16977-951 com.vmware.pbm.profile.impl.ProfileManagerImpl - Starting Timer: retrieveContent. Profile ids: [ProfileId{uniqueId = #########-####-####-####-##########}]
YYYY-MM-DDTHH:MM:SS.759Z [pool-12-thread-1] ERROR opId= com.vmware.pbm.hostsync.impl.HostSyncWorker - [HostSync host-####] Exception occurred while checking if host is inSync.java.util.concurrent.ExecutionException: (pbm.fault.PBMFault) { faultCause = null, faultMessage = (vmodl.LocalizableMessage) [ (vmodl.LocalizableMessage) { dynamicType = null, dynamicProperty = null, key = com.vmware.pbm.pbmFault.locale, arg = (vmodl.KeyAnyValue) [ (vmodl.KeyAnyValue) { dynamicType = null, dynamicProperty = null, key = summary, value = No VASA Provider for schema namespace (vtstap) found.
This occurs even when no Veritas or VTSTAP-based VASA providers exist in the current environment. Although the issue does not typically affect normal VM operations, it may cause repeated log entries, PBM-related warnings, or storage policy inconsistency messages.
VMware vCenter Server (VCSA)
Storage Policy Based Management (SPBM)
Environments that previously used or imported storage policies referencing external VASA providers (e.g., Veritas)
No active VASA provider registered for the “vtstap” capability namespace
The SPBM service loads all storage policies and validates their associated capability namespaces. At least one storage policy in the environment contains a subprofile referencing the “vtstap” namespace, typically associated with a Veritas VASA provider.
Because the vCenter Server does not have a VASA provider registered that exposes this namespace, SPBM is unable to resolve the capability. This results in repeated log entries such as:
"No VASA Provider for schema namespace (vtstap) found."
This often occurs due to:
A residual or stale storage policy from a previously installed Veritas VASA provider
A policy imported from another environment
Database remnants after removing a VASA provider
Check the vCenter Server sps.log for entries similar to:
Starting Timer: retrieveContent. Profile ids: [ProfileId{uniqueId = #########-####-####-####-##########}]
The uniqueId corresponds to the storage policy profile generating the error.
Access the PBM Managed Object Browser:
https://<vCenter_IP>/pbm/mob/?moid=ProfileManager&method=PbmRetrieveContent
Provide the following XML in the profileIds input field:
<profileIds> <uniqueId>#########-####-####-####-##########</uniqueId></profileIds>
Review the returned content to determine which storage policy is associated with this profile ID.
Depending on usage:
If the policy is not used:
Delete the storage policy from vCenter.
If the policy is in use:
Attempt to recreate or edit the policy to remove invalid capability references.
Note: If capability removal is not possible, contact Veritas and Broadcom Support.
Restarting the sps service may help clear cached entries:
service-control --restart sps
The issue is cosmetic in most cases and does not typically impact VM/storage operations. However, these messages can make it difficult to find other problems in the logs.
Stale VASA capability namespaces can persist if policies remain after removing a VASA provider.
Policy cleanup resolves the issue permanently.