0

I'm new to LXC containers and i'm aware of how to move a container from one host to another using the cli move code, but how would it be possible to do this using the pylxd api or any other apis, i need to be able to do this for my upcoming project, thanks.

Jonathan Kumar
  • 553
  • 1
  • 6
  • 20
  • Migrations is a little tricky as more happens then you might think, if you want to do this purely with the api instead of cheating and using `lxc query` or `lxc copy`. You call the api to initialise the container migration, which will return an operation id, use that with the host certificate, to build the *source* param, plus the standard container stuff like profiles, name, config. Then you make a post request to the destination server to create a container, the destination server uses the cert to pull it off the origin. https://github.com/lxc/lxd/blob/master/doc/rest-api.md#10containers – Lawrence Cherone Mar 08 '18 at 19:50
  • @LawrenceCherone Well actually my intentions are to move the container to another host with higher cpu/ram resources when the load is heavy on it and once the load decreases to move it back to the old server where it can run on a proper load. i hear live migration can do this, is it possible to do 'live migration' via an API. – Jonathan Kumar Mar 08 '18 at 21:02
  • sure everything is possible through the api, the cli is just a client that talks to the api over a unix socket, but keep in mind migrations are load intensive, also your need criu installed on both hosts also migrations are not instant. To prevent high loads on the host, you should use limits to prevent containers killing the host also dont add to many containers. – Lawrence Cherone Mar 08 '18 at 21:11
  • @LawrenceCherone Thank you very much for that, just to add, i've also heard of lxd clustering, it's something that's new to LXD so just wondering whether i should use this for my project, or whether the live migration process using criu is better. I would really appreciate your reply, thanks. – Jonathan Kumar Mar 09 '18 at 16:38
  • Yeah that's new, had a quick look at it, looks like a nice feature but its a mode change, if redundancy is important to you and you can afford to spin up 3+ servers which essentially act like one then it might be an option, though it does not load balance from what im seeing its primarily for redundancy, *only the leader serves* until a node goes down.. so all other hosts are syncing until that time. So it depends on the use case. For a *web* setup, you can achieve the same by using a reverse proxy like nginx and having your app deployed to any amount of containers using a deployment strategy. – Lawrence Cherone Mar 09 '18 at 18:33
  • It be interesting to see how it works with nested containers as a cluster on a single host ;p – Lawrence Cherone Mar 09 '18 at 18:41
  • @LawrenceCherone Exactly, my project has currently got no need for redundancy just a strategy for up/down scalability based on traffic outcomes, so that if the concurrent users increase i can spin up a high perf. server and get the container moved their, i think live-migration is the option since it can get the job done and although not instant it doesn't exactly add a downtime for the application (or so i've heard, need clarification on this). P.S that WOULD be an interesting thing to watch LOL :D. – Jonathan Kumar Mar 09 '18 at 19:50

0 Answers0