This is a blog post on some old Content Library research which I had looked into several months back for a customer inquiry and realized I never got a chance to write about. When you create a Subscriber Content Library (CL) which synchronize content from a Published CL, the Subscriber CL is basically in read-only mode. Not only can you not edit or modify the content, but the CL itself is also locked as a Subscriber forever. Why might this be a concern or an issue?
Consider the following scenario, where you have a single master CL that contains all the images you wish to distribute amongst your remote sites as efficiently as possible and ideally leveraging CL's built-in replication mechanism. Lets say the master CL is in Palo Alto and you have several vCenter Servers that can be configured as Subscriber CLs in Cork, Ireland. Instead of having configuring each Subscriber to pull remotely from PA, why not replicate that to a single Subscriber located in Ireland and re-publish that content locally to the remainder CL? The ideal workflow would look something like the diagram below.
However, today you can not simply convert a Subscriber CL to also become a Publisher CL. The only option that I could think of without relying on something like externally replicating a CL is to create an additional Published CL from the Subscriber CL. The idea is you would clone from your Subscriber CL in the same vCenter Server to a new Publisher CL and then that CL can then be used by the other local Subscriber CL as depicted in the diagram below.
This functionality currently does not exist in the vSphere Web/Flex Client, however it can be automated using the Content Library REST APIs. I had created a Content Library PowerCLI Module a few months back and one of the functions that would be useful for this workflow is the Copy-ContentLibrary.
The function is pretty straight forward to use, it accepts the name of a source CL that has already been configured as a Subscriber CL and the name of a new Published CL that you have created but is empty.
After that, the contents of the source CL will be copied into the destination CL as shown in the screenshot below.
Depending on the size of your CL, this can take some time but once it has completed, you should that your Published CL is now populated with content from your source CL.
The PowerCLI function also does a few additional things such as checking if a file already exists and will skip the file and move on to help with the copy.
If your intention is to only replicate from your master CL and then create a local publisher CL, there is an additional flag that you can set to $true called -DeleteSourceFile which will delete the files from the Subscriber CL. This is useful if you only have a single Datastore in which both the Subscriber and Publisher CL is storing, which means after the CL copy, you would be consuming 2x the storage as everything has been duplicated. For this particular customer, they only required an initial sync to populate content in their EMEA office and after that, they would be managing it local and not require additional replications from their master CL.
