WilliamLam.com

Automating VM Template management using Content Library in VMC

by // 11 Comments

Today, the vSphere Content Library only supports a single deployable VM type using the Open Virtualization Format (OVF) standard. Although customers are familiar with both OVF and OVA (archive of OVF and VMDKs), support for vCenter VM Template is still one of the most highly requested feature for Content Library. This should come as no surprise since many of our customers have built operational procedures and automation workflows for managing VM deployments over the years and simply switching to another format has a significant impact to their existing workflows.

UPDATE (10/18/18) - The VMTX feature is now available in vSphere 6.7 Update 1

I know the Content Library team has been heads down working on a number of enhancements to Content Library and it looks like one of these improvements has recently made its way out onto VMware Cloud on AWS (VMC) which I had just noticed while working in my SDDC.


In VMC, when you right click on a VM and select "Clone as Template to Library", there will be a new option to capture a VM as a VM Template (VMTX) within a Content Library!

[Read more...]

Converting a vSphere Content Library from Subscriber to a Publisher?

by // 5 Comments

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.

Deployment models for vSphere Content Library

by // 7 Comments

When talking to customers about vSphere Content Library deployments, one question I normally get is how best deploy Content Library for optimal workload deployment, especially in scenarios where remote or branch offices are involved? There are two main deployment models for vSphere Content Library as the title has alluded to. The main difference between the two is whether you have a single vCenter Server or if you have multiple vCenter Servers, with each managing its own vSphere infrastructure?

Lets refer to the single vCenter Server case as Scenario 1 and the multi-vCenter Server case as Scenario 2 and below are the two scenarios outlined with additional details.

Scenario 1 (Single vCenter Server):

In this scenario, which is a fairly common deployment for many smaller to mid-size organizations, where you only have a single or very few vCenter Server(s). They are used to manage several remote locations which only consists of ESXi hosts running at each of the locations and storage local to the site is available. In addition, there are several expected behaviors of the content itself which I have formulated into the following table below:

Content Management Content Distribution Content Deployment
Centrally Managed Sync across the WAN Workloads stored and deployed locally

For this type of an environment, you would first setup a published library which stores all the content that you wish to distribute across your remote sites. Next, you would create subscriber library(s) consuming the published library, but instead of storing the replicated content locally, it is actually stored at each of the remote locations and their respective vSphere Datastore(s). This ensures that content is synchronized from our published library out to each of the remote locations, but when content is requested for deployment, the traffic is local to the site rather than going across the WAN.


In the above scenario, since there is only a single vCenter Server, if it ever becomes unavailable then provisioning and management to the remote location will also be unavailable. This is the expected behavior regardless if Content Library is configured.

[Read more...]