Linux on VMware - 為什麼要使用分區？
在虛擬化環境（在我的情況下為 ESXi）中安裝 Linux VM 時，是否有任何令人信服的理由來對磁碟進行分區（使用 ext4 時），而不是僅僅為每個掛載點添加單獨的磁碟？
我唯一能看到的是，使用 fdisk 可以更容易地查看磁碟上是否存在數據。
另一方面，我可以看到一些不使用分區的充分理由（顯然，除了 /boot 之外）。
- 更容易擴展磁碟。只是增加VM的磁碟大小（通常在VCenter中），然後重新掃描VM中的設備，並線上調整文件系統的大小。
- 將分區與底層 LUN 對齊不再有問題。
我在這個話題上沒有找到太多的東西。我錯過了什麼重要的事情嗎？
這是個有趣的問題…
我不認為有一個明確的答案，但我可以提供一些歷史背景，說明圍繞該主題的最佳實踐可能如何隨著時間而改變。
自 2007 年以來，我不得不支持在 VMware 環境中以各種形式部署的數千個 Linux VM。我的部署方法已經發展，並且我擁有繼承和重構其他工程師建構的系統的獨特（有時是不幸的）經驗。
昔日…
回到過去（2007 年），我早期的 VMware 系統就像我的裸機系統一樣被分區。在 VMware 方面，我使用拆分的 2GB 厚文件來組成 VM 的數據，甚至沒有考慮多個 VMDK 的概念，因為我很高興虛擬化甚至可以工作！
虛擬基礎設施…
在 ESX 3.5 和早期的 ESX/ESXi 4.x 版本（2009-2011）中，我使用的是 Linux，在單體厚配置 VMDK 文件上正常分區。必須預先分配儲存迫使我以與實際硬體類似的方式思考 Linux 設計。我正在為作業系統創建 36GB、72GB、146GB VMDK，對通常的 /、/boot、/usr、/var、/tmp 進行分區，然後為“數據”或“增長”分區添加另一個 VMDK（無論是 / home、/opt 或特定於應用程序的東西）。同樣，這個時代物理硬碟大小的最佳點是 146GB，並且由於需要預先分配（除非使用 NFS），所以我需要對空間保持保守。
精簡配置的出現
VMware 在後來的 ESXi 4.x 版本中圍繞精簡配置開發了更好的功能，這改變了我開始安裝新系統的方式。隨著 5.0/5.1 中添加了完整的功能集，一種新型的靈活性允許更多的創意設計。請注意，這與虛擬機功能的增加保持同步，即有多少 vCPUS 和多少 RAM 可以送出給單個虛擬機。與過去相比，可以虛擬化更多類型的伺服器和應用程序。這是正確的，因為計算環境開始完全虛擬化。
LVM太可怕了……
到 VM 級別的完整熱添加功能已經到位並且很普遍（2011-2012 年）時，我正在與一家致力於不惜一切代價維持其客戶 VM 正常執行時間的公司合作（愚蠢）。因此，這包括線上 VMware CPU/RAM 的增加以及在現有 VMDK 上調整*風險的 LVM 磁碟大小。*此環境中的大多數 Linux 系統都是單個 VMDK 設置，在 LVM 之上具有 ext3 分區。這很糟糕，因為 LVM 層增加了操作的複雜性和不必要的風險。例如，/usr 中的空間不足可能會導致一系列錯誤決策，最終意味著從備份中恢復系統……這部分與流程和文化相關，但仍然……
分區勢利…
我藉此機會試圖改變這一點。我在 Linux 中有點像分區勢利小人，覺得文件系統應該分開以滿足監控和操作的需要。我也不喜歡 LVM，尤其是使用 VMware 和執行您所要求的事情的能力。因此，我將 VMDK 文件的添加擴展到可能增長的分區。如果需要，/opt、/var、/home 可以獲取它們自己的虛擬機文件。這些將是原始磁碟。有時這是動態擴展特定尺寸過小的分區的更簡單方法。
歐巴馬醫改…
隨著一個非常知名的客戶的入職，我的任務是設計 Linux VM 參考模板，該模板將用於創建他們極其可見的應用程序環境。應用程序的安全要求需要一組獨特的掛載，因此與開發人員一起嘗試將非增長分區填充到一個 VMDK 上，然後為每個具有增長潛力或具有特定要求（加密、審計等）因此，最終，這些 VM 由 5 個或更多 VMDK 組成，但為將來調整大小和保護數據提供了最佳靈活性。
我今天做什麼…
今天，我對 Linux 和傳統文件系統的總體設計是一個瘦 VMDK（分區）上的作業系統，以及其他任何東西的離散 VMDK。我會根據需要進行熱添加。對於像 ZFS 這樣的高級文件系統，它是一個用於作業系統的 VMDK，另一個用作 ZFS zpool 的 VMDK，可以調整大小、雕刻到其他 ZFS 文件系統等。