在之前的博文中（參見Linux Cgroups詳解系列），作者對LXC 的實現做了分析，
這里再例舉一下LXC 的一些不足和作者個人的一些改進意見。
（一） 缺少對磁盤配額（disk quota）的支持
LXC 依賴於Linux Cgroups 實現資源管理的功能，而Cgroups 並沒有相應的
子系統來提供限制磁盤空間的功能。對於服務器整合而言，限制磁盤空間是個很
有用的功能，可以限制單一應用占有過多的磁盤空間，從而導致其他應用失敗。
LXC 現在的解決辦法是在創建容器的時候利用LVM 創建一個LVM 分區來
限制容器可使用的磁盤空間。這個辦法依賴於LVM，用戶在使用LXC 時需要做
額外的工具。最好的解決辦法是將這個功能集成到LXC 本身，而不是依賴於第
三方工具。LXC 實現限制磁盤空間的功能，可以利用內核的resouce counter 機制，
采取類似Cgroups memory 子系統的實現，也可以借鑒OpenVZ 兩級磁盤配額的
實現。
（二） 缺少對寫時復制（copy on write）的支持
對於基於容器的虛擬化技術來說，每個容器都是一個操作系統用戶態實例，
因此每個容器都需要自己的系統函數庫文件等必需文件。如果每個容器都存一份
拷貝的話，在一個系統上有多個容器的情況下，就會造成磁盤空間的浪費。
一個簡單的解決辦法就是對於容器共用的文件，可以只保存一份拷貝，其他
容器都采取硬連接的方式來共享文件。這樣減少占用的磁盤空間，減少內存里的
inode 緩存等。但是如果沒有其他的額外措施，當一個容器修改這種共享文件的
話就會影響到其他容器。解決這個問題的最佳方法就是寫時復制，當有容器對共
享文件寫入時，為其單獨創建一份拷貝。LXC 現在並不支持寫時復制技術。實
現寫時復制，可以借鑒內核對內存寫時復制的實現。內存對共享的內存頁增加了
額外的標記，當進程試圖對此類內存頁寫入時，就會對其執行寫時復制操作。以
此類推，實現寫時復制就需要對文件加入額外的屬性值，並對write 等系統調用
添加額外的處理代碼，以保證當容器對共享文件進行修改時，為其創建單獨的拷
貝。
（三） 進程和容器之間的動態關聯還不夠完善
在基於容器的虛擬化技術中，進程不再是個全局概念，而是從屬於某個特定
的容器（如果我們采取類似Solaris Containers 的觀點，將系統本身看成是一個特
殊的容器的話）。理想情況下，進程跟容器之間是動態關聯的，進程可以在容器
之間遷移。在基於容器的虛擬化技術中，容器既是資源容器，也是隔離的命名空
間。因此，進程的遷移既是資源主體的變更，也是命名空間的變更。就LXC 而
言，資源管理是通過Cgroups 實現的，進程可以在cgroup 之間有條件地遷移；
命名空間的隔離是通過Namespaces 機制實現的，目前內核只支持進程變更有限
的幾類命名空間。LXC 在處理進程在容器間遷移時，使用setns 系統調用切換進
程的命名空間，但是setns 系統調用目前只支持三類命名空間的切換，而LXC 需
要所有的命名空間都切換。因此，在現有內核上，使用LXC 的進程遷移功能會
失敗。LXC 的解決辦法是為內核打補丁來增加對剩余命名空間切換的支持。但
是這種辦法對於用戶並不友好，也抵消了LXC 的一部分優勢，畢竟LXC 相對於
OpenVZ 等技術的一大優勢就是內核級的支持，使用時不用額外打補丁。這個問
題目前還沒有好的解決方法，理想情況就是新版本的內核集成這個補丁。
（四） 不支持checkpoint
checkpoint 技術可以將容器中所有的進程暫時Frozen，並容器完整的狀態存
儲到磁盤上。目前LXC 還不支持checkpoint 技術，雖然利用Cgroups 的Freezer
子系統，可以將容器中的進程暫時Frozen，也可以將Frozen 的進程恢復進行，
但是並沒有存儲容器完整的狀態，效果類似將容器中的進程暫停和恢復。完整的
實現checkpoint，還需要在進程Frozen 時，將容器中所有進程的狀態存下來，這
個可以通過掃描/proc 文件系統，記錄相應的狀態信息來實現。
（五） 不支持容器的動態遷移（live migration）
動態遷移是指將正在運行的容器從一個機器遷移到另一個機器。動態遷移不需要
停止容器中的進程，可以用來維護在線系統，減少服務器宕機的可能。另外，動
態遷移可以通過將容器從負載較高的服務器遷移到負載較低的服務器來優化服
務器集群的資源配置。LXC 目前並不支持動態遷移。動態遷移可以通過
checkpoint 來實現。將容器的進程暫時Frozen，將狀態保存到文件，再將文件傳
輸到目標機器，在目標機器上恢復容器的運行。