Proxmox LXD?
- Thread starter devinacosta
- Start date
CRIU is quite complex, so I am not sure if its worth to support it. Stop/Restart migration is as good in most situations and works out of the box.
But yes, there are plans, but with low priority.
But yes, there are plans, but with low priority.
+1 for CRIU. For us most situations is for a production workload and if we have to take downtime that is not popular. LXC is a key benefit of proxmox, there are many other KVM solutions so it would be good if proxmox would concentrate more on its strengths
the problem with CRIU is that it is very unreliable for most actual usage scenarios. if you have shared storage, container downtime when doing a restart migration should be a few seconds maximum, and probably shorter if you optimize for it.
the comment was about CRIU, not LXD. there is no plan to integrate LXD, but we check CRIU from time to time, but AFAIR the last time we looked at it, it was not ready enough...
Ah, rereading the thread shows that, yes.
Would LXD not be a good upgrade, since it would strengthen the container environment provided?
The full isolation of each LXD OS is better than with LXC, not? I think the toolset with LXD is more powerful as well. I may be wrong, but aren't there more startable images available for LXD than for LXC as well?
The
There was no equivalent solution in 2015 when we switched from the EOL'd OpenVZ to the newer and more mainstream LXC as the low-level tech stack for containers (CTs) in Proxmox VE 4.0. Even now, LXD does not have full feature parity with the pve-container project. While LXD may have some integrations that we do not, such as the rather gimmicky CRIU one, it also lacks some features that we already have and require in Proxmox VE. Note that the pve-container also provides full CLI tooling and REST API parts for managing CTs from the Proxmox VE API daemons and web UI.
If there's some feature that LXD has, fully works and is sensible to integrate in Proxmox VE, the solution is not to switch to LXD, but rather to integrate it into in the pve-container project. This approach requires less effort than a complete switch and allows for better integration with Proxmox VE.
pve-container project and its tooling (e.g., pct = Proxmox Container Toolkit) is already doing all that and more. We're using LXC similarly as LXD does: as low level toolkit which we control with higher level management, things like a syscall filter daemon written in rust (ref) and additional kernel features.There was no equivalent solution in 2015 when we switched from the EOL'd OpenVZ to the newer and more mainstream LXC as the low-level tech stack for containers (CTs) in Proxmox VE 4.0. Even now, LXD does not have full feature parity with the pve-container project. While LXD may have some integrations that we do not, such as the rather gimmicky CRIU one, it also lacks some features that we already have and require in Proxmox VE. Note that the pve-container also provides full CLI tooling and REST API parts for managing CTs from the Proxmox VE API daemons and web UI.
If there's some feature that LXD has, fully works and is sensible to integrate in Proxmox VE, the solution is not to switch to LXD, but rather to integrate it into in the pve-container project. This approach requires less effort than a complete switch and allows for better integration with Proxmox VE.
Last edited: