1

Hey all! I’m begining a transition from vSphere to Hyper-V and am running into issues with my test host, specifically with PXE booting from the VMs. I’ve searched numerous forums and found a LOT of others having similar issues, though unfortunately none of the suggested fixes for any of them seem to be working here.

Normally there’d be more redundancy at each layer, but for now I’ve stripped things down to the minimum until I get this sorted out. Currently there’s 1 host server (Windows Server 2025 sta), with adapters dedicated for management (so management is not enabled on the vswitch), storage, migration and VM guest traffic. The vswitch with the VM traffic adapter is connected to an Aruba AOS-CX 8320, normally trunked for several VLANs. That same physical switch is also connected to our vSphere host that runs our DHCP and WDS servers (running in separate VMs). IP helpers are set up on the needed VLANs on the switch for DHCP and WDS, with no PXE options configured in the relevant DHCP scopes. Physical computers as well as our VMware-hosted virtual machines are all able to PXE boot with this setup with no issues.

In every scenario I’ve tested, the result is the same - when I attempt to PXE-boot a VM running in Hyper-v, it times out while waiting for an address and eventually errors with no response. I’ve run wireshark looking at the interface on the host’s end, the switch’s, the WDS server’s as well as the DHCP server’s ends… in the case of the switch, WDS and DHCP servers, the discovery requests are seen as are the offers from both DHCP and WDS, however on the Hyper-V host it only sees the discovery requests coming from the VM… none of the offers appear from the WDS or DHCP server. Once the VM gives up and eventually boots the guest OS, then the offer/ack requests proceed and it pulls an IP address without issue, pulling from the expected DHCP scope with each VLAN I test the VM in (tried multiple just to be sure the VLAN trunking was working between the physical switch, vswitch and VM adapter)… it only struggles during the PXE attempts.

I have tried removing the IP helpers and instead adding the DHCP options (60, 66, 67) and configuring them accordingly, as well as even trying a combination of them. In all cases, I can PXE boot successfully from physical machines and vmware VMs, just not from Hyper-V.

I have tried switching the virtual machine’s VLAN to the same as our DHCP and WDS servers, though there was no change. I have also tried switching the physical switch port to an access port on a single VLAN, and removing the VLAN specification on the virtual machine - no change. Plugging a physical laptop into that switch port, it’s able to PXE boot on the expected VLAN with no issue.

While I wouldn’t have expected it to make a difference, just to rule it out I tried setting a static MAC on the virtual machine rather than the dynamic one - no change. In both cases, I verified in the switch’s MAC address table that it was mapping the correct physical port that the Hyper-V vswitch interface is plugged into for each of the VM’s MACs that I tried. Because the DHCP offers were being seen on the switch’s end but not on the host, I had wondered if perhaps it was having trouble getting back to the Hyper-V host vswitch, but again, DHCP works fine after the OS boots.

I should note that my attempts have mainly been from Gen 2 VMs. I did try creating a Gen 1 with a legacy network adapter, but it also wound up being unable to PXE boot, so I didn’t spend much time troubleshooting that one.

It really does seem to be something specific to PXE (beyond just the IP helpers and/or dhcp options), and also specific to just hyper-v, as I can’t reproduce the trouble on any other physical machine or virtual machine in our vsphere environment, even when using the same VLANs and even the same physical switch port. Sadly I can’t pinpoint it though.

Has anyone come across these issues that can recommend a different fix than what I’ve already tried?

Thank you!

4 Spice ups
2

A couple of things to try (if you’ve not already).

Disable Secure boot in the VM settings (if you need this, that may be an issue, however, if you use GPT disk partitions and install an OS compatible with secure boot, you can often add it later)

Under network adapter, advanced features, ensure none of these are getting in the way.

3

You’ve done very thorough testing, and as a non pxe boot/dhcp works fine it does indicate it is specific to pxe. It;s strange as the dhcp offer part should work - i.e. the VM get an IP but no pxe server host info.

Can you clarify what his means and how it was verified:

did you run wireshark on the hyper-v host?
and the dhcp offer is never seen coming out of the switch and into the nic attached to the hyper-v switch for vms? But it is seen when ot a pxe boot?

Whilst more work, it might be worth a test using win10/11 as the host of the vm to see if the issue is specific to server/server2025.
Can you use a win10/11 PC with hyper-v role connected to the required vlan and then try booting a pxe-enabled VM ?

4

Thank you for the suggestion! Unfortunately, it behaves the same way whether secure boot is enabled on the VM or not. All advanced network features for the VM have been disabled… sadly no luck.

5

Correct, I ran wireshark on the Hyper-V host, monitoring the network interface used in the virtual switch that connects back to the physical switch for VM traffic. The DHCP discovery queries from the VM during the PXE boot process appeared, as they did on the physical switch and DHCP/WDS servers, however wireshark on the hyper-v host did not see the offer or acknowledgements that were being seen on the physical switch and beyond… not until the VM’s PXE boot process timed out and the OS booted, at which point the hyper-v host did see the DHCP offer and the VM did successfully pull an address.

Thanks for the suggestion about testing a different host OS… I’ll throw a suitable NIC in a spare box and get it set up with Win10 and hyper-v at some point today as time permits to try out on that same switch port and see if I can get a VM to PXE boot from that with a similar configuration.

6

Trying another host OS was going to be my suggestion as well. Server 2019 or 2016 but Win10/11 is an even better idea.

While writing this it also occurred to me that you could try different host hardware.

Are all the adapters in the host the same? If you have a couple of different chipsets you could swap VM guest traffic with storage for example, or swap with the management adapter.
But trying an entirely different host would help this as well.

If it works with Windows 10/100 you can’t be sure it was the OS or the different hardware.

7

Thanks! I was able to work on it more today and first tested different hardware running Windows 10. With the vswitch adapter connected to the same physical switch and port, configured the same as it had been with my 2025 host, I was able to PXE boot successfully from a hyper-v VM.

After the success with that test, I went ahead and rebuilt the original host server using Server 2022. Configured identically to how I had it before as far as adapter and vswitch configurations, etc, I again was able to successfully PXE boot from a VM.

So it does seem to be an issue specific to server 2025 in my case, as it’s the only variable I can change that makes a difference.

8

2025 has a few known issues with networking (like W11 24H2) and others have reported issues with PXE booting VMs.

Microsoft is aware of this and some of the options supplied are workarounds, if they’re not working for you, unless you have an explicit need for 2025, I’d stick with 2022.

9

It may be, but some other posts on this issue (that I found googling) suggested deleting and recreating the vswitch resolved it. So it may just be some vswitch error also.
It is strange that it fails on pxe ONLY - It must be something in the request/response that hyper-v then seems to ignore.

10

Just to rule it out, I wound up reinstalling 2025 on that host yesterday and once reconfigured, ran into the same issues when PXE booting from the VM. Deleting the vswitch and recreating unfortunately had no effect. I installed 2022 on it again today, and PXE booting from VMs is working fine.

11

Wildly guessing here, but, 2025 requires ssl , MS force disabled http transfers, now that is ok, except for a second thing, TCP transfer for network boot doesn’t happen at the OS driver level, you don’t have an OS yet, so it happens at the UEFI driver level, that part is super primitive, originally that would have been firmware on a network card that supports network boot, now it is a wedge driver in hyper-v emulating a UEFI device module, supporting an emulated NIC that is also a forwarding interface to the host NIC…there is a lotta ugly here..not the least of which is UEFI network drivers didn’t originally do SSL, that is above the transport layer.

So…some part of hyper-v needs a tiny update to handle this little detail that MS foistered on us all of a sudden…

(Wild guess #2 - the host interface may be intercepting the ssl handshake, in which case the VM will never even see it)