none
Hyper-V build 1703 generation 2 PXE has faulty ARP implementation

    Pertanyaan

  • Since build 1703 came out for Windows 10 Enterprise x64, with Hyper-v enabled, the ARP protocol does not work correctly in a Gen2 vm during a PXE boot. The result is that the DHCP protocol does not work in a gen2 vm, and thus, pxe booting is broken in a gen2 vm on the 1703 build.

    Host and guest are on subnet: 10.1.29.x /24
    DHCP server IP: 10.1.1.3
    PXE server IP: 10.1.1.3

    Here is correct ARP behavior, on a gen1 vm, notice arp for default gateway mac address, and subsequent successful DHCP, then successful download from the WDS server at 10.1.1.3.

    gen1-vmguest-1703host-ARP-correct

    Here is the faulty arp behavior as found in a Gen2 vm on the same host as above. Notice the ARP protocol trying to get the mac address of a remote subnet IP. Anyone that understands the ARP protocol recognizes immediately that this can never work.

    gen2-vmguest-1703host-ARP-failure

    Somewhere during the 1703 dev cycle this ARP regression was introduced. This needs to be investigated by the developers as there is no way to "configure" how hyper-v's gen2 embedded PXE code implements the ARP protocol.

    Please don't comment regarding "how to pxe boot in hyper-v" this PXE infrastructure is perfect. UEFI and BIOS based physical PCs on the 10.1.29.x subnet can PXE boot just fine from 10.1.1.3. Additionally, reverting the host hyper-v OS back to 1607 build, gen2 vms can successfully PXE boot. The ARP traffic change is the smoking gun for this regression.

    This ARP bug is only present in build 1703, with a generation 2 vm.

    Hope this is useful to help get this critical regression bug fixed.

    -Ben

    Jumat, 23 Juni 2017 19.24

Semua Balasan

  • Hi peacepenguin,

    Thanks for sharing the information with us. We are trying to reproduce the environment, if we get any result, we'll feedback as soon as possible.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Senin, 26 Juni 2017 01.26
    Moderator
  • Hi peacepenguin,

    After some test and research, seems you are right, we will try to report this behavior to our Product Team for further confirmation. We totally understand the inconvenience this issue has brought to you, your kind understanding is appreciated. We will keep pushing and tracking the process.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Senin, 26 Juni 2017 09.57
    Moderator
  • Hi Anne,

    Any updates on this issue?

    Also can I ask another question. Does the Gen 2 UEFI framework support DHCP services for Network Unlock at boot?

    Senin, 17 Juli 2017 22.30
  • Any further updates? 

    I just ran into this bug myself trying to PXE boot a new VM after upgrading the host machine to Win10 1703.

    Can confirm that physical computers can still PXE with UEFI on my network.

    Selasa, 01 Agustus 2017 05.40
  • I'm also having the same issue. I can PXE boot everywhere else in my environment, except on a Windows 10 1703 Hyper-V VM. Packet traces show the same as Ben has posted. ARP requests for the IP address of the PXE server (located in a different subnet), rather than the default gateway.
    Senin, 07 Agustus 2017 20.01
  • Hi peacepenguin,

     

    This issue has been resolved as of build 16230. Newer builds are available as part of the Windows Insider Program that include this fix.

     

    Thanks,

    SteVen

    Kamis, 24 Agustus 2017 20.55
  • Hello SteVen,

    we have Windows 10 1709 (16299) fresh installation with VM Gen2 config version 8.2, and cant still PXE boot.
    If I create Gen1 VM...PXE boot works.

    Please can You confirm, or anybody, if its truly resolved?

    Thanks,

    Lubos

    Jumat, 01 Desember 2017 23.18
  • I can confirm this bug was never resolved - typical Microsoft sticking their heads in thh sand and ignoring users - they just want to ignore us until the next version comes out crossing their fingers that "someone" resolved the issue.  As someone that has worked on the support side of Microsoft i can honesty say, they dont care in the slightest about you mate.... sorry it sucks but hey who are you?  just a consumer who paid for their product.  You don't count unless your a business.

    • Diedit oleh kroix0078 Senin, 26 Februari 2018 07.48
    Senin, 26 Februari 2018 07.47
  • This is still broken, what a joke.
    Rabu, 18 April 2018 15.06
  • 1803 and I get the same result as before, it is still not working with gen2 vm's.
    Rabu, 16 Mei 2018 10.09
  • I have run into a similar problem, but I'm not sure it is identical since my WDS and DHCP servers are on the same subnet.  The error I get with Gen 2 VMs is:

    1. Network Adapter (00155D834F2C)           There was a TFTP error.
    2. SCSI Disk (0,0)    No UEFI-compatible file system was found.

    But, a Gen 1 VM boots just fine.  I'm using Windows Server 2016 for the Hyper-V host, and both my WDS server and DHCP server are also Server 2016 VMs. The client VM is Windows 10 1803.

    I'm investigating this and will provide details about what I find.

    -Greg



    Jumat, 25 Mei 2018 17.59
  • Same issues with gen 2 VMs. I am able to PXE boot using a Gen 1 VM no problem. Gen 2 fails at DHCP negotiation. I have physical PCs that PXE boot no problem, both BIOS and UEFI. 

    Workaround for me is to boot from the ISO generated by MDT. A pain since I have to move the ISO any time I update the deployment share, but at least I can continue using my VM to make reference images. 

    Kamis, 14 Juni 2018 20.27
  • We've been having the same issue after creating a new WDS server. Our issue was a missing file. The below steps are the solution we implemented and we've been able to boot Gen2 VMs with no further issues.

    1. On the WDS server navigate to C:\RemoteInstall\Boot\x64. 
    2. Verify that the file wdsmgfw.efi is in the folder. 
    3. If the file is missing copy it from C:\windows\system32\reminst\boot\x64. 

    Rabu, 27 Juni 2018 17.00
  • We've been having the same issue after creating a new WDS server. Our issue was a missing file. The below steps are the solution we implemented and we've been able to boot Gen2 VMs with no further issues.

    1. On the WDS server navigate to C:\RemoteInstall\Boot\x64. 
    2. Verify that the file wdsmgfw.efi is in the folder. 
    3. If the file is missing copy it from C:\windows\system32\reminst\boot\x64. 

    This solved my issue with Server 2016 MDT, WDS and DHCP in a Gen2 VM and a Gen2 VM for PXE boot. Shame on M$ that this issue persist more than a year.

    Thank you a lot for sharing the solution with us.

    Rabu, 04 Juli 2018 16.34
  • Having the same issue - PXE Server shows 7E4E62EA-C8F4-4B3A-A492-65BFA44B454F: found optional advertisement
    Physical machines can boot fine.
    I've tried the WDSMGFW.efi file fix and even restarted WDS after with no success.


    nick

    Jumat, 13 Juli 2018 19.16
  • I just experienced the issue with 1703.

    I upgraded straight to 1803 and still had the issue.  Once I uninstalled my virtual switch and created a new one, it worked fine.

    Try recreating your virtual switch.


    nick

    Jumat, 20 Juli 2018 02.01
  • We've been having the same issue after creating a new WDS server. Our issue was a missing file. The below steps are the solution we implemented and we've been able to boot Gen2 VMs with no further issues.

    1. On the WDS server navigate to C:\RemoteInstall\Boot\x64. 
    2. Verify that the file wdsmgfw.efi is in the folder. 
    3. If the file is missing copy it from C:\windows\system32\reminst\boot\x64. 

    This solved my issue with Server 2016 MDT, WDS and DHCP in a Gen2 VM and a Gen2 VM for PXE boot. Shame on M$ that this issue persist more than a year.

    Thank you a lot for sharing the solution with us.

    This fixed my issue booting a Gen2 VM into PXE. Thank-you!

    Minggu, 05 Agustus 2018 18.26
  • We've been having the same issue after creating a new WDS server. Our issue was a missing file. The below steps are the solution we implemented and we've been able to boot Gen2 VMs with no further issues.

    1. On the WDS server navigate to C:\RemoteInstall\Boot\x64. 
    2. Verify that the file wdsmgfw.efi is in the folder. 
    3. If the file is missing copy it from C:\windows\system32\reminst\boot\x64. 

    This solved my issue with Server 2016 MDT, WDS and DHCP in a Gen2 VM and a Gen2 VM for PXE boot. Shame on M$ that this issue persist more than a year.

    Thank you a lot for sharing the solution with us.

    This fixed my issue booting a Gen2 VM into PXE. Thank-you!

    Fixed me as well!  Shame indeed that we have to hunt around for this.   Thank you to the contributors.
    Jumat, 10 Agustus 2018 15.44
  • Hey Tried this many times with 1 virtual CPU on the WDS VM and it works fine. Adding one more virtual CPU on the WDS VM don’t work anymore. 1 virtual CPU = OK 2 virtual CPUs = NOT OK Maybe an interaction with NUMA or so. Anyway. The main point ist that it works fine for us. Best regards Alex
    Selasa, 25 September 2018 07.17
  • Did you find a solution to this? I have been running a Hyper-V host on my Win 10 Client and everything works fine, but now when i installed a new Hyper-V host running on Windows 2016 or 2019 server i cant get PXE boot to work.. I still works from physical clients and clients running on my Windows 10 Hyper V host.. 

    Jumat, 02 November 2018 14.42