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.
Allan Kjaer says
There is a problem with this, you can't deploy them from within the content library to a datastore cluster. This is a problem if you use Aria Automation and have made image mappings to them. I have posted about the problem here. https://www.virtual-allan.com/vmware-vra-8-and-vcenter-content-library/
William Lam says
Content Library does NOT support Datastore Clusters, so this happens regardless of the content used.
Allan Kjaer says
I can deploy a OVA/OVF from the content library to a datastore cluster without problem.
William Lam says
I stand corrected. I had recall this was something that wasn't possible in early days but seems like its possible (confirmed myself). Thanks for sharing and strange that VMTX doesn't follow same model ... I'll have to ask around
Allan Kjaer says
Did you get some information on this?
Daniel Speed says
I was trying this out with my teams a few weeks back, and it turned out that images produced on 6.7 were incompatible with 6.5, even when produced with an appropriately targeted hardware version. (nvram section is new and unsupported on the older version). Various threads about this issue imply that this is not seen as a problem, which implies a less than strong commitment to compatibility.
For us, this has made it difficult to rely this as otherwise very useful functionality.
William Lam says
This would make sense, you're using NEWER functionality and you assume it'll just work with older vSphere releases that did not support that feature? This would be true for almost any newer feature when using vSphere, it simply doesn't work that way. You can build an image in 6.5 and it'll work in 6.7 but not reverse
I also noticed you mention 6.5/6.7, both of which have been EOL'd ... hopefully you're considering upgrading to supported versions to not put your organization at any risks
Daniel Speed says
Our typical workflow has us building images in Dev, and then promoting to prod, which we would typically update vmware versions after testing in Dev too.
Are you suggesting that the only way to manage this is a cluster specifically dedicated to image building that is always the oldest version that we have?
It's highly inconvenient that you can't correctly target older hardware versions for us.
Sharath says
Can we use content libraries across multiple sso domains?
Sharath says
Suppose my Publisher is in SSO-1 and subscriber vcenters are in SSO-1 as well as SSO-2. We observed that we were not able to add as vcenter subscription from different SSO-2 domain
William Lam says
Did you read the blog post?
Sharath says
Yes, and subscription doesn't work between two SSO domains !!!
Sharath says
Hello William,
Let me rephrase my query.
We have two separate vcenter stack which are in two separate ELM (consider Site A & Site B).
Currently one of the vcenter of Site-A is configured as Publisher content Library and rest of the VCs in same ELM of Site-A are configured as Subscriber content libraries.
We would like to have Site-B vcenters which are NOT connected to Site-A ELM to be subscribed to Site-A publisher content library and sync with all the templates.
We are able to create subscriber content library in Site-B using subscription URL of Site-A publisher content library. But we are not able to add new Site-B Subscription in Site-A Publisher content library. It is only able to list all vcenters which are in its ELM and not Site-B vcenters.
What can be done in this case?