Recurring “No VASA Provider for schema namespace (vtstap) found” Errors in sps.log on vCenter Server
search cancel

Recurring “No VASA Provider for schema namespace (vtstap) found” Errors in sps.log on vCenter Server

book

Article ID: 420966

calendar_today

Updated On:

Products

VMware Live Recovery VMware vCenter Server

Issue/Introduction

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.

Environment

 

  • 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

 

Cause

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

Resolution

1. Identify the Storage Policy Causing the Error

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.


2. Retrieve the Profile’s Details Using the PBM MOB

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.


3. Remediate the Problematic Policy

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.


4. Restart SPBM Service After Cleanup

Restarting the sps service may help clear cached entries:

service-control --restart sps

Additional Information

 

  • 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.