Trong quá khứ, Ivy từng được xây dựng lại với tiêu chí sử dụng hoàn toàn Container LXC thay thế cho VM. Tuy nhiên sự cố tràn RAM (Memory Leak) ở qBittorrent không chỉ gây crash chính qBittorrent mà còn làm Memory đầy ở Ivy gây crash các CT/VM khác dẫn tới Ivy cần phải Reboot sau vài ngày sử dụng nên Ivy-NAS bắt buộc phải chạy trong VM. Hiện tượng Memory Leak vẫn còn, tuy nhiên sẽ chỉ gói gọn ở trong VM thôi, và VM Ivy-NAS chỉ đơn giản là Reboot vài ngày một lần mà không ảnh hưởng tới các CT/VM khác trong Ivy.
May mắn là thời gian gần đây mình đã phát hiện ra nguyên ngân qBittorrent dễ tràn RAM và crash sau thời gian dài là do tham số File pool size quá cao, ở mức 5000. Và bằng cách giảm xuống 1000 hay 500 thì hiện tượng này không còn nên có thể coi như vấn đề đã được khắc phục. Với tiêu chí cái gì có thể nhét trong CT thì sử dụng CT, mình sẽ thử nghiệm chạy Ivy-NAS trong CT trở lại trong vài ngày tới.
Việc chạy ở CT thay vì VM có ưu điểm là CT ít overhead hơn VM và ngốn ít tài nguyên hơn, đồng thời resources chia sẻ trực tiếp với OS thay vì qua một cấp virtualization. Đồng thời với NAS thì việc sử dụng Bind mount point để chia sẻ thư mục từ Host tới CT đơn giản hơn rất nhiều so với VM khi VM cần giải pháp phức tạp hơn là sử dụng VirtioFS / Virtio9p / NFS / SMB. Ưu điểm của VM so với CT chỉ ở khi sử dụng Backup / Restore, khi VM có thể Online trong khi CT cần Stop để thực hiện những thao tác này.
Tiện với việc setup CT Library, các thành phần thuộc về Service ở trong Ivy-NAS như Plex, Jellyfin, DAV, SMB,… sẽ được tách ra một CT riêng để các Service này luôn thường trực mà không phụ thuộc vào trạng thái của Ivy-NAS.
Lần setup lại Ivy-NAS dạng CT này, phương án chạy Docker dành cho qBittorrent trong Ivy-NAS hoàn toàn khả thi do LXC đã hỗ trợ Feature keyctl để có thể chạy ảo hóa trong CT thay vì chỉ có lựa chọn chạy trong VM như trước đây. Ngoài ra phương án chạy Ivy-NAS ở VM rồi cài Docker cho qBittorrent cũng được suy xét.