Linux – Implications of using VMware’s templating and cloning for provisioning Linux servers instead of PXE

linuxprovisioningpxe-bootredhatvmware-esxi

There seems to be speed benefits when using VMware's templates to create new VMs. However, I'm concerned about possible less obvious security and flexibility implications. For e.g.:

  • First boot generated keys
  • VMware proprietary methods of configuring server settings (IPs, hostname, etc.)

In a shop that's almost entirely VMware with a majority of Linux being RHEL-based distros, has anyone come across some pitfalls when provisioning from templates? How about concerns when cloning?

BTW: Regardless of the initial provisioning method, it would primarily be used as a bootstrap to Puppet for the rest of the configuration.

Best Answer

Depending on the environment and your provisioning process, it may be faster to build anew than using VMware templates and the clone from template feature.

I did work in a large Linux-focused VMware environment, where the deployment process wasn't as automated as it should have been. We relied on vSphere templates of RHEL systems, but quite a bit of manual work was needed following the initial clone.

Template advantages:

  • Templates are good if you're baking other applications, configuration settings and things that extend beyond the reach of config management into the template. (e.g. a complex Oracle application stack)
  • The cloning time is a function of your storage and vSphere infrastructure. I've seen really slow and resource intensive cloning jobs occur.
  • If using Red Hat/CentOS/Debian/Ubuntu, for example, you can take advantage of the sys-unconfig command to "unconfigure" a system ahead of templating. This is the Linux equivalent to Microsoft's Sysprep and removes network interface rules, SSH keys, network settings, etc.
  • VMware's IP assignment tools are okay and haven't been too much of a problem with mainstream Linux operating systems.

PXE/kickstart deployment advantages:

  • Usually faster than templating/cloning, assuming you have a local repository and a net boot image.
  • More flexible in that you can make changes to your images/master without the cycle of converting template to VM, modifying, reconverting and cloning.
  • Best when coupled with a configuration management solution.

In the end, it depends on your application and how much additional work is needed following the initial OS install. I've taken a hybrid approach, using clones for the most complex instances and new builds via a provisioning system for routine systems. They're not mutually exclusive.

Related Topic