假设您所在的组织拥有众多数据中心，每个数据中心都有自己的私有云，运行在 VMware vCenter 5.5 上。VMware 有适用于不同操作系统的模板，包括 Windows、Redhat Linux 等。
假设有两个私有云，C1 和 C2。C1 是一年前建立的，而 C2 是最近才建立的。假设它运行的是 Windows 2012。自 C1 建立以来，基础模板已更新多次。例如，.NET 框架从 v4.0 更新到 v4.5，然后又更新到 v4.5.1。
C1 中的虚拟机需要重建。但是，该虚拟机中运行的软件与 .NET v4.5 或 v4.5.1 不兼容。所以我们唯一的模板不兼容。我们必须重新创建模板，但安装某些操作系统补丁等可能会给虚拟机带来问题，这种情况很罕见。
因此，对模板进行版本控制似乎是一种最佳实践。最佳方法是什么？
以下是我尝试过的：
- 在模板更新之前创建快照。VMware vSphere 工具仍将其视为一个模板，因此从快照“20131031 02:00”创建虚拟机会稍微复杂一些。
- 复制模板，现在我们有“Windows Server 2012 (20131031)”、“Windows Server 2012 (20130331)”和“Windows Server 2012 (20140601)”。这些工具对此支持良好。我们可能很快就会陷入混乱，人们不知道在哪个模板上安装了什么。
- 模板更新后，将其导出。VMware 工具中只有最新模板可用，但出现问题时我总是可以恢复旧版本的模板。
是否有更强大的方法来对 VMware 模板进行版本控制？
答案1
我认为您试图用错误的工具解决问题。VMware 模板与传统的操作系统映像非常相似。它们存在的目的是为了做两件事：1) 提供所有服务器都以之为起点的一致且已知良好的基础；2) 减少从安装介质到已知良好状态所需的重复管理任务。您构建模板以满足整个机群中最常见的配置。如果您有如此多的不同需求，以至于您的“公分母”模板如此稀少，以至于模板与所需状态之间存在巨大差距，那么您必须开始进行计算以确定维护多个模板的努力是否值得您在从“公分母”模板到专用模板所需的任务方面节省的努力。根据我的经验，维护多个模板或映像通常比执行配置所需的努力要多得多。正如您所发现的，以这种方式维护不同的模板是一条对数曲线，而不是线性曲线 - 尤其是在异构环境中。这就是为什么映像对桌面如此有效但对服务器却不那么有用。
您的解决方案在于减少从“公分母”模板到您所需的特殊配置所需的任务工作量。这本质上是配置管理。在 Windows 生态系统中，您正在查看 GPO、PowerShell DSC 和 SCCM 等工具。我对 Linux 世界中的企业工具不太熟悉，但像 Puppet 或 Chef 这样的工具应该可以工作。
如果您期望的最终状态配置存在很大的差异，那么使用模板或图像来减少配置工作量通常会是一场失败的游戏。
如果您坚持使用模板，则需要构建一些脚本（可能使用 PowerCLI）来执行快照、修改和复制模板的任务，并使用版本对其进行标记或将其放入可以处理这种大小的文件的某种版本控制系统中。同样，我认为以这种方式解决问题的努力比使用某种配置管理系统要少。