Lxc import fails due to lxdbr0 having different subnet

I have a container where i set manually ip address with the following commands:

lxc network attach lxdbr0 vaultwarden eth0 eth0
lxc config device set vaultwarden eth0 ipv4.address

Container was exported to a .zst file.

On another server, i did lxc import and it failed with the following error:

[me@hp]$ lxc import  vaultwarden_backup_2022-03-22.zst
Error: Failed importing backup: Failed creating instance record: Failed initialising instance: Invalid devices: Device validation failed for "eth0": Device IP address "" not within network "lxdbr0" subnet

There are two options which are not the best, but possible:

  1. change the original image, remove eth0 device, rexport the container and then import the new image without fixed ip
  2. change the network subnet for lxdbr0 on a new server, import container, remove device from the new container, then set the subnet on lxdbr0 to what it needs to be

Is there a way to overcome this problem just by using `lxc import?


If you open the vaultwarden_backup_2022-03-22.zst file you should be see a backup.yaml file in there and you can edit that to remove the problematic config and then import.

Also if you could can you log an issue over at Issues · lxc/lxd · GitHub as I expect this is similar to an issue that we resolved in the past where restoring a snapshot who’s config had become invalid since it was taken was being prevented.

We worked around it by allowing the restore to occur (so ignoring the device validation errors at instance create time) but then it would still prevent the instance from being started. But by that point it would then be possible to fix the config via the lxc config edit <instance> command.

I expect we need to do something similar in this case.

I think the problem here is you have static IP/subnets in your instance… Unless you configure your lxdbr0 to have the same subnet its going to break.

Yes that has been established already. The question though is how to import an instance from another host (that was on another lxdbr0 configured with a different subnet) onto a new host without manually resorting to modifying the config inside the backup tarball. I’ve proposed some options in the github issue above.