Re: Bug#867594: cloud.debian.org: vms lease the same dhcp ipv4 address in kvm/libvirt
> official debian/stretch64 v9.0.0 vagrant box has wrong dhcp configuration.
>
> As far as I understand, Stretch switched to using DHCP Client Identifier (DUID)
> by default, which is generated from /etc/machine-ip, which should be different
> due to installation procedure. As Vagrant boxes have no regular installation
> procedure, machine_id is embedded into the box, and so, is the same for
> all vms and Client Identifier also. As libvirt uses that DUID for assigning
> IPv4 addresses, all stretch vms get the same initial IP - new one
> makes unusable all previously started.
>
> As DHCP client has an option to use MAC for DUID (or instead DUID?), I propose
> to update network config inside vagrant box to use MAC.
Thank you for your interest for the Vagrant boxes. I did some research
on on the libvirt boxes, and it seems the problem is not that Stretch
switched to use DHCP Client Identifier (DUID), but rather than the
libvirt vagrant boxes are built using vmdebootstrap, which is using
systemd-networkd by default, which is using the machine-id as a DUID as
you rightly pointed out.
man networkd.conf(5) describes the use of /etc/machine-id you're mentioning
I would consider this as a bug in vmdeboostrap since vmdeboostrap is
silently diverging from the defaults one would expect from a default
debian installation, where ifup and the isc dhcp client are used.
As a work around we could possibly generate the machine-id on first
boot, as it is less diverging than changing the default DUID that
systemd-networkd uses.
The recommended aproach from systemd to generate the /etc/machine-id
file would be to use systemd-firstboot, but systemd-firstboot is not
shipped by debian (#844528)
A workaround for the workaround would be then to delete /etc/machine-id
as the end of the virtual machine generation, and then create at first
boot in /etc/rc.local via something similar to:
-f /etc/machine-id || systemd-machine-id-setup
Reply to: