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