Damned if you do, damned if you don't

I’ve been using LXD for years across two servers: one local and one production, which is remote. For a long time, I had a backup script —a simple script that ran commands like lxc delete ct, followed by lxc copy remote:ct ct—effectively giving me a local copy of the container (ct).

My containers use static IPs because they’re behind proxies with nat: true, enabling them to listen on the remote server’s external IP address.

I’m not sure when this setup broke, but now it doesn’t work at all. Regrettably, I hadn’t been monitoring the existence of backup containers for a while. Recently, I discovered that LXD prevents me from copying containers if the networks on lxdbr0 are configured differently. To address this, I made an effort to reconfigure local containers to operate on the same subnet. However, when I now attempt to use lxc copy remote:ct local, I encounter the following error:

Error: Failed instance creation: Failed creating instance record: Failed initialising instance: Invalid devices: Device validation failed for “eth0”: Cannot specify “ipv6.address” when DHCP or “ipv6.dhcp.stateful” are disabled (unless using security.ipv6_filtering) on network “lxdbr0”

This configuration used to work years ago, but it no longer does. The core issue is that I need to use DHCP-only containers to facilitate copying them between machines, yet I also require containers with static IPs for port forwarding from the outside to the inside.

Furthermore, due to space limitations, I can’t perform lxc export on the remote server — there isn’t enough space on the system volume for export operations.

I’ve also been considering the recent Canonical/Incus debacle and wondering if switching to Incus might be beneficial. However, I’m skeptical that Incus will resolve this issue, and I’m hesitant to make any changes without current backups.

Does anyone have suggestions on how to achieve both objectives — automatic container (actually, container’s snapshot) copying and port mapping?

I have not tried it, but I know you can use dd and ssh to pipe data to remote server. If you can get lxc export to write to standard out then you could use the same technique.

This is just my first thought. My second thought is that migrating to Incus would be a good idea.

No, it does not work that way. lxc export creates whole tar and only then sends it to stdout. Thus running lxc export remote:ct - -q makes no sense – it will generate whole tar consuming / disk space and only then send it.

1 Like

Another thought I just had. How about setting up another server and adding it as a remote. Then copy the container from the original server to the new one.

This is how I do my backups.

No, another server won’t help – lxc refuses to copy because of static settings of source container.

Does the discussion in this thread help you with any ideas?