情況：

在集成的一體化 ESXi/ZFS-Storage 伺服器上，儲存 VM 使用裸機磁碟並通過 NFS（或 iSCSI）將文件系統導出回 ESXi，ESXi 將其用作其他 VM 的池儲存，存在更新儲存虛擬機時會出現問題，因為許多正在執行的虛擬機都依賴於它，並且會因或類似原因而超時NFS.AllPathsDown，這相當於從普通伺服器中拉出驅動器而不將其關閉。

當然可以關閉所有虛擬機，但這會變得非常耗時且乏味（或者必須編寫腳本）。將虛擬機移動到另一台主機是可能的，但需要更長的時間，並且在較小的設置中可能是不可能的，因為單台機器就足夠了。暫停虛擬機可能會起作用，但速度也很慢（有時比關機慢）。

可能的解決方案…

1. 一個簡單而有效的解決方案似乎是通過 CLI 停止 VM 程序，在使用kill -STOP [pid]找到它之後ps -c | grep -v grep | grep [vmname]，執行儲存 VM 的升級/重新啟動，然後使用 繼續執行 VM 程序kill -CONT [pid]。
2. 一個類似的解決方案可能是快速重啟（在 Solaris/illumos viareboot -f或 Linux via 上可用kexec-reboot）的組合，它需要幾秒鐘而不是幾分鐘，以及 ESXi 中的 NFS 超時（在失去 NFS 連接時，我認為所有 I/O 都會暫停120 秒，直到假定儲存永久關閉）。如果重新引導時間在 ESXi NFS 視窗內，理論上它應該類似於由於錯誤更正而一分鐘沒有響應但隨後恢復正常操作的磁碟。

……還有問題？

現在，我的問題是：

1. 哪種方法更可取，或者它們同樣好/壞？
2. 在數據庫、Active Directory 控制器、使用者執行作業的機器等特殊情況下會有哪些意外副作用？
3. 哪裡應該小心？連結部落格上的評論提到，例如，當 CPU 凍結時，可能會出現計時問題。

---

編輯：澄清這個問題的範圍

在收到前兩個答案後，我認為我的問題措辭不夠清楚或為簡潔起見遺漏了太多資訊。我知道以下幾點：

• VMware 或其他任何人都不支持它，不要這樣做！：我沒有提到這一點，因為第一個連結已經告訴了它，而且我也不會問這台機器是否由 VMware 支持管理。這是一個純粹的技術問題，支持的東西超出了這裡的範圍。
• 如果今天設計一個新系統，有些事情可以通過其他方式來完成： 正確，但是由於系統已經執行了幾年穩定，我不想把嬰兒和洗澡水一起扔掉，重新開始，引入新的問題。
• *購買硬體X，你不會有這個問題！*誠然，我可以以相似的成本購買 2 或 3 台額外的伺服器並擁有完整的 HA 設置。我知道這是怎麼做到的，這並不難。但這不是這裡的情況。如果這對我來說是一個可行的解決方案，那麼我一開始就不會問這個問題。
• 只需接受關閉和重啟的延遲：我知道這是一種可能性，因為這是我目前正在做的事情。我提出這個問題是為了在目前設置中找到更好的替代方案，或者了解已證實的技術原因，其中概述的一些方法會出現問題 - “它是不可預測的”，沒有任何解釋為什麼在我的書中沒有得到證實的答案。

---

因此，重新表述問題：

1. 這兩種方法中的哪一種在技術上更可取，為什麼，假設設置是固定的並且目標是減少停機時間而不會給數據完整性帶來任何負面影響？
2. 在特殊情況下有什麼意外的副作用，例如

• 使用者和/或應用程序訪問它們的活動/空閒/靜止數據庫
• 這台機器上和/或其他機器上的 Active Directory 控制器（在同一個域上）
• 通用機器空閒或使用者執行作業或執行自動維護作業（如備份）
• 網路監控或路由器等設備
• 在此伺服器或另一台或多台伺服器上使用或不使用 NTP 的網路時間

3. 在哪些特殊情況下最好不要這樣做，因為缺點大於優點？哪裡應該小心？連結部落格上的評論提到，例如，當 CPU 凍結時可能會出現計時問題，但沒有提供任何推理、證明或測試結果。

4. 這兩種解決方案之間的實際技術差異是什麼？

5. 由於主機上的 CPU 過載，VM 程序的執行停止

6. 由於磁碟或控制器故障而增加了磁碟 I/O 的等待時間，假設它低於 NFS 門檻值？

我的建議是完全避免這個問題。您提到增加成本和完全重新架構是阻礙因素，但在這種情況下您可以考慮在雙節點故障轉移集群中的主機上擁有兩個儲存 VM。這將允許您修補其中之一（但不能同時修補兩者），而不會影響集群服務的 NFS 或 iSCSI 的可用性。它仍然不是一個受支持的解決方案，但它至少允許在維護方面具有一定的靈活性，但代價是增加了用於儲存的資源成本（主要是你為第二個儲存 VM 提供了多少記憶體）。

如果改變架構是完全不可接受的，那麼最安全的選擇是關閉虛擬機。

下一個最佳解決方案是在您的虛擬機中啟用休眠。休眠將確保所有文件系統都處於靜止狀態，有助於避免可能的損壞。

接下來，您可以使用記憶體狀態拍攝 VM 的快照，強制終止 VM 的程序，然後在完成後恢復到快照。這會導致一個可能失去數據的小視窗，但我相信您永遠不會在維護視窗之外嘗試此操作，因為任何數據失去都是不可接受的，因此這應該是無關緊要的。此解決方案與創建快照一樣快，可確保 VM 不會抱怨磁碟失去，但確實會導致潛在的數據失去。

最後，如果你想暫停程序（並且已經測試過它確實有效），那麼我強烈建議你首先同步來賓中的所有磁碟（在 Linux 中，這將通過 /bin/sync 完成。提供的實用程序由 SysInternals for Windows：http ://technet.microsoft.com/en-us/sysinternals/bb897438.aspx ），并快速執行您的維護，這樣時鐘就不會被調得太遠。

至於潛在的副作用，任何連接 AD 的機器必須（預設情況下）在 DC 時間的 5 分鐘內。因此，在任何解決方案之後，除了正常關閉之外，VM 不連續可用，我建議您強制恢復的來賓更新其時鐘。在數據庫伺服器上，不要在伺服器繁忙時執行這些操作，因為這會增加文件系統損壞的可能性。

除了正常關閉或高可用性儲存之外，所有選項的主要風險是損壞。緩衝區中可能會有一些 I/O 將被丟棄，應用程序可能會錯誤地認為這些 I/O 已成功完成。更糟糕的是，I/O 可能已由較低層重新排序以獲得更優化的寫入模式。這可能會導致部分數據被亂序寫入。也許在寫入數據庫行的數據之前行計數增加了，或者在校驗和數據物理更改之前更新了校驗和。這可以通過只允許同步寫入儲存來緩解，但會以性能為代價。

引用自：https://serverfault.com/questions/800688