Proxmox LXD?

devinacosta

Renowned Member
Aug 3, 2017
65
11
73
48
I noticed that Proxmox mainly has LXC support which doesn't allow for container migration (online/hot), which I know LXD supports. Has Proxmox considered supporting LXD within the product?
 
  • Like
Reactions: cave
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.
 
+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.
 
Is there a timeline for LXD support, @dietmar ? It's been 5 years since your comment, so I'm wondering.
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...
 
  • Like
Reactions: fabian
The 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:
  • Like
Reactions: Johannes S
@cheiss

I thought the same, but here and there you read that lxd is more lightweight then a traditional vm.. On one machine I'm using Windows on bare metal with docker to create instances from a template as I need them.. Maybe LXD would make deployment easier..
 
@cheiss

I thought the same, but here and there you read that lxd is more lightweight then a traditional vm..

You confuse lxcs ( Linux containers) with lxd ( Software for managing vms and lxcs) Both lxd ( and it's fork incus) and ProxmoxVE manage vms and lxcs. Lxcs are more lightweight than vms but only work for Linux applications since they run directly on the host. They are also more limited, e.g. running docker in them breaks from time to time after updates thus running docker in them is not supported by Proxmox.
On one machine I'm using Windows on bare metal with docker to create instances from a template as I need them.. Maybe LXD would make deployment easier..
Nope, docker on Windows will always need some kind of vm, lxd will just add another layer which is not needed. Docker for Windows also runs a Linux vm in the background.
 
Last edited:
  • Like
Reactions: cheiss and UdoB