Unable to copy container due to already defined IP address

When trying to copy a container this no longer works. I get the following error:

root@dev ~ # lxc copy kasdev4 kasdev6
Error: Failed creating instance record: Failed initialising instance: Failed to load device to add “eth0”: IP address “10.0.10.4” already defined on another NIC

As far as I can remember this worked previously.

The work-around is removing all network settings and the copy it. Afterwards restore the network setting and also set the on the new container.

I have a script that sets all network related things. But I first need to be able to copy the container before I can run it.

Please can you show output of lxc config show kasdev4?

Sounds like a similar class of issue to

That is not a valid command

lxc config show kasdev4?

root@dev ~ # lxc config show kasdev4
architecture: x86_64
config:
image.description: EABO’s OpenErp 5/7 container
image.release: precise
image.version: “12.04”
volatile.base_image: c4c141925122b02d707b5035bbbf05568c7a22afa1f03f26a00d84d6f94fa808
volatile.eth0.host_name: vethd12c732b
volatile.eth0.hwaddr: 00:16:3e:35:3e:ee
volatile.idmap.base: “0”
volatile.idmap.current: ‘[]’
volatile.idmap.next: ‘[]’
volatile.last_state.idmap: ‘[]’
volatile.last_state.power: RUNNING
volatile.uuid: 30c63c5b-8f54-4f8b-a0c1-6c631664981f
devices:
eth0:
ipv4.address: 10.0.10.4
name: eth0
nictype: bridged
parent: lxdbr0
type: nic
filestore:
path: /opt/openerp7/oe/server/openerp/filestore
source: /mnt/filestore/
type: disk
fonts:
path: /usr/local/share/fonts
source: /usr/local/share/fonts
type: disk
monit-proxy:
connect: tcp:127.0.0.1:2812
listen: tcp:0.0.0.0:41094
type: proxy
root:
path: /
pool: tank
type: disk
ephemeral: false
profiles:

  • default
    stateful: false
    description: “”

You can do this:

lxc copy kasdev4 kasdev6 -d eth0,ipv4.address=

I had a similar problem with cloning backups and it turned out to be that the hardware address was also being cloned. Which I guess is fair for a backup/restore situation.

I resolved the problem by setting the hardware address on the restored instance to e.g. volatile.eth0.hwaddr = “”.

That worked for me… Though these days I prefer cloud-init for instance creation as its faster than having to copy around large images.

Yes that is working but it should not be needed. It should just be as simple as: lxc copy kasdev4 kasdev6

Now we need to remember to remove the IP config every time we need to copy a container…

Why shouldn’t it be needed?

Previously there was a lack of validation which allowed multiple NICs to be configured with the same IP at the same time, which then caused conflicts in the DHCP static allocation.

Why does LXC not just remove the IP if there is an conflict when copying? And show an message that it removed the IP.

It could potentially do that I suppose, although we try and avoid silently modifying config that was explicitly set by the user when something is copied (unlike the volatile.* keys).

By running this command you are effectively telling LXD to do that though (which it would have been required sooner had the validation bug I mentioned earlier not been present):

lxc copy kasdev4 kasdev6 -d eth0,ipv4.address=

We’ve been tightening up the device validation in the last few releases to prevent configurations that will produce unwanted results.

You can open an issue here Issues · lxc/lxd · GitHub if you like to suggest a change of behaviour though.

Okay thanks

1 Like

You only need to blank the hwaddr if your cloning via a import. If you do a lxc rename its done automatically. The issue here is your using a backup.

This is an IP config issue, not to do with MAC address, which is set via volatile key, and is regenerated when copying (as opposed to moving) as it is not explicitly set by the user’s config.

1 Like

If the container has a static IP then the same problem would occur.

But if the hwaddr is the non-unique then DHCP will just continue the lease the same IP to as many instances that have that hwaddr.?

I’ve had that issue with using a backup image to clone instances… Whilst the lxc export allows you to change the instance name on the restore it doesn’t reset the hwaddr.

Yep that is what we are discussing. I’ve proposed that we add the -d approach to lxc import and lxc restore in https://github.com/lxc/lxd/issues/10114