A couple of questions

[Node815]

This is looking good so far!

1. If I have existing data on an external drive, does it require it to be erased to be set up in this?
2. Would this be able to import Proxmox backups and import them in as LXC's?

[fenio]

1. Well bcachefs has option to convert existing filesystem but I never used it and AFAICS it might be problematic with multidevice filesystem so it really depends what are you using currently. As long as this is not multidevice filesystem then inplace migration is possible but NASty doesn't support it currently. bcachefs does.
2. I'm not using Proxmox (well I do but in a limited manner). What exactly are its backups? Kind of snapshots of LXC containers? I'd have to see actual backup to check what could be done.

[Node815]

The backups are basically snapshots.

The existing filesystems are ext4 so more than likely able to be converted. As far as LXC's are concerned, I'm not too partial to them, I've been using the community helper scripts found here on Github which publishes LXC's of apps. I do run a few docker LXC's as well so I would just move everything to one drive if I couldn't convert those LXC's.

[fenio]

Would be easier to see actual files you want to import. As I said I have no experience with Proxmox.
If you can share something without personal data that could be used as test case for LXC import I can give it a try.
For qcow2 images I'm going to implement #65 so that should make it easier to migrate existing VMs.

[Node815]

Here is my small (1014mb file) on Dropbox for this. It's a "neko" LXC which when restore it should display a login (admin/admin) and then spawns a basic web browser. Nothing too fancy. And was a default install from community-scripts.org which supplies many different LXC's.
Zipped Neko LXC Link
Please let me know if you have any isssues retreiving it. I will be removing it in a couple of days.

[fenio]

Thanks for the test backup — that's perfect, it's the shape I was hoping for. Before I start building, I want to make sure I'm scoping this to your actual need rather than trying to be a universal "any LXC anywhere" importer.

A few questions:

1. Are all the LXCs you'd want to migrate community-scripts.org / Helper-Scripts templates? Those have a predictable shape — single app, single systemd unit, Debian/Ubuntu base — and that's the audience I want to design for. If you also have hand-rolled Proxmox LXCs (Alpine, OpenRC, multi-service, weird storage setups), they probably won't import cleanly and I'd rather say "supported: community-scripts; not supported: arbitrary LXCs" than promise something that misbehaves.

2. How fancy do you need the import to be?

   • Minimum viable (what I'm currently planning): unpack the rootfs into a local OCI image, run it as a privileged-ish Docker container with /sbin/init as PID 1, expose it under Docker's bridge network. Your neko ends up on https://nasty/apps/neko/ and the app inside the container starts as if it had booted. You'd lose the LXC's original bridge IP — it'd just listen on a Docker port — but the app works.
   • Nice-to-haves I'm explicitly punting on for the first cut: parsing pct.conf mount points into bind mounts automatically, parsing the network section to give the container its original IP, port-mapping discovery from inside the rootfs.

   Is the minimum viable enough for you? Or is there a specific bit ("must preserve the LXC's IP", "must mount /storage at the same path") that's a deal-breaker without it?

3. Roughly how many LXCs do you have to migrate? If it's 3-5 from community-scripts, MVP solves your whole problem. If it's 50 with mixed shapes, we should design differently.

Once I know I'm not trying to solve "every LXC ever made" the design gets a lot cleaner.

[Node815]

I run about 10 at the most. It's a pretty small setup. To be honest, I'm okay with using docker for all of my setups if needed. But I do also believe that if you could make this cross compatible with their scripts which are over 400 or more that would open up a big audience for your platform too. Just putting my two cents in for there.

[fenio]

Well I can hear you but thing is they are using LXC... which is completely different thing that currently supported Docker.
There are repos of Apps much easier adaptable to my current design. Namesly https://github.com/getumbrel/umbrel-apps or stuff from https://github.com/trueforge-org/
And after all all I'm considering is migration helper... not actual support for LXC. I see no reason in supporting two container systems. I decided to go with docker/docker-compose path as I think they are the most popular ones and cover majority of stuff.

Just a side note... for some time I was using k3s / kubernetes instead of docker ;)