VMware vSphere

Hello,

I have the problem, that I am not able to get a VM on our ESXi 6.0.0 to boot over PXE from our WDS if I choose EFI as start option. If I choose BIOS instead, everything works fine.

When I use EFI I get this screen when starting up:

After that I am presented the Boot Manager and can select EFI Network manualy, then I get the following screen. Nothing happens there. After a few seconds I get back to the Boot Manager where I can select another boot media.

Unfortunately I dont have access to our WDS-Server to view any log, but I will ask for this if I cant solve the problem otherwise. If you need any more information feel free to ask.

KR,

Mango

Hello,

Please see the below existing thread for reference:

https://communities.vmware.com/thread/541487

Hallo parmarr,

thanks for the reply but unfortunately my problem is different from the one mentioned in your link. My PXE Boot works fine if I use BIOS which the poster of the thread you linked seems to use (I tell if from his screenshot). It only does not work when using EFI instead of BIOS. Without any warning, message or failure. It just quits and the only things I can see are the screenshots posted above. If I then set the same VM to BIOS I can boot via PXE.

Did you ever find a solution to this?  I am having the same exact problem.  I am looking to create Windows 2016 server images with EFI and VMXNET3 out of the box.  I know I can get this working by using an ISO and installing it the "normal" way.  But WDS has some features that I want to take advantage of (I can use a custom answer file and embed the VMware drivers into the WIM).  Plus, I like building clean images.  Starting out with BIOS just so I can PXE boot and then converting EFI later is very unclean in my opinion (and I don't know if that is even possible).

Thanks

NK

Hi,

Perhaps this post helps?

https://www.virtuallyghetto.com/2015/10/support-for-uefi-pxe-boot-introduced-in-esxi-6-0.html

Note that you can actually change the VM from BIOS to UEFI, but only for a select number of OS's, microsoft added support for that in Windows 10 and Windows Server 2016.

(another link to virtually ghetto for those details)

https://www.virtuallyghetto.com/2017/10/tip-from-engineering-use-uefi-firmware-for-windows-10-server-2016.html

--

Wil

Hi,

Thanks for the information.  I actually don't want to PXE boot to install ESXi, as mentioned in the article link you posted.  I want to PXE boot to install a Windows 2016 VM instead.  I believe the OP is looking for the same too.

Also - thanks for the link about switching from BIOS to EFI.

NK

Yes, thats exactly what I want to do. (Windows 10 in my case but that doesnt really matter). Unfortunately, I did not found a solution yet...

maybe this could help:

https://mediarealm.com.au/articles/wds-uefi-boot-legacy-boot-pxe-dhcp-option/

Use DHCP to detect UEFI or Legacy BIOS system and PXE boot to SCCM – Automation, Management and everything in between

or simply add to google "pxe boot uefi bios"

No you should never use these DHCP options, its unsuported and not recommended

In my own testing PXE booting a Windows 10 VM to WDS/MDT is simply broken with EFI firmware.   You have to use BIOS firmware unfortunatly.

I found out the hard way after building a client image on a Win10 VM with EFI firmware, which I had to trash and rebuild as I couldn't PXE boot it to perform a WDS capture

I'm running into this as well on the client side.  Unable to PXE boot when using VMware host (in my case built on workstation) if I choose UEFI.  We're using Symantec/Altiris and it hangs when loading boot.wim.  Works fine if I just use legacy BIOS.

We are in the process of deploying new hardware and a new Win10 SOE.  I've been struggling with this exact same issue for several weeks.  I've contacted Microsoft premier support (in case it was something to do with the Boot.WIM drivers for the VM) but as it's VMWare not Hyper-V, they don't really want to know about it.

I'll follow this post very closely for any updates.

Like the original poster, we used a VM to perform a 'build and capture' MDT task sequence for WIN8.1 every few months to update the SOE image.  It worked perfectly (and used the native BIOS mode).

As the new laptops require EFI mode, we assumed we could simply adjust the VM parameters accordingly and perform a similar 'build and capture' task sequence for WIN10, but we either get this driver error:

.

.....or (like the original poster) the VM just reboots and starts the EFI boot process after a few minutes.  I've not seen the screen offering me the task sequence options even once!

I have tried countless WIMS and used different driver packs, but no success so far.

Please advise any updates or articles relating to this issue.

Cheers,

Matt

I was having the same problem and changing to VMXNET3 worked for me.  Thanks.

"I was having the same problem and changing to VMXNET3 worked for me.  Thanks."

I can confirm that his actually worked for me.

All other options mentioned here didn't work in my case. We're on VMware ESXi, 6.7.0, 14320388

I just had some luck with this..  On my vm guest,  the default network adapter type was e1000e.  I was regularly getting stuck at "Start PXE over IPv4".  I just removed the 1000e and setup a vmxnet network card.  Great Success.  I am uploading an image of my guest over PXE boot right now. 

Thank you! Switching from E1000 to VMXNET 3 fixed for me. Thanks!!

I just fixed it by disableing NetBios over TCP IP under the tcp ip v4 options -> WINS

Had this issue very often with HyperV

Has anyone had any luck with this issue?

I am using VMware® Workstation 14 Pro, 14.1.2 build-8497320 and am having this exact problem. I boot using the EFI network adapter, i get a message saying start PXE over IPv4, then i end up back at firmware.

I cant try changing the network adapter as the last post suggested as that is not an option in VMWare workstation. Any advice would be appreciated.

Hello,

our solution was to set a fixed value for TFTP blocksize at the PXE-Server und disable dynamic window size. Maybe that helps.

Hi fboehm

Could you provide any screen caps of your settings? would to try and replicate...

Thanks

I just ran into a very similar issue.  In the end, it was a whole combination of different things that caused the issue.  First, using vmxnet3 NICs on the VMs did permit UFI VMs to boot, it just took in excess of five minutes to complete the process.  I could never, or never had enough patience, to let e1000 type NICs complete booting.  It really looked like they would hang mid-way through the process.

Based on quite a bit of research, I started playing around with the different TFTP options, both in the WDS properties GUI and by creating registry keys to set default values (which I'm not ever sure applies in Server 2016 any more).  A lot of what I read indicated that TFTP clients are sensitive to fragmented packets, and also just the nature of TFTP requiring ACKs sent for every frame.  I'm operating on a 10g network, and the DHCP, WDS, and client VM are all virtual and hosted on the same vSphere host, so I want to take full advantage of the max speed possible.

Thus, I enabled jumbo frames support on the vSwitch that all of these VMs were connected to (which the physical switches in my environment were already set to), then set WDS' Max Frame size to 8192, which keeps it under the 9000 MTU threshold and thereby prevents fragmentation.  Additionally, I disabled the Variable Window negotiation setting and hard-coded a registry value to set that to 8 windows.

My EFI now boots as fast, if not faster than BIOS.  And I tried almost every possible combination of different settings to get this working, and finally settled on this. 

My setup definitely did not like having the absolute max value of 16384 and the problem persisted until I set WDS Max Frame size to be under the MTU threshold.  For most Ethernet networks, the default MTU (and also VMware's default) is 1500, so you should probably try setting the Max Frame rate to 1024 to keep the frames from fragmenting if you want to avoid jumbo frames.  Though in our setup, jumbo frames also really increases the speed of the TFTP transfer.

Just in case this helps anyone:

My issue actually turned out to be a WDS fault. I had installed the full WDS role, downloaded all ADKs etc (done many times in the past), but for some reason, the "RemoteInstall\Boot\x64" folder had some files missing, one of these being wdsmgfw.efi - causing the EFI TFTP transfer to fail. wdsnbp.com was present, which is why BIOS network boot worked without issue.

I have no idea if this is a known Windows bug, i uninstalled the role, rebooted the server and reinstalled, re-imported my Deployment share and regenerated boot images, nothing solved this problem. In the end i had to copy the x64 directory from a known working server, then regenerate all boot images, which fixed the problem. EFI from VMWare workstation appears to work fine, for me at least this was a Windows Server issue.

Thanks lsjordan!

For people searching for the code, this is how to do it.

Copy-Item -Path 'C:\Windows\System32\RemInst\boot\x64\wdsmgfw.efi' -Destination 'D:\RemoteInstall\Boot\x64'

Just replace the destination path with your path.

However, despite this seems strange, the destination folder must be x64 and not x64uefi.

No PXE Boot from VM with EFI. Using Microsoft WDS​

Ever find a solution to this?  We were working fine and then one day poof it stopped working.  Cannot get any support from VMware.  

After much troubleshooting, I got PXE over EFI working by deleting the 060 option from the DHCP scope Options and Server options.

I set up a DHCP Scope policy for the PXEClient for 066 and 067

Per Microsoft:

• Don't use DHCP options 60, 66, or 67. It isn't supported.

https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/os-deployment/advanced-troubleshooting-pxe-boot#troubleshooting-dhcp-discovery

Also, afterwards the PXE boot stopped working again and option 060 had returned on the DHCP IPv4 policy, even though I had deleted it.  I deleted it again and PXE started working again.

Hello every one

Exact same issue here as the OP.

Did anyone find a solution to this? or we just putting it down to UEFI simply broken on Workstation?

Thanks 

I have gone through similar issue and it is because of DHCP settings. Configured DHCP server accordingly and it is working fine now. This link helps.

http://www.itfaq.dk/2016/07/27/use-dhcp-to-detect-uefi-or-legacy-bios-system-and-pxe-boot-to-sccm/

If you will change network adapter of your VM from E1000e to e1000 wds + pxe will start normally.

have same problem with wmvare 6.7

Try it without Secure Boot. This worked for me.

Hi All,

For the issue mentioned in this thread, all you need to change the VM's firmware as i pointed out in the image file.

I create the VM with a e1000e network adapter and it works fine for me.

After I have installed the operating system I change the network adapter to vmxnet3.

You must change the adapter before you configure the IP address. Otherwise you will lose the configuration you already entered.

i will echo that this issue still exists. on my new cluster, 6.7, it defaults to EFI bios(recomended), but it uses the e1000e network card. It appears that these are not compatible settings for WDS.

Switching the the vmxnet3 completely solves the problem.

i am not using this network card anywhere so i dont know if its stable as the e1000e but i am going to try it out on this new machine i am building.

I found a solution that worked for me instantly. Went into the settings of the VM and switched the Network Connection type from NAT to Bridged. Worked perfectly. I also tried this out using a VMNet connection with the auto bridge option and that worked as well!