虛擬機器關不了機：請求不是電源開關

按下關機。工作開始執行，讀取圖示轉個不停，三分鐘後虛擬機器仍在執行。最後按下停止，它立刻就停了，於是浮現一個明顯的疑問：既然第二個顯然做得到，第一個為什麼沒有用？

這兩者不是同一個動作的兩種力道。它們是兩件完全不同的事。

一切都取決於這個區別

關機是一個請求。虛擬化平台請客體自行關機，就像按下實體機器的電源按鈕，是請作業系統乾淨地關閉。如何處理這個請求，由客體決定。

停止是斷電。它會立即切斷虛擬機器的電源，不經任何溝通。官方文件用很直白的話警告：停止可能導致資料遺失，因此應謹慎使用。

一旦把這兩者分開來看，關不了機的虛擬機器就不再神祕。它並不是在拒絕。內部根本沒有人聽到這個請求。

誰應該負責聆聽

可能的聆聽者有兩個，一台正常的虛擬機器至少會有其中一個。

作業系統的電源按鈕處理程式。在 Linux 客體上，這通常都存在。但在精簡的映像檔、類似容器的設備，或是停在早期開機階段或救援 shell 的系統上，可能就沒有。

客體代理程式。當它已啟用且確實在執行時，會為虛擬化平台提供一條直達內部的通道，關機請求就會走這條路。

如果代理程式沒有開啟，而電源按鈕處理程式又不存在或沒有回應，請求送出後就無處可去。虛擬化平台得到的不是拒絕，而是什麼都沒有，從外部看起來兩者一模一樣，這也正是工作看起來像卡住而不是失敗的原因。

如果虛擬機器經常要花很久才能關機，比起縮短逾時時間，更好的第一步是確認代理程式是否真的在運作。

接著是逾時，然後是強制

等待是有上限的。每個客體預設的關機逾時是 180 秒；時間一到，虛擬機器就會被強制停止。

對整個節點上的所有項目進行批次停止，也有自己的時間預算：它會嘗試乾淨關機，預設最多等待三分鐘，然後強制停止所有仍在執行的項目。

所以，無人看管的關機最誠實的描述是：客氣地請求，等待一段固定的時間，然後拔掉插頭。如果資料庫需要四分鐘才能把資料寫回磁碟，預設值早已決定它只能得到三分鐘。

調高數字，但別跳過問題

很容易把逾時當成要調整的那個設定。對於確實需要更長時間的虛擬機器，調高它是正確的。

但一台無論等多久都不會關機的虛擬機器，問題並不在逾時，給它十分鐘只代表在同樣的強制停止之前多等十分鐘。應先找出內部是否有任何東西在聆聽。

關機工作已經卡住時

如果某個關機工作一直停在那裡，而虛擬機器必須馬上停下來，有一種明確的方法可以停止它，並覆寫正在執行的關機工作，而不是排在它後面等待。這個方法之所以存在，正是因為工作卡住的情況常見到需要一個解答。

使用時要清楚它是什麼：它仍然是斷電，附帶同樣的警告。

最容易讓人中招的情況：停電

從這裡開始，整篇文章就不再只是紙上談兵。

在電池耗盡前關閉客體的停電處理指令碼，會繼承上述所有特性。它送出的是請求。沒有在聆聽的客體會忽略這些請求。逾時開始計算。接著所有仍在執行的項目都會被強制停止，可能是在電池電量已經偏低時，也可能是全部同時發生。

在依賴這類配置之前，有兩件事值得檢查，而且兩者的成本都很低：

客體真的會回應關機請求嗎？在一個平常的下午，拿著碼錶測試其中一台。

總時間預算是否在電池撐得住的範圍內？客體是依序關機的，逾時時間會累加。一排每台各需兩分鐘的虛擬機器，並不是兩分鐘就能完成的關機。

從未演練過的停電計畫，終究會被演練一次：在黑暗中，在時間壓力下。

Atlas 的做法

Atlas 不會發明第三種關機方式。請求與斷電是僅有的兩種方式，假裝還有別的，將會是一個有後果的謊言。

它做的是拒絕讓兩者混淆。具破壞性的操作會在確認之前就表明自己具有破壞性，因此停止永遠不會偽裝成稍微強硬一點的關機出現。這個區別正是本文的全部主題，而一個把兩者呈現為份量相同、並排相鄰按鈕的面板，早就已經失去了這個區別。

每日摘要則負責另一半：非計畫中的重新啟動會被當成事實回報。一台因無法乾淨關機而被強制停止的虛擬機器，到了隔天早上，看起來和當機的虛擬機器一模一樣。兩者都值得被注意到。