networking comes up before hostname is set
Bug #1739516 reported by
Michael Hudson-Doyle
This bug affects 4 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Expired
|
Medium
|
Unassigned |
Bug Description
When boot with libvirt a disk image that has been installed with subiquity which has the workaround for bug 1737630 applied, i.e. networkd starts automatically, I cannot ping the VM by hostname from the host.
I think this is because the networking has come up before the hostname is set, so the hostname is not sent along with the DHCP request to libvirt's dnsmasq and so that dnsmasq cannot answer lookups for the hostname. If I run "netplan apply" on the vm, enough things are apparently restarted that DHCP happens again and I can ping the vm by hostname from the host.
I'm not completely sure I have diagnosed this correctly and certainly don't know how to fix it.
Changed in cloud-init: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
To post a comment you must log in.
This is true that hostname is not set before networking comes up.
I would like to fix this, but there are a couple things to consider
a.) network datasources
currently there are some datasources that run only after networking comes up. As it is right now it is "too late"to read the hostname from the network metadata service and then update the system hostname before dhcp would run.
b.) systemd-networkd's dhcp client seems to actually be listening for hostname getting set and updating its lease information on that event. we saw this in azure when we were removing the old 'bounce the network' code that served the purpose of publishing the
c.) relying on the guest to populate dns information via dhcp is kind of garbage anyway. as a "cloud" solution anyway.
d.) cloud-init allows setting hostname in user-data (in addition to meta-data).
the user-data provided by the user could be in a '#include' url, which might not be available until all networking is up. Thus, even if we moved network datasources to pull their information 'pre-network' (the way that the digital ocean md service does) we can't consume all the user-data at that point.
'd' might be a reasonable limitation. the other things are acheivable.