Greetings
I’ve done this before but I can’t remember what I did and in about 45 minutes of looking duckduck isn’t helping either!
I have a container xxxxxx , used the command
$lxc copy xxxxxx yyyyyyy
yyyyyy has the same IPv$ address as xxxxxxx but NOT the same IPv6 address.
How do I kick yyyyy in the pants to get a different IPv4 address?
(I’ve tried stopping and starting yyyyy, tried ifup down and up both with and without eth0 and so far no joy!)
TIA
Greetings
Was continuing to work on this and then tried this:
stopped each container (original and its copy (with now a different name)) then started both at once.
Operation a success! Each container has a different IPv4 address!!!
I had remembered that it was something simple but I haven’t been able to find any references to this technique.
So for hopefully someone else’s use - - - there it is!
When a container starts up, it will ask for a new IP address from the LXD DHCP server.
Each container should have a unique MAC address, which is randomly selected.
The LXD DHCP server can distinguish between containers if they have different MAC addresses.
$ lxc launch ubuntu:x c1
Creating c1
Starting c1
$ lxc list c1
+------+---------+----------------------+-----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+---------+----------------------+-----------------------------------------------+------------+-----------+
| c1 | RUNNING | 10.52.252.203 (eth0) | fd42:cba6:557e:1a5f:216:3eff:fe65:7a4b (eth0) | PERSISTENT | 0 |
+------+---------+----------------------+-----------------------------------------------+------------+-----------+
$ lxc copy c1 c2
$ lxc list
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| c1 | RUNNING | 10.52.252.203 (eth0) | fd42:cba6:557e:1a5f:216:3eff:fe65:7a4b (eth0) | PERSISTENT | 0 |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| c2 | STOPPED | | | PERSISTENT | 0 |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
$ lxc start c2
$ lxc list
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| c1 | RUNNING | 10.52.252.203 (eth0) | fd42:cba6:557e:1a5f:216:3eff:fe65:7a4b (eth0) | PERSISTENT | 0 |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| c2 | RUNNING | | fd42:cba6:557e:1a5f:216:3eff:feff:833f (eth0) | PERSISTENT | 0 |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
$ lxc list
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| c1 | RUNNING | 10.52.252.203 (eth0) | fd42:cba6:557e:1a5f:216:3eff:fe65:7a4b (eth0) | PERSISTENT | 0 |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
| c2 | RUNNING | 10.52.252.118 (eth0) | fd42:cba6:557e:1a5f:216:3eff:feff:833f (eth0) | PERSISTENT | 0 |
+----------------+---------+----------------------+-----------------------------------------------+------------+-----------+
So, how do you diagnose why two containers happen to get the same IP address? By comparing their MAC address.
$ lxc exec c1 – ip addr show dev eth0
14: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:65:7a:4b brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.52.252.203/24 brd 10.52.252.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd42:cba6:557e:1a5f:216:3eff:fe65:7a4b/64 scope global mngtmpaddr dynamic
valid_lft 3358sec preferred_lft 3358sec
inet6 fe80::216:3eff:fe65:7a4b/64 scope link
valid_lft forever preferred_lft forever
user@computer /home/user
$ lxc exec c2 – ip addr show dev eth0
16: eth0@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:ff:83:3f brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.52.252.118/24 brd 10.52.252.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd42:cba6:557e:1a5f:216:3eff:feff:833f/64 scope global mngtmpaddr dynamic
valid_lft 3346sec preferred_lft 3346sec
inet6 fe80::216:3eff:feff:833f/64 scope link
valid_lft forever preferred_lft forever
The two MAC addresses are different, and they share the first part 00:16:3e. The first part indicates that these are MAC addresses for XenSource (randomly generated MAC addresses for virtual servers). Read more at https://www.citrix.com/blogs/2011/08/26/the-mac-address-challenge-xendesktop-on-xenserver/
The chances for a collision (two containers that happen to get the same random MAC address) is around 1 in 10 trillion. Therefore, if you manage to get two containers with the same IP (because same MAC address), ask again here because it would be an interesting bug. Use a title like BUG: MAC Address collision in two containers.
Thank you for your technical response - - - useful clarification.
What was (and is) fascinating to me was that when I started the cloned container for the first time the two ipv4 addresses were the same. The ipv6 addresses were not, but they differed in only the last 2 quads.
I had not done an ifconfig on the originating container throughout the attempts to change the ipv4 address so I did one now - - and they do share the first 3 pairs but not the next 3 (as you suggested) of the MAC address.
What was (and is) confusing to me is why the dhcp server ‘did’ give the same ivp4 address.
I was able to affect the needed change so situation is good but am still confused as to why an automated tool would generate the same ivp4 address from 2 different MAC addresses.
If you run the LXD snap, then you can have a look at
/var/snap/lxd/common/lxd/ (for the DEB LXD package, it is elsewhere in /var/…).
In there, you can get a lot of info:
$ cat /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.hosts/c1
00:16:3e:1f:c9:a0,c1
$ cat /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.hosts/c2
00:16:3e:c8:72:b0,c2
Here it shows you what DNSMASQ (the one for LXD) thinks about the MAC Address of the containers.
In /var/snap/lxd/common/lxd/logs/ you can find the LXD logs, and also individual logs per container.
A real physical network interface has a proper, unique and defined MAC address. On the contrary, a virtual network interface (like those in containers) has a 00:16:3e:??:??:?? MAC address that is randomly generated when the container image is instantiated. It keeps the first part (00:16:3e) so that it is distinguishable from other interfaces.
For your case, if you want to delve deeper, you can have a look at the logs.
Interesting and fascinating - - - sorry - - - I’m thinking I can actually understand this yet at the same time I don’t understand.
There are 6 MAC addresses defined in /var/snap/lxd/common/lxd/networks/lxdbr0 yet I have 5 containers. Is the sixth one for lxdbr0 itself?
Spent a little time looking at files like your 2 examples and I get 5 MAC addresses and the ipv4 address that is linked with lxdbr0.
Thank you - - - interesting stuff!
I got these files,
$ sudo tree /var/snap/lxd/common/lxd/networks/lxdbr0
/var/snap/lxd/common/lxd/networks/lxdbr0
├── dnsmasq.hosts
│ ├── c1
│ ├── c2
│ └── mycontainer
├── dnsmasq.leases
├── dnsmasq.pid
└── dnsmasq.raw
1 directory, 6 files
The active DHCP leases can be found in
$ cat /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.leases
1514494933 00:16:3e:c2:e8:b9 10.52.252.170 c1 *
1514493578 00:16:3e:2a:03:5c 10.52.252.46 c2 *
1514494528 00:16:3e:54:53:ff 10.52.252.38 mycontainer *
duid 00:01:00:01:21:60:e3:34:00:e0:4c:50:a9:dc
The last line (duid) is some ID and not a MAC Address.
OK - - - a 14 character hexadecimal ID.
Thank you for your assistance and consideration.
Sorry for resurrecting a very old thread, but I just ended up with two containers having the same MAC addresses using a similar example, but with snapshots:
lxc launch ubuntu:x c1
lxc snapshot c1 test
lxc cp c1 c2
lxc restore c2 test
lxc start c2
Both containers c1 and c2 now have identical MAC addresses and identical /etc/hostname (c1). Is there a way to force generation of a fresh MAC addresses and fixing the hostname? The only workaround I found is to copy c2 again:
lxc stop c2
lxc mv c2 tmp
lxc cp tmp c2
lxc start c2
lxc rm tmp
But it is rather inconvenient to do this procedure every time after restoring the a snapshot with the copy.
This will clear the volatile MAC address, allowing a new one to be generated, and run the copy template on next start (which resets the host name).
lxc stop c2
lxc config set volatile.apply_template=copy
lxc config unset c2 volatile.eth0.hwaddr
lxc start c2
Thanks, that worked! However, not much shorter than copying / renaming the container. 
Does it mean that the volitile values like MAC address are saved in snapshot and are overwritten when restoring from snapshots?
True, although depending on the storage driver being used, the latter is a lot cheaper than the former. 
Correct, a snapshot is a readonly copy of the instance at the time it was taken, and is not modified when restoring.