One new great feature in vSphere 7 is template versioning. You heard that maybe already somewhere, or read it on various blog posts shortly after the announcement of vSphere 7.
I recently had to restore some of my Windows templates because something went wrong. Then I said, why not try out the new template versioning? Well, it’s easier said than done. I’ve found out that working with templates in vSphere 7 isn’t much of a difference than it is in vSphere 6.x. It’s also not a big difference when working with content libraries. But there are still some differences and maybe even limitations. I’ll update this post when I find out more about this. Maybe I’m just doing it wrong, or it is a bug like the one where VMs and Templates view doesn’t show folders after two levels in vSphere client (KB 78693).
What is vSphere template versioning?
First, it’s a great feature! With vSphere 7, you can now have multiple versions of a template. For example, you create your base template, then there’s the next version when you install patches and updates, and so on. If there’s something wrong, you can revert to the previous version of your template. Also, if you’ve got a huge template chain already, you can delete the oldest versions of your template. In my humble opinion, there is some space for improvement when working with templates and versioning. But I’ll show you later what that means.
How to work with the new versioning?
As far as I have tested it, you can’t convert existing templates to a template with versioning enabled. I mean there is no button like “convert that template”. It’s a manual task. That counts for templates that are stored somewhere on a datastore connected to your ESXi host as well as for templates that are stored in the content library. But as I already mentioned, maybe I’m just doing it wrong (hopefully not). And in case this should work, I’ll find it out and update this post.
How to work with template versioning then? It’s pretty easy. You set up your virtual machine and do everything you need to prepare it as your VM template. Michael White has some great posts about creating VM templates. Let’s assume that you’ve got your VM ready for the next steps.
Convert a VM to a template
Important: DON’T just convert your template VM to a template yet! You’ll see why shortly. That’s the most important thing I’ve learned so far when working with the new template versioning in vSphere 7. Let’s go through the steps together.
I’ve got my template VM ready, it’s called “CENTOS81-TEMPL”:
Notice: you can see that versioning information is only available in a content library.
To achieve this, you have to clone the VM as a template into your content library. Do it now.
Clone your template VM now as a template to the library:
Notice: that’s the most important step I’ve learned. I tried it many times but versioning didn’t work. I just had to read the information above a bit better to get the important point.
I’ve got a separate folder for the templates itself and also one for the original template VMs. If you pick an identical name for both the VM and the template, it has to be in another folder.
Chose the appropriate folder in the assistant and define a name for the template, then click Next.
In the next step, choose your content library where you’d like to store your template, then click Next.
Select the compute resource for your clone operation, then click Next.
Choose the datastore where the template will be stored and click Next.
Notice: that was one thing that made me curious. The template will not only be stored in the content library, but also on your ESXi datastore. I’m not sure why. Maybe that’s because of the conversion/cloning operations and also for faster deployments. I’m sorry, I don’t know it yet.
Do a review of your options and click Finish.
Check out a template for changes
We’ve got our first template with versioning enabled now. Looks good, doesn’t it?
The VM has been converted to a template and stored in the folder you picked before. It is also stored in the content library.
Create a new version (check-out)
We assume that it is now some time ago when you installed the last updates into your template. And now it’s the best time to check for updates again.
Navigate to your locally stored template and click “Check out VM from this template” on the summary page of the template.
In the check out assistant, set a name for that “temporary” VM, then click Next.
Select the compute resource, and click Next.
If you fancy to power on the VM after check out, you can click the checkbox, then click Finish.
You may notice the new icon the running VM has now after check out. It’s not only the regular green play sign but also a blue dot.
Save the new version (check-in)
In my example, I just installed CentOS 8.1 without any patches in my original template VM. One of the versions I created here is with installed updates.
After making the necessary changes to your template, shut down the VM and click “Check-in VM to template”.
Notice: maybe it is also a bug, or it might be a browser caching issue. But in my case, that button wasn’t available for clicking until I clicked another VM and clicked back to that template VM. I’ll check that as well as some other things mentioned in this post.
When working with versioning, it’s always a good idea to update the check-in notes as well, like a date/time, or specific installed software, etc. so that other users see what has been done the last time the template has been updated.
Just click Check In to update the template now.
If you’re done, you can find the versioning on the summary page of that template.
Things to consider
Maybe you remember what I wrote about the space of improvements above when you look at the next screenshot. You can see the same template but with different numbers (3) and (4). Sure, I played around a little during the write up of that post, that made a jump from no number up to (4). But that’s not the point.
The thing is that you have that template folder on your ESXi host. When you’re working with many different templates (many flavors of operating systems, for example) and you update the templates, let’s say, monthly, then this numbering can get quite cumbersome. Imagine 5 different operating systems which are f templates. After the first update, you’ve got 10 templates in the folder.
I made it a bit easier for me to have only the most recent template versions directly in the templates folder, and move all older versions in a subfolder. As this is only a logical folder, nothing to do compared with Windows Explorer and its folders, you can do this as well. That doesn’t break the versioning in vCenter but gives you a better overview of your templates.
After all, it looks clean and tidy in the content library. But to be honest, we all expect that, don’t we?
What about the content library?
If you were working with templates in your content library before, you might have noticed that your templates were stored at “OVF & OVA Templates”. At least that was my personal experience, no matter which vSphere version I was using. Not a single template was stored at “VM Templates”, no matter if in my homelab or production.
We’ve got now a template with versioning enabled, and this template is stored in our content library. Can I make this template available in other content libraries? Well, I wasn’t able to do so, unfortunately…
Published / subscribed content library
Let’s assume that you have one main content library in your central vCenter, and you’ve got some subscribed libraries, maybe on an hyperconverged system in another location. In theories, you can create a subscribed library on a datastore of that hyperconverged system. You can configure the subscribed library to download the content immediately or only when needed.
That works for regular templates, ISO files, and other things you’ve got in the content library. Unfortunately, I wasn’t even able to get the metadata, the table of contents, of the new versioned templates from my main library to a subscribed library, no matter if it is in another vCenter or even in the same vCenter just on another datastore. And yes, I’ve got two vSphere 7 vCenter in my lab to test and play around. So it’s not a thing of incompatibility.
What we did today
I am happy to summarize today’s blog post here. What did we do today?
- We’ve created a template (well, you did, I already had one for demo)
- We’ve cloned it as a template into the content library
- Then we were able to use template versioning
- We’ve changed something on the template (check-in / check-out)
- We’ve found out that the numbering is cumbersome, but we’ve got a workaround with the additional folder
- We’ve also found out that these versioned templates are not published to subscribed libraries
What’s next?
I’ll try to dig into that template topic a little deeper to find out if it is possible to publish versioned templates also to subscribed content libraries. I mean, why shouldn’t it work? That’s one of the goals of a content libraries, if I’m not wrong, to have one single template / ISO image which can be used in different vCenters and locations. No more updating several templates in different locations, but only one in the centrally managed location. If there is a solution for that, I’ll probably find it, and I’d like to update this blog post as well.