[BUG] DNS issue where deprovisioning sets the hostname to localhost.localdomain
edwardsp opened this issue · 1 comments
Describe the bug: A clear and concise description of what the bug is.
Deprovisioning sets the hostname to localhost.localdomain
but it also sets the hostname for dhclient
to localhost.localdomain
. This can result in nslookup localhost
on the network resolving to another Virtual Machine in the starting state between the time where dhclient
is initially run and when the hostname is setup by walinuxagent.
Distro and WALinuxAgent details (please complete the following information):
- Distro and Version: [e.g. Ubuntu 16.04]
- WALinuxAgent version [e.g. 2.2.40, you can copy the output of
waagent --version
, more info here ]
CentOS 7.9 and Ubuntu. Although this will effect all distros if dhclient is run before the actual hostname is set.
Additional context
This breaks scripting that would rely on localhost
being correct.
You can reproduce this with the following steps:
- Create a new image after running
waagent -deprovision
. - On another VM on the VNET, run the command
watch nslookup localhost
(or run in a loop and pipe to a file) - Start a new VM on the VNET with the image that was created
- For a short period while the new VM starts up you will see
nslookup localhost
being resolved to the new VMs private IP address
Log file attached
Any /var/log/messages will show the hostname being set to localhost.localdomain
when the VM initially starts if it has been created after using waagent deprovision.
Assigning to provisioning, during deprovisioning we set dhcp hostname to localhost.localdomain. The bug described in this issue occurs after creating a new VM with the image and before provisioning updates the hostname.