VMs get identical IPs

Question

I frequently run several Ubuntu Server instances in a VirtualBox VM for testing various things. I typically install Ubuntu once and then clone the VM as many times as I need to. I use Bridged Networking in VirtualBox, and get a dynamic IP from my router. VirtualBox has the ability to randomize the MAC address of the virtual NIC. With 16.04 this worked fine: Install + Clone + Randomize MAC = every instance gets its own unique IP.

This no longer works in 18.04. I don't understand why, but even when I change the MAC, all the clones always get the same IP address. (My router seems to think whichever instance booted last owns the IP.)

Furthermore, when I change the VMs to static IPs using netplan as follows ...

$ cat /etc/netplan/01-netcfg.yaml

network:
    version: 2
    renderer: networkd
    ethernets:
        enp0s3:
            dhcp4: no
            addresses: [192.168.1.28/24]
            gateway4: 192.168.1.1
            nameservers:
                addresses: [192.168.1.1]

... the NIC ends up with two IPs - the static address I assign, and the original dynamic IP, like so:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:dd:e5:ea brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.28/24 brd 192.168.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet 192.168.1.154/24 brd 192.168.1.255 scope global secondary dynamic enp0s3
       valid_lft 86383sec preferred_lft 86383sec
    inet6 fe80::a00:27ff:fedd:e5ea/64 scope link
       valid_lft forever preferred_lft forever

I've googled all over the place and can't figure this out. I'm guessing it may have something to do with cloud-init, but if so I can't figure out what to do about it.

Appreciate any help!

Answer 1

I've seen this plenty of times recently, so I'm for now just assuming you are struck by the same and provide it as an answer. If that is not your case at least it might help others.

Ingredients to the issue:

• clone a system after having it booted (should never be done IMHO)
• networkd

Now what happens is that on first boot systemd will generate /etc/machine-id and afterwards networkd will use that to make a client-id in its dhcp requests.

That will be the preferred unique ID to serve IPs and therefore all machines cloned with the same /etc/machine-id will conflict.

There is more than that which is done on first boot/init which is the reasons you should IMHO start with clean cloud images plus a deployment procedues. But for now, please make sure /etc/machine-id gets deleted. It will generate a new one on boot and the systems can be differentiated by the DHCP server.