情况：
在集成的一体式 ESXi/ZFS 存储服务器上，存储虚拟机使用裸机磁盘并通过 NFS（或 iSCSI）将文件系统导出回 ESXi，后者将其用作其他虚拟机的池存储，当需要更新存储虚拟机时，就会出现问题，因为大量正在运行的虚拟机依赖于它，并且会由于NFS.AllPathsDown类似原因而超时，这相当于在不关闭正常服务器的情况下从正常服务器中拉出驱动器。
当然，可以关闭所有虚拟机，但这非常耗时，而且繁琐（或必须编写脚本）。将虚拟机移至另一台主机也许是可行的，但需要更长的时间，在一台机器就足够了的小型设置中可能无法实现。暂停虚拟机可以工作，但速度也相当慢（有时比关机还慢）。
可能的解决方案...
- 一个简单而有效的解决方案似乎是通过 CLI 停止 VM 进程使用
kill -STOP [pid]找到它后ps -c | grep -v grep | grep [vmname]，执行存储VM的升级/重启，然后使用 继续执行VM进程kill -CONT [pid]。 - 类似的解决方案可能是快速重启（在 Solaris/illumos 上可通过
reboot -f或在 Linux 上可通过kexec-reboot）只需几秒而不是几分钟，并且 ESXi 中的 NFS 超时（在 NFS 连接丢失时，所有 I/O 都会暂停，我认为是 120 秒，直到假定存储永久关闭）。如果重新启动时间在 ESXi NFS 窗口内，理论上它应该相当于由于错误更正而一分钟没有响应但随后恢复正常运行的磁盘。
...还有问题吗？
现在，我的问题是：
- 哪种方法更可取，或者它们同样好/坏？
- 在数据库、Active Directory 控制器、用户正在运行作业的机器等特殊情况下，会产生哪些意外的副作用？
- 哪些地方需要注意？链接博客上的一条评论提到，例如，当 CPU 冻结时可能会出现计时问题。
编辑：澄清这个问题的范围
在收到前两个答案后，我认为我的问题表述不够清楚，或者为了简洁而遗漏了太多信息。我意识到以下几点：
- 它不受 VMware 或任何其他人的支持，不要这样做！：我没有提到这一点，因为第一个链接已经说明了这一点，而且我也不会问这台机器是否由 VMware 支持管理。这是一个纯粹的技术问题，支持内容超出了本文的范围。
- 如果今天设计一个新系统，有些事情可以用其他方式来完成：正确，但由于该系统已经稳定运行了几年，我宁愿不彻底解决问题，而是从头开始，以免引入新的问题。
- 购买硬件 X 你就不会遇到这个问题！没错，我可以以类似的成本购买 2 或 3 台额外的服务器，并拥有完整的 HA 设置。我知道怎么做，这并不难。但这不是这里的情况。如果这对我而言是一个可行的解决方案，我一开始就不会问这个问题了。
- 只需接受关机和重启的延迟：我知道这是有可能的，因为这是我目前正在做的事情。我问过这个问题，要么找到更好的当前设置中的替代方案，或了解证实由于技术原因，一些概述的方法会出现问题——“这是不可预测的”，而没有任何解释为什么在我看来不是一个有根据的答案。
因此，重新表述这些问题：
- 从技术上讲，哪种方法更可取，为什么，假设设置是固定的，并且目标是减少停机时间，而不会对数据完整性产生任何负面影响？
- 特殊情况下的意外副作用有哪些？
- 活跃/空闲/静止的数据库，有用户和/或应用程序访问它们
- 此计算机和/或其他计算机（位于同一域中）上的 Active Directory 控制器
- 通用机器处于闲置状态或用户正在运行作业或运行自动维护作业（如备份）
- 网络监控或路由器等设备
- 此服务器、另一服务器或多台服务器上使用或不使用 NTP 的网络时间
- 在哪些特殊情况下不建议这样做，因为弊端大于利端？哪些地方需要小心？链接博客上的一条评论提到，例如，当 CPU 冻结时可能会出现计时问题，但没有提供任何理由、证据或测试结果。
- 这两种解决方案之间的事实和技术差异是什么？
- 由于主机 CPU 过载，虚拟机进程执行停滞
- 由于磁盘或控制器故障，磁盘 I/O 的等待时间增加，假设它低于 NFS 阈值？
答案1
我的建议是完全避免这个问题。您提到增加成本和完全重新架构是阻碍因素，但在这种情况下您可以考虑在双节点故障转移群集中的主机上安装两个存储虚拟机。这样您就可以修补其中任何一个（但不能同时修补两个），而不会影响群集提供的 NFS 或 iSCSI 的可用性。它仍然不是一个受支持的解决方案，但它至少允许一定的维护灵活性，但代价是增加资源开销（主要是您为第二个存储虚拟机提供的内存量）。
如果改变架构完全不可接受，那么最安全的选择就是关闭虚拟机。
下一个最佳解决方案是启用虚拟机的休眠功能。休眠功能可确保所有文件系统都处于静止状态，从而有助于避免可能的损坏。
接下来，您可以对具有内存状态的虚拟机进行快照，强制终止虚拟机的进程，然后在完成后恢复到快照。这可能会导致一小段时间的数据丢失，但我敢肯定，您永远不会在维护窗口之外尝试这样做，因为任何数据丢失都是不可接受的，所以这应该是相当无关紧要的。此解决方案与制作快照一样快，可确保虚拟机不会抱怨磁盘丢失，但确实会导致潜在的数据丢失。
最后，如果您想暂停进程（并且已经测试过它确实有效），那么我强烈建议您首先同步客户机中的所有磁盘（在 Linux 中，这可以通过 /bin/sync 完成。SysInternals 为 Windows 提供的实用程序：http://technet.microsoft.com/en-us/sysinternals/bb897438.aspx)，并快速进行维护，以免时钟调得太慢。
至于潜在的副作用，任何 AD 连接的机器必须（默认情况下）与 DC 的时间相差 5 分钟。因此，在采用任何解决方案后，如果 VM 不是持续可用（除了正常关机），我建议您强制恢复的客户机更新其时钟。在数据库服务器上，不要在服务器繁忙时执行这些操作，因为这会增加文件系统损坏的可能性。
除了正常关机或高可用性存储之外，所有选项的主要风险是损坏。缓冲区中的一些 I/O 可能会被丢弃，应用程序可能会误以为这些 I/O 已成功完成。更糟糕的是，I/O 可能已被较低层重新排序，以实现更优化的写入模式。这可能导致数据部分无序写入。也许在写入数据库行的数据之前行数已增加，或者在校验和数据物理更改之前校验和已更新。这可以通过仅允许同步写入存储来缓解，但会以牺牲性能为代价。
答案2
答案3
- 哪种方法更可取，或者它们同样好/坏？
两者都不。
这是糟糕设计的代价，除了关闭虚拟机、处理存储虚拟机然后重新启动其他虚拟机之外，我不会采取任何措施让这种情况变得更糟。我还会找人使用受支持/可支持的架构重新设计您的设置。
- 在数据库、Active Directory 控制器、用户正在运行作业的机器等特殊情况下，会产生哪些意外的副作用？
它本质上是不可预测的，如果你再这样做，这次可能发生的事可能不会发生。这是无法忍受的。
- 哪些地方需要注意？链接博客上的一条评论提到，例如，当 CPU 冻结时可能会出现计时问题。
很难建设性地回答这个问题。