我在一家软件公司工作。我的部门负责（除其他外）构建 VMWare 虚拟机并将其分发给我们的销售团队成员，然后他们使用 VMWare Player 启动它们，为客户运行他们的产品演示。
最近，我发现我们更新和分发这些虚拟机的方式是各种错误的。这是我们更新“Demo VM”的过程：
- 从中央服务器下载新的虚拟机副本（~35 GB）
- 将其设置为持久模式，然后启动它并进行更改，例如将产品升级到最新版本和更新许可证
- 更改完成后，将其关闭并将其设置回非持久模式，然后将整个内容（~35 GB）上传回中央服务器，并使用新的文件夹名称和递增的版本号
- 谁需要最新版本然后从文件服务器下载它（35 GB * X）
这不仅会占用大量网络带宽，而且从网络下载 35 GB 的内容可能会非常耗时，尤其是对于我们远程办公室中无法享受 Intranet 速度的人来说。
我的问题：有没有更好的方法来管理需要在用户机器上本地运行的虚拟机的更新和分发？
我开始质疑我们当前方法的原因是，当更新虚拟机时，只有一小部分文件（VMEM 和虚拟磁盘映像）发生变化，对吧？因此，与其复制整个 VM 文件夹，不如说应该有一种仅上传/下载增量的方法。类似于 Git 等版本控制系统的工作方式。我实际上尝试为此使用 Git，但事实证明 Git 在管理大文件时很糟糕。所以我想我会在这里问。
Rsync 可以很好地解决这个问题。如果您想将差异分发到无法直接访问服务器的机器，您也可以尝试xdelta。
触发更新以在虚拟机内部运行也是一种选择，但您必须小心，如果不耐烦的用户在更新时中断虚拟机，他们不会损坏虚拟机。我会亲自修补VM磁盘文件。
在我看来，一个合适的答案取决于目标操作系统，因为可用的工具差别很大。
在这个工作流程中可能会有一个有趣的转变，它可以通过使其具有可重复性和灵活性来改进流程。让我试着解释一下。正如您所描述的（如果我理解正确的话），这项任务是基于离线建立一个黄金形象，并让销售部门人员克隆它。
（从您提供的信息中尚不清楚该员工是否应该能够修改黄金图像或仅在分发时用于演示目的，这可能会产生我在下面不考虑的后果）。
因此，为了至少给出部分答案，这些是我的
假设：
debian-rules或与流spec配对的文件autotoolsfpmcobbler。可以管理不同的服务，但有趣的是 TFTP、PXE、kickstarting、预置，即配置步骤。或者，pulp也可以分发存储库（不仅在客户端请求时，而且在服务器主动请求时）。puppet,ansible,salt, ..., 即配置步骤。和一些用例：
- 成熟的 GNU/Linux 虚拟机
如果您对上述假设感到不满，那么有很多方法可以确保最终用户可以拥有一台具有您之前决定的确切配置和安装软件的虚拟机。其中之一将涉及使用
vagrant. 使用该软件，您只需要修改一个文件（vagrantfile描述您要构建的机器类型。此外，vagrant还可以将配置的机器处理到您选择的配置管理系统。在线文档非常好，并且有网上很多例子。销售人员的机器可以运行任何操作系统，因为唯一的要求是它们安装
vagrant在主机上。生成一个 Demo VM 只需要一个简单的vagrant up.也有一些有趣的替代方案
vagrant。例如，检查packer。- 基于容器的提案，而不是成熟的虚拟机
如果销售人员的机器可以使用任何 GNU/Linux 操作系统，您还可以利用容器，这是一种运行虚拟化操作系统且开销很小的方式。使用这项技术的更有趣的方式（在我看来）包括但不限于
libvirt：docker和LXC. Docker 有这个概念dockerfile，在功能上类似于vagrantfile，更有趣的是，有一个注册表可以托管您的可分发图像。容器可以作为托管操作系统中的简单服务运行，因此使用它们非常简单。
- 没有操作系统
为了帮助改进分发过程，当然，应该确保只安装最低限度的所需软件。但是有一些方法可以完全没有操作系统。如果您的用例可以从使用类似的软件中受益
supermin，那么一个设备可能小到几兆字节到千兆字节。其他人提出了一种不同的方法，没有托管操作系统，但这种模型似乎不符合您的描述。