File [Datastore_name] /<contentlib-ID>/<Template-ID>/<filename> was not found.Deletion of file or directory [Datastore_name] /<contentlib-ID>/<Template-ID>/<filename> from <ClusterName> Content Library #### was initiated from 'cl/[email protected]' and completed with status 'Failure'/var/log/vmware/content-library/cls.log have the following entries:YYYY-MM-DDTHH:MM:SSZ | INFO | OPID | transferService-pool-7-thread-846 | HttpClientEndpointImpl | Transfer session <sessionID>: Received a 503 response while requesting https://VC_FQDN:443/cls/vcsp/lib/ContentlibraryID/Template_ID/ovf%20descriptor. Retrying...
YYYY-MM-DDTHH:MM:SS | DEBUG | OPID | tomcat-http-26 | RequestController | Transfer for file <filename> in item <ID> scheduled for deferred resultYYYY-MM-DDTHH:MM:SS | ERROR | OPID | tomcat-http-26 | VcspServerImpl | file <filename> was not found in library item <ID>
Note:
template.ovf, template.vmdk, template_1.vmdk, template.nvramvCenter Server
This issue occurs due to a PostgreSQL pagination limitation in the publisher vCenter. The system retrieves content library items in pages of 100 using OFFSET-based SQL queries. When the total number of items exceeds 100, items are distributed across multiple pages, and components of a single template may span page boundaries. Because PostgreSQL can return rows in varying orders between queries, some file rows may fall outside the expected page range and be skipped during synchronization.
Broadcom Engineering is aware of this issue and a fix will be included in a future vCenter patch release.
Workaround:
Reduce the number of OVF templates in the publisher Content Library to ensure the total number of corresponding items are fewer than 100. This ensures that synchronization occurs in a single PostgreSQL page and avoids the pagination issue.