A commonly miss-understood capability of the vSphere Content Library is managing and distributing Virtual Machine Templates (VMTX), which was introduced in vSphere 6.7 Update 2.
When vSphere Content Library was first released in vSphere 5.0, content was distributed by using a pull-based replication where the subscriber vCenter Server would setup initiate the content subscription to the publisher vCenter Server and then content would then be downloaded to the subscriber vCenter Server as shown in the diagram below.
This initial architecture of vSphere Content Library made it extremely easy for any vCenter Server, regardless of their vCenter Single Sign-On domain, to create a subscription and download content (ISO, OVF/OVA and other files) from the vSphere Content Library of the publisher vCenter Server.
The creation of the vSphere Content Library subscription was managed completely by the individual subscribing vCenter Server as long as it knew the subscription URL and any credentials that may have been configured and of course connectivity to the publisher vCenter Server. While this made it easy for anyone to subscribe content from a vSphere Content Library, it also meant for larger organizations with many vCenter Server(s), an additional task was required to configure each subscribing vCenter Server.
Once content was sync'ed to the subscriber vCenter Server, there was no easy way to control which users can deploy specific OVF/OVA(s) from the vSphere Content Library, which can be a challenge for organizations that requires fine grain access control for workload deployment. How do you ensure specific users/groups were deploying the appropriate or even the latest images?
When the VMTX capability was added to vSphere Content Library, it not only introduced a new Check-In/Check-Out feature for VM Templates but it also added new method for managing VM image distribution across multiple vCenter Servers using a new push-based replication that originates from the publisher vCenter Server.
Instead of going to each subscribing vCenter Server to create a vSphere Content Library subscription, you can now manage all subscriptions directly from the publisher vCenter Server. This additional vSphere Content Library replication method requires all vCenter Server(s) that wish to subscribe to VMTX images, must participate in either an Enhanced Linked Mode (ELM) or in a Hybrid Linked Mode (HLM) where an on-premises vCenter Server is publishing content to a VMware Cloud on AWS vCenter Server (the reverse is not supported today).
Because vSphere Content Library subscription is managed and configured at the publisher vCenter Server, a trust must exists between the publisher and subscriber vCenter Server to be able to create the subscription from the publisher vCenter Server and this is why there is a requirement for either of the linked mode options are required to be able leverage the new VTMX sync capability.
With this background, to manage and create subscriptions to your subscriber vCenter Server(s) to include VMTX images, you need to select the desired vSphere Content Library in your publisher vCenter Server and under the new Subscriptions tab as shown in the screenshot below.
While there are some trade-offs with using the new VMTX capability in vSphere Content Library, there are also some advantages over managing the traditional OVF/OVA Images. If you recall earlier, I mentioned there was no way to control which users were allowed to deploy from specific OVF/OVA images from a vSphere Content Library? With VMTX, you actually have the ability to assign granular permission to user(s) and group(s) on who can see and deploy specific VMTX images, which is a result of the VMTX image being a part of the vSphere Inventory, which means you benefit from vCenter Server permissions.
Below is an example where I have two VMTX images: Photon-3.0 and Photon-4.0 in a single vSphere Content Library and I have assigned permissions such that it respectively maps to lob1-user and lob2-user, who are then only allowed to deployed based on the permissions I have set on the VMTX images.
Furthermore, we can also limit what content a specific subscribing vCenter Server should see, especially if there are different requirements across your vCenter Server deployment(s) and with the pull-based model, all users in the subscribing vCenter Server(s) would be able to see all OVF/OVA from the published vSphere Content Library and that may or may not be a desired outcome based on the needs of your organization.
The alternative approach to limiting OVF/OVA access would be to create multiple vSphere Content Libraries from the publisher vCenter Server, but that can lead to duplicate content needing to reside in multiple libraries which consumes additional storage and adds additional complexity. With this new approach, you can manage a single vSphere Content Library with all your desired VMTX and then leverage vSphere permissions to provide additional access control within each subscribing vCenter Server. Finally, to ensure that each subscribing vCenter Server does not download unnecessary VMTX images that can not be used, you should always consider enabling the Download library content when needed setting and only pre-download content that you know can or will be used by the subscribing vCenter Server.