Hyper-V virtual machines have the ability to PXE boot. Obviously, PXE boot raises some security concerns. The problem is, unlike a typical physical machine's firmware, there isn't an obvious way to disable PXE boot altogether.
Hyper-V manager shows each of the VM's network adapters in Settings=>Firmware=>Boot Order
:
You can move a network adapter to the bottom of the boot order, but you can't remove it altogether from that screen. So if, for some reason, Hyper-V can't boot from any of the other drives, the VM still tries to PXE boot and shows this screen:
I've scoured Settings=>Network Adapter
for a way to disable PXE boot to no avail.
So my questions are:
- How do you disable PXE boot in a Hyper-V VM?
- If you can't disable PXE boot, is there a good reason why?
I'm using Windows Server 2012 R2
Use Powershell to Remove Network Boot Devices from the Boot Order
You can use PowerShell to strip the
Network
BootType
s from the VMs boot order.Extract the Current Boot Order
Using Powershell you can use this command to extract the current boot order:
If you inspect
$old_boot_order
You should see the list of boot devices fortestvm
. Something like this:Strip the Network Boot Devices
You can strip the boot devices from the boot list with the
Network
BootType
using this command:Inspecting
$new_boot_order
should look something like this with no moreNetwork
boot devices:Set the New Boot Order
To set the new boot order for the VM use this command:
Confirm the New Boot Order
To confirm what you did use that first
Get-VMFirmware
command again:Beware: If you use both PowerShell and Hyper-V manager to make changes to the boot order, PowerShell may report erroneous (out-of-date) boot order. See also this technet thread.
In case someone lands here looking for Generation 1 VM solution, I ended up looking for it all around the place.
Found it was really simple, in MS official docs:
https://docs.microsoft.com/en-us/powershell/module/hyper-v/set-vmbios?view=win10-ps
The
Set-VMBios
supports-VMName <name of VM>
as well, I use that for readability, while MS docs obviously uses shorter form.Those firmware entries you mention are of type Firmware Application (101fffff). They can be controlled from within the guest OS using bcdedit, the hypervisor will replicate changes:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc749510(v=ws.10)
Host:
Guest:
The entry has been removed from the Hyper firmware page (if the settings are currently open, hit the refresh button on the firmware page)
But what if we remove the harddisk?
Congratulations, you just killed your machine. There's no option on the Hyper-v Gui page to fix this, nor will a guest reboot fix this, so thank you for providing a powershell command to fix this, I just tested, it's working. In the Hyper GUI, there's a stupid way to fix the firmware by opening the harddisk page, changing SCSI number, clicking "Apply", then changing it back, hitting "apply" again. There's MS for you.
What happens on a real computer when a firmware application is removed through bcdedit? Will the motherboard (or whereever that mysterious NVRAM resides) re-create the firmware entry after a reboot? Will it be then picked up by bcd store automatically?