3 ms·

LXD is nice. I use it for most of my services where a VM isn't required (e.g. because of running Windows or a particular old kernel). I particularly like that

LXD is nice. I use it for most of my services where a VM isn't required (e.g. because of running Windows or a particular old kernel). I particularly like that it replaces what I used to use debootstrap for, and quicker too. Unfortunately, I've got some older LXC (v1.0) containers that fail to boot under LXD, which means I need to have both container systems installed on my hosts. It's unfortunate that this means I have to have both the "dash" commands like `lxc-ls` and the "space" commands `lxc ls` which return separate lists. That's because one of them is the LXC project, and one of them is the LXD project, confusingly using very similar names for commands. The one feature of LXC that I really miss in LXD is the `lxc-console` command. Among other things, without console it's harder to debug those LXC containers to figure out why they aren't booting under LXD.

sciurus 8y ago
Why can't you replace the older LXC containers with new ones managed via LXD?
- jlokier 8y ago
  Because they don't boot successfully in LXD - their init doesn't like the LXD environment. Obviously this can be fixed but it's non-trivial to figure out why. For the time being it's easier to keep using LXC for those.
  - jlokier 8y ago
    Oh, perhaps I misunderstood your question. If you mean why can't I completely replace them with newly built containers, it's because they are complete but rather old OS images with years of configuration history in them, running specific versions of mission critical applications. They are older than LXC, and were originally run on real servers, then under chroot and UML, then under KVM, before LXC or Docker were a thing. To be tinkered with most carefully. As much as I would like to restart from scratch, with new versions of everything, experience has taught me it would be unwise to do it in a hurry, or without extensive testing. So yes they can be replaced and will be eventually, but it's not a small job and will need time scheduled to it. For the time being it's the Right Thing To Do(tm) to keep the existing images still running as they are.

sciurus 8y ago

Why can't you replace the older LXC containers with new ones managed via LXD?

jlokier 8y ago
Because they don't boot successfully in LXD - their init doesn't like the LXD environment. Obviously this can be fixed but it's non-trivial to figure out why. For the time being it's easier to keep using LXC for those.
- jlokier 8y ago
  Oh, perhaps I misunderstood your question. If you mean why can't I completely replace them with newly built containers, it's because they are complete but rather old OS images with years of configuration history in them, running specific versions of mission critical applications. They are older than LXC, and were originally run on real servers, then under chroot and UML, then under KVM, before LXC or Docker were a thing. To be tinkered with most carefully. As much as I would like to restart from scratch, with new versions of everything, experience has taught me it would be unwise to do it in a hurry, or without extensive testing. So yes they can be replaced and will be eventually, but it's not a small job and will need time scheduled to it. For the time being it's the Right Thing To Do(tm) to keep the existing images still running as they are.