So I run a CentOS VM as my NetBoot server. It uses the fantastic BSDPy NetBoot server by Pepijn Bruienne.
This past week I’ve been having a terrible time getting it to work in the lab. We have our servers on one VLAN and our clients on another VLAN. Pretty standard stuff, we simply add the IP address of the NetBoot server VM as an IP-Helper in the config of the switch/router and then the BSDP data passes across the vlans. I was able to confirm this was occurring from the bsdp server logs. I was also able to confirm that tftp was working by connecting to the server from the client and “GET”ing the booter file. I could see my NBI in startup disk pref pane. But no matter what my clients would not NetBoot. I could not see the NetBoot image in the startup manager either (startup and hold option key to see boot options) that was weird but it didn’t bother me too much because startupdisk.prefpane was working which is generally the litmus test for NetBoot.
So after a week of hacking on our networking team. It turns out it was in fact, not our networking teams fault. They had configured everything correctly (not that there is much to do really).
It turns out that our virtualisation team used some kind of orchestration to create my VM from the VHD that I gave them. During this orchestration(automation) process to create the VM on the Hyper-V host, somehow an advanced settting called DHCP Guard was enabled on the VM. This prevents the VM from responding to DHCP requests at a Hyper Visor level, and of course prevents the client from NetBooting.
Pro-tip: Make sure this setting is NOT enabled before you harass your network engineers, or you’ll end up owing then a case of beer