Comment 5 for bug 1775566

I identified that systems I spawn as q35 right away work.
Only those where the initial cloud init runs as i440fx and then I change them to q35 are affected.

I compared configurations and eventually had even my converted instance running, to the point that it was hard to tell why.

I found that the root cause is this difference in config:
BAD:
network:
    version: 2
    ethernets:
        enp3:
            dhcp4: true
            match:
                macaddress: 52:54:00:ba:23:d6
            set-name: enp3

GOOD:
network:
    version: 2
    ethernets:
        enp1s0:
            dhcp4: true
            match:
                macaddress: 52:54:00:ba:23:d6
            set-name: enp1s0

Now yes, the device is enp1s0 at the moment:
$ dmesg | grep enp
[ 0.898280] virtio_net virtio0 enp1s0: renamed from eth0

But according to the netplan spec this should not matter right?
It has a match so the upper name is just an id.
And set-name can be whatever we want.

Bad case networkd files:
$ tail /run/systemd/network/10-netplan-enp3.*
==> /run/systemd/network/10-netplan-enp3.link <==
[Match]
MACAddress=52:54:00:ba:23:d6

[Link]
Name=enp3
WakeOnLan=off

==> /run/systemd/network/10-netplan-enp3.network <==
[Match]
MACAddress=52:54:00:ba:23:d6
Name=enp3

[Network]
DHCP=ipv4

[DHCP]
UseMTU=true
RouteMetric=100

Good case networkd files:
$ tail /run/systemd/network/10-netplan-enp1s0.*
==> /run/systemd/network/10-netplan-enp1s0.link <==
[Match]
MACAddress=52:54:00:ba:23:d6

[Link]
Name=enp1s0
WakeOnLan=off

==> /run/systemd/network/10-netplan-enp1s0.network <==
[Match]
MACAddress=52:54:00:ba:23:d6
Name=enp1s0

[Network]
DHCP=ipv4

[DHCP]
UseMTU=true
RouteMetric=100

Cloud init generating them right the first time makes it work.
If we go in with the old names it fails, while according to the man page it should not.
So is it an issue in netplan or more in networkd I'm not sure - leaving it to the owners of the packages.