How to make a new OpenVZ template from an existing template for Proxmox
Category : How-to
The kind folks over at OpenVZ.org have created a rift of templates which we can use as a starting point for our template. It is possible however, to create your own template from scratch based on your favorite Linux distribution – that will be coming in a later blog post.
The starting point for this blog post is to have downloaded a template and started it up in a container. If you don’t have any templates you can download one from OpenVZ. If you use Proxmox as your hypervisor you can download one via the web gui by clicking on your storage, clicking and finally Templates.
So, as I say, you need to have a container up and running and for this post we are going to assume it is running under the VMID of 100. Make any required changes to the template such as:
- apt-get update && apt-get upgrade (for Debian based containers).
- yum update (for anything RedHat).
When you are ready to create the template, turn of the container by using the GUI’s Shutdown button or issuing the command halt in the containers terminal.
The next thing to do is to remove the network interface. It doesn’t matter if you use veth or venet – just use the web gui and remove the network device. 
Once this is complete, login via SSH to the Proxmox server and cd to the root directory of the container. If you have the default setup, this will be /var/lib/vz/private/100.
ssh root@proxmoxserver cd /var/lib/vz/private/100
Issue the tar command to create the template archive (remember to keep the . on the end, it’s important!). You can change the container template name to anything you like, but I have found it best to conform to the following formula:
operatingsystem-version-archtype-description.tar.gz
tar -cvzpf /var/lib/vz/template/cache/oracle-6-x86_64-intitial.tar.gz .
That’s it! You can now select the container when creating a template from either the GUI or using CLI commands.
I have made a patch for the Proxmox web GUI to add this functionality to the the interface. See my GUI changes blog post for more information.
6 Comments
Francisco
15-Feb-2014 at 8:48 pmHelp a lot. I’m starting with OpenVZ.
I’m using KVM for a long time, and now learning OpenVZ.
Thank you!
Ap.Muthu
5-Oct-2014 at 1:52 amThere are quite a few posts in the Proxmox forum and the Proxmox wiki which show that this is insufficient.
There will be a need to
1. package the container (tar) with numeric ids
2. remove temporary files
3. eliminate ssh keys (will be auto generated on first boot of cintainer made from it)
4. Remove any stale PIDs
5. remove apt cache (apt-get clean all) before shutdown
6. remove /etc/hosts and /etc/resolv.conf (place additional entries / modifications in a setup file to be executed on first boot and removes itself)
james.coyle
5-Oct-2014 at 5:35 pmHi,
I agree and disagree, almost equally, on all points.
1) I don’t follow.
2) I wouldn’t say this is life and death – obviously it’s ideal but hey, what’s a few temporary files between friends?
3) I agree unless like me you require all machines and templates to use the same key, for example in a DEV environment.
4) Again, ideal and, dare I say it, “best practice” but won’t usually cause any issues.
5) I prefer to keep the cache – it saves that first update taking ages, and all to save a few MBs?
6) This is updated by Proxmox when the new instance is fired up, so again, not a huge issue.
Point 3 is a good point, and I agree in many instances, disagree in others. This is simply taking a machine and creating an almost identical clone and as such, byte-for-byte all files and settings will be replicated. This is a blessing just as much as it is a curse.
The key is to understand the process and make your own decisions.
nemo
3-Mar-2015 at 2:38 pmI believe Ap.Muthu is referring to the ownership of the files by uid with #1. In my opinion, tar does that well enough since it stores both username and numeric id anyway and “–same-owner” is default when unpacking as root. Maybe he’d prefer –numeric-owner, but I really can’t find a good reason for that. If you need users and files cleaned up in the template, clean them up before tarring.
Joel
15-May-2015 at 12:10 pmI dont think works any more.
Under /var/lib/vz/private/1/ ,
I see a directory root.hdd instead of regular directories of the vm.
paolo
8-Jun-2015 at 2:40 pmThanks for your help
We got a problem in a DEV environment: the bare metal hosting machine (proxmox latest) is in datacenter. We have 20+ devs machine created using centos-6 openvz container personalized with apache & mysql installed.
I saw that the root password of the containers change randoom without request (if i change the password, stop / shutdown / backup / restore manually the machine the password is still the same: if I leave the machine and return after 3 or 4 days the root password change )and if we want to access we need to reset the password thru vzctl set or via vzctl enter XXX and then passwd.
This thing happens only on the personalized template: we have also another ubuntu 14.04 container on it that doesn’t give us this problem.
I don’t think someone hacked us: we block every access outside vpn, we have one single-point of access (OPENVPN) and only one of these 20 machines is online outside the vpn (thru prerouting capabilities of iptables, only for port 80 & 443). What’s wrong?