7

I created a new nat network with dhcp enable through GUI on my VirtualBox 6.0 and connected 2 Guest VM's to it but keeps assigning the same IP to both VM's even if they are running at the same time.

  • Host: Ubuntu Desktop 18.04.
  • Guest A: Ubuntu Server 18.04. 08:00:27:33:ac:c6
  • Guest B: Ubuntu Server 18.04. 08:00:27:b9:41:77 (cloned from Guest A)

I checked the NatNetwork-Dhcpd.leases file that VirtualBox generates after starting the VM's the first time and saw that leases for both VM's appears as "acked" but got the same IP even though they have different MAC addresses.

<?xml version="1.0"?> <Leases version="1.0"> <Lease mac="08:00:27:b9:41:77" id="ffe2343f3e00020000ab117f957fa5c66cfffd" network="0.0.0.0" state="acked"> <Address value="10.0.2.4"/> <Time issued="1565568632" expiration="1200"/> </Lease> <Lease mac="08:00:27:33:ac:c6" network="0.0.0.0" state="acked"> <Address value="10.0.2.4"/> <Time issued="1565568546" expiration="1200"/> </Lease> </Leases>

I have also noticed that if I turn off Guest A and the turn it on again then the NatNetwork-Dhcpd.leases removes the id attribute to the lease section of Guest B and adds it to the lease section of Guest A with the exact same value modifying the file as follows:

<?xml version="1.0"?> <Leases version="1.0"> <Lease mac="08:00:27:b9:41:77" network="0.0.0.0" state="acked"> <Address value="10.0.2.4"/> <Time issued="1565568632" expiration="1200"/> </Lease> <Lease mac="08:00:27:33:ac:c6" id="ffe2343f3e00020000ab117f957fa5c66cfffd" network="0.0.0.0" state="acked"> <Address value="10.0.2.4"/> <Time issued="1565576544" expiration="1200"/> </Lease> </Leases>

My VirtualBox nat network is as follows:

<NetserviceRegistry> <DHCPServers> <DHCPServer networkName="HostInterfaceNetworking-vboxnet0" IPAddress="192.168.56.100" networkMask="255.255.255.0" lowerIP="192.168.56.101" upperIP="192.168.56.254" enabled="1"/> <DHCPServer networkName="NatNetwork" IPAddress="10.0.2.3" networkMask="255.255.255.0" lowerIP="10.0.2.4" upperIP="10.0.2.254" enabled="1"> <Options> <Option name="3" value="10.0.2.1"/> <Option name="6" value="10.0.2.1"/> </Options> </DHCPServer> </DHCPServers> <NATNetworks> <NATNetwork networkName="NatNetwork" network="10.0.2.0/24" ipv6="0" ipv6prefix="fd17:625c:f037:2::/64" advertiseDefaultIPv6Route="0" needDhcp="1" enabled="1"> <Mappings> <Loopback4 address="127.0.0.1" offset="2"/> </Mappings> </NATNetwork> </NATNetworks> </NetserviceRegistry>

Any help would be really appreciated.

Improve this question

2 Answers 2

Reset to default
6

After some more research + trial & error I find out that

The cause of the problem is that the built-in network config of Ubuntu 18.04 no longer uses the NIC Mac address as the default id for DHCP requests. (anneb, 2018, para. 1).

and also that

Mos DHCP clients, including dhclient, supply a client-ID field of type '01' (MAC-based). Another common type is '00' (domain name). However, by default, systemd-networkd supplies an "opaque" client-ID that was generated from the contents of /etc/machine-id.

According to the DHCP protocol, leases are chosen by client ID first (as long as the client supplies a "client ID" option, which may or may not be MAC-based), then by the MAC address only if the client didn't send an ID. (grawity, 2018, para. 4-5).

so I generated a new /etc/machine-id file in Guest B the way hvd (2017, n.p.). suggested:

  1. Verifying if /var/lib/dbus/machine-id was a symlink to /etc/machine-id

    $ sudo ls -l /var/lib/dbus/machine-id lrwxrwxrwx 1 root root 15 Aug 1 17:18 /var/lib/dbus/machine-id -> /etc/machine-id

  2. Deleting /etc/machine-id

    sudo rm -f /etc/machine-id

  3. Regenerating /etc/machine-id

    sudo dbus-uuidgen --ensure=/etc/machine-id

  4. Reboot the VM

    sudo init 6

  5. Login and verify new IP address is assigned to Guest B

    $ ip addr show enp0s3 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:b9:41:77 brd ff:ff:ff:ff:ff:ff inet 10.0.2.5/24 brd 10.0.2.255 scope global dynamic enp0s3 valid_lft 1070sec preferred_lft 1070sec inet6 fe80::a00:27ff:feb9:4177/64 scope link valid_lft forever preferred_lft forever

Improve this answer
1

I had similar problem where I had a base-machine (Ubuntu 18.04). It's basically a clean install with a user-account for me. I never run this machine but clone new machines from it. But all clones got the same IP even though I gave them new MAC. But after reading your post and fiddling a little I solved it like this on the base-machine:

  1. Remove /etc/machine-id and /var/lib/dbus/machine-id.
  2. Create an empty /etc/machine-id.
  3. Give /etc/machine-id proper permissions (this does not seem to be strictly necessary but that's how it was initially).
  4. Shutdown the machine and never start it again or you will have to redo the steps above!

Or in code:

sudo rm /etc/machine-id /var/lib/dbus/machine-id
sudo touch /etc/machine-id
sudo chmod 444 /etc/machine-id
sudo shutdown -h now

Now the base-machine can safely be cloned, and each new machine will generate its own unique machine-id on first boot.

The new /etc/machine-id will be automatically generated by systemd-machine-id-setup on boot if it is read-only and not initialized.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .