假设您在一个拥有众多数据中心的组织中，每个数据中心都拥有自己的运行在VMware vCenter 5.5上的私有云。 有不同操作系统的VMware模板，包括Windows，Redhat Linux等
假设有两个私有云，C1和C2。 C1一年前build成，C2最近才build成。 让我们假设它运行Windows 2012.自C1build立以来，基本模板被更新了几次。 例如，.NET框架从v4.0更新到v4.5，然后更新到v4.5.1。
C1中的虚拟机需要重build。 但是，该虚拟机中运行的软件与.NET v4.5或v4.5.1不兼容。 所以我们唯一的模板是不兼容的。 我们必须重新创build这个模板，很可能会安装一些可能导致虚拟机出现问题的操作系统补丁等。
所以看来这应该是版本模板的最佳实践。 什么是最好的方法？
这是我的尝试：
是否有更强大的版本化VMware模板的方法？
我想你正试图用错误的工具来解决你的问题。 VMware模板与传统操作系统映像非常相似。 他们确实有两件事情：1）提供一个一致的已知好的基础，即所有的服务器都从头开始; 2）减less从安装介质到已知良好状态所需的重复pipe理任务。 您可以构build您的模板以满足您车队中最常见的configuration。 如果你有这么多不同的需求，那么你的“共同的分母”模板是如此的多余，以至于模板和期望的状态之间存在巨大的差距，你必须开始做math计算来确定维护多个模板的努力是否值得您从您的“公分母”模板转到您的专业模板所需的任务中进行了保存。 根据我的经验，维护多个模板或图像往往比执行configuration所需的工作量要多得多。 正如你已经发现维护不同的模板这种方式是一个对数曲线，而不是一个线性 – 特别是在一个异构的环境。 这就是为什么影像对于桌面电脑来说效果如此之好，但对于服务器来说则不太有用
您的解决scheme在于减less从您的“公分母”模板到您的专业期望configuration所需的任务。 这基本上是configurationpipe理。 在Windows生态系统中，您正在查看GPO，PowerShell DSC和SCCM等工具。 我不太了解Linux世界中的企业工具，但应该像Puppet或Chef那样工作。
如果您想要的最终状态configuration有显着的多样性，使用模板或图像来减lessconfiguration工作往往是一个失败的游戏。
如果您为此使用模板，您将需要构build一些脚本（可能使用PowerCLI）来执行快照，修改和复制模板的任务，并将其标记为版本或将其放入某种版本控制系统可以处理这个大小的文件。 再一次，我怀疑用这种方法解决你的问题的努力不如使用某种configurationpipe理系统。