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!
Here is a screenshot of a VM that I had created which has been captured to my Content Library using both the traditional OVF format as well as the new VMTX format.
A really neat feature the team had implemented with VMTX support is that we are also preserving the "old" vCenter VM Template concept. The exact same VMTX image in the Content Library will also show up as a standard VC Template under the "VM and Templates" inventory view. This means you can continue with your existing workflows both UI and API (vSphere SOAP API) while transitioning to the new VMTX APIs (REST) over time and still being able to benefit from using the Content Library.
Speaking of APIs, in addition to the UI, customers can also consume the new functionality through a couple of new vCenter REST API for automation purposes. Below are the two APIs for working with VMTX templates:
- Capture VM to VMTX Template - POST /vcenter/vm-template/library-items
- Deploy from VMTX Template - POST /vcenter/vm-template/library-items/{item}?action=deploy
The new APIs are pretty straight forward to use and I have also updated my Content Library PowerCLI Module to include the following two new functions:
- New-VMTX
- New-VMFromVMTX
The New-VMTX function will take an existing VM and create a new VMTX Template within a particular Content Library, here is an example:
New-VMTX -SourceVMName "Windows10-BaseInstall" -VMTXName "Windows10-VMTX-Template" -LibraryName "VMC-CL-01"
The New-VMFromVMTX will deploy a new VM from a VMTX Template and you have the ability to reconfigure a number of vHW configuration such as CPU/Memory (which I have implemented) but also changing disk and network configuration. For customers who leverage Customizations Specs, the API also supports specifying that during deployment, feel free to take a look at the API documentation for more details and below is an example:
New-VMFromVMTX -NewVMName "Windows10-VM-From-VMTX-Template" -VMTXName "Windows10-VMTX-Template" -PowerOn $true -NumCpu 4 -MemoryMB 12288
If you have an existing VM Template that you wish to convert to a VM to be able to use these functions, you can use the following PowerCLI command:
Set-Template -Template (Get-Template -Name "TEMPLATE-NAME") -ToVM
Finally, I was curious if there were any noticeable differences between the capture and deploy times when switching to the native VMTX format? I ran a quick test with a Windows 10 image that I had built which contained two VMDKs (60GB & 40GB). It consumed ~90GB of disk storage after I uploaded a number of large files to ensure it used up some of space within the GuestOS before running my experiments.
Here are the results for capturing (cloning) a VM to VMTX:
VM Content Library Capture Type | Duration |
---|---|
VMTX Capture | 2min 22 sec |
OVF Capture | 2min 19 sec |
Here are the results for deploying from a VMTX to VM:
VM Content Library Deploy Type | Duration |
---|---|
VMTX Deploy | 2min 6 sec |
OVF Deploy | 3mn 16 sec |
Standard VM Deploy | 2min 10 sec |
I did not expect a difference in the capture time, since it was basically a clone but I was pleasantly surprised at the faster deploy time for a VMTX template compared to OVF.
If you are currently a VMC customer, you can immediately take advantage of the new VMTX capability in Content Library and you will see further improvements in the near future. For on-premises customer, hopefully this gave you a sneak peak at what is to come for Content Library. There is still more work to be done, but if you like what you see or have other feedback, feel free to leave a comment and I will be sure to share that with both Engr/PM teams.
Gert Van Gorp says
hi,
de content library, is that configured on the vsan datastore or can it be stored on nfs storege using the S3 storage appliance of AWS
gert
letsrunit says
Any idea when this may make it out for GA?
William Lam says
Yup, this will be available as part of the upcoming vSphere 6.7 Update 1 release
Rudolf Kleijwegt says
Hi William,
Your screenshot shows a 'Templates' VM folder. But what if such a folder already existed pre-upgrade? What happens to the VMs and/or templates that existed within that folder?
Rudolf
William Lam says
Not sure what you mean? The "Templates" is simply a VM Folder that is pre-created for you when running in VMware Cloud on AWS, you probably won't have this directory in your on-premises environment. There's no relationship between the feature mentioned above and this directory name, this could have been called "Foo" for the Folder name and it would still work 🙂
Rudolf Kleijwegt says
You mentioned that items created in a content catalog also appear in the VMs and templates view. I just assumed that the Templates folder would be the default placeholder for such items and was wondering what would happen if you upgraded from a previous vCenter version and already had a Templates folder pre-upgrade.
So what would be the default location of templates created in a content catalog when viewing them from the VMs and templates view? And can it be changed afterwards?
William Lam says
No, "Templates" is simply a pre-created Folder in VMC (which is where this feature was initially released). You can create your own folders and when creating a VMTX Image, you specify which folder it will reside under. This feature is now in vSphere 6.7 Update 1, so I recommend you give it a try to see how it works 🙂
Rudolf Kleijwegt says
I'll try to upgrade ASAP. There are several features in vSphere 6.7 U1 that make it worth upgrading. Thank you William.
Justin Smith says
Looks like this is supported in 6.7 U1 now since I can see it as an option. Do native powercli commands work to manipulate this or would I still need your ContentLibrary module?
If so, does that only work with VMC still?
Joel C says
What about just updating a Content Library item? i.e. using the same VM/Template to push to the content library to replicate to a linked vCenter?
Jocke says
Hi,
I have the most recent VMware PowerCLI PowerShell Modules installed, and the Get-ContentLibrary cmdlet works just fine. However, no matter what I try, I can't get the New-VMTX or New-VMFromVMTX to work (command not found). If I manually download and import your Content Library PowerCLI Module, I get the New-VMTX or New-VMFromVMTX functions, but the import breaks the current modules.
For example, after the manual import, the Get-ContentLibrary tells me I should be connected to a vCenter Server (Connect VIServer), even though I'm already connected. If I try without your imported module, the Get-ContentLibrary works like a charm again.