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.
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.
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.
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.
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.
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.