@jimmy9008 said in Vagrant/DHCP problem:
So, we have a DevOps colleague who has setup automation with Vagrant to one of our Hyper-V hosts. I am not familiar Vagrant at all, but the allows his code to build VMs on one of our Hyper-V hosts. I am trying to rule out DHCP being the issue.
Most of the time the VMs are made successfully and get a DHCP address. Every once in a while, one of the automated VM fail to get a DHCP IP (well, they actually don't). (from being generated new)
We setup Wireshark to capture traffic for one of these failed events. When this fails I can see:
1 - the broadcast from the mac of the VM asking for any DHCP servers on the subnet
2 - the DHCP offer with the MAC of the client and the IP available
3 - the actual DHCP request from the client MAC with the IP which is available from step 2
4 - the DHCP Ack from the DHCP server confirming allocation complete
I have checked the DHCP server and can see the record. Correct IP, MAC, and a machine name. Now, at this point I believe the entire flow has been successful. Now, this is where it goes wrong.
I connect to his VM in Hyper-V and login with the password he gave and type ipconfig /all
I get no IP, no subnet, but I do see DHCP = Yes, Gateway and DNS servers. I now type 'hostname', and the hostname is different to what is in DHCP!
What I suspect:
- Vagrant makes the machine, it boots, gets an IP and is written to DHCP
- At some point, the code written gets the VM to change its host name and the VM reboots
- The VM (with its new name) asks DHCP server for the same IP
- DHCP server refuses as the hostname does not match the IP in its records
- Vagrant VM is left in a stage having no IP
Does this sound reasonable? I assumed if this were the case though that the DHCP server would send a NACK or something refusing the IP renewal/request, but do not see the traffic in Wireshark.
If I restart the VM or do ipconfig /renew, it does get the correct IP, and DHCP updates with the new name of the machine.
This once in a while happens to his Linux VM and his Windows Server VM which are made via Vagrant, leading me to believe the issue is Vagrant.
The fact DHCP has a record of the IP, Name and MAC of the host before name change makes me think the issue is with Vagrant/his code rather than DHCP server.
You might be confused by the hostname without it being a problem.
Normally it's the DHCP client that tells the server it's hostname in the DHCPREQUEST package.
So the hostname is set in the OS during installation and it's communicated to the DHCP server. The DHCP server stores this information in it's lease table. The hostname and IP can then be communicated from the DHCP server to DNS as well.
But it's also possible for the DHCP client to change the OS hostname based on a hostname the DHCP server sends - usually when having static DHCP reservations.
It's however not a requirement for the dhcp client to sends its hostname to the dhcp server and it's not a requirement that the dhcp client changes the hostname based on the hostname the DHCP server provided either. These are options that can be enabled or not.
Whatever the setup is, you can have the hostname inside the VM and the hostname on DHCP/DNS be different without anything being wrong.
I think you're on the right track using wireshark to figure out what is happening. I would have a close look on the MAC addresses to see what VM is doing what.
I don't know Vagrant but I don't see any reason for the DHCP server to supply a hostname to the VM when Vagrant is perfectly capable of setting the VMs hostname itself.
I would have a look at the DHCP server settings. Are you for instance using static reservations and are you setting hostnames from the DHCP server?