'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match: macaddress: 52:54:00:de:bd:f6 set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called crazy3 and brought up fine with dhcp. However, instead I see:
$ 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: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
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
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments.
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by cloud.cfg. d/99-disable- network- config. cfg with the following:
macaddress: 52:54:00:de:bd:f6
set- name: ens3
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called crazy3 and brought up fine with dhcp. However, instead I see:
$ ip a UP,LOWER_ UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
1: lo: <LOOPBACK,
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: ens3: <BROADCAST,
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK, UP,LOWER_ UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 MULTICAST, UP,LOWER_ UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 ff:fede: bdf6/64 scope link
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
3: myiface3: <BROADCAST,
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments.