Debian cloud-init VM template clone gets two DHCP IP addresses

[crazyelectron]

When creating a VM (using Clone from the GUI) it gets two DHCP-assigned IP addresses, one for `eth0` and one for an alias `enp0s18`.
The template is created from the latest Debian Cloud image (https://cloud.debian.org/images/cloud/bullseye/latest/#:~:text=debian-11-genericcloud-arm64.qcow2) to which I only added `qemu-guest-agent` using `virt-customize` and `virt-sysprep`. In the cloud-init parameters of the template created from that image I specify 'dhcp' for net0 in addition to the SSH key.

I use the following commands to create the template:

qm create $VMID --name $TEMPL_NAME --memory $MEM --net0 virtio,bridge=$NET_BRIDGE
qm importdisk $VMID $IMG_NAME $DISK_STOR
qm set $VMID --scsihw virtio-scsi-pci --scsi0 $DISK_STOR:vm-$VMID-disk-0
qm set $VMID --ide2 $DISK_STOR:cloudinit
qm set $VMID --boot c --bootdisk scsi0
qm set $VMID --serial0 socket --vga serial0
qm set $VMID --ipconfig0 ip=dhcp
qm set $VMID --cores $CPU_CORES
qm resize $VMID scsi0 $DISK_SIZE
qm template $VMID

How can I get rid of this second IP address in the cloned VM's?

 

[jummama]

I encountered this recently as well. With no network configuration in Cloud-Init in Proxmox, my VM was getting dhcp4 with ens18 as the device name. With a network configuration defined, it was renaming to eth0, but was also grabbing two DHCP addresses.

If the VM is rebooted after this, it then comes back up with a single DHCP address.

This behavior seems to be from the interfaces template Debian supplies.

This is the /etc/network/cloud-interfaces-template in the current Debian 11 image:

auto $INTERFACE
allow-hotplug $INTERFACE

iface $INTERFACE inet dhcp

I edited this file with virt-edit, changing dhcp to manual, and the resulting image no longer pulls 2 DHCP addresses. I suspect that something like this is occurring:

• udev configures the network device through ifupdown with the template, resulting in a DHCP address
• cloud-init renames the interface, and configures it from the cloud-init drive
• DHCP is run again on a "new" interface, resulting in a second address

Unfortunately, this first DHCP process seems to occur before cloud-init is even running, so even bootcmd is too late to patch this, and editing the image (or building your own) is the only option I can realistically think of here. Perhaps some further tinkering involving ifdown and ifup could undo this after it happens, but that feels hackier than I'm comfortable with.