Overview: My Unraid server's host OS is currently inaccessible via the network (cannot ping its expected IP, web GUI connection refused), and I cannot see the Unraid console display. A Windows 11 Virtual Machine (VM) running on this Unraid server is fully functional, displaying video output via motherboard's integrated GPU (iGPU) passthrough and successfully obtaining its own IP address directly from the LAN's DHCP server. This issue occurred immediately after a motherboard BIOS update.

Symptoms:

• Unraid Host:

  • Unreachable via network: ping to its expected IP fails. The physical network interface for the Unraid host is not acquiring an IP address from the router's DHCP server that we can identify. Attempts to connect to the web GUI (HTTP) result in a "connection refused" error.

  • No console display: The motherboard's HDMI output is showing the Windows 11 VM's display, preventing access to the Unraid OS console.

• Windows 11 VM:

  • Fully functional, including graphical output via passed-through iGPU.

  • Network access is working, acquiring its IP directly from the LAN's DHCP server (not from Unraid's internal DHCP).

Context/Recent Changes:

• Recently performed a BIOS update on the Unraid server's motherboard (MSI MAG B650 TOMAHAWK WIFI, BIOS 1.M3 03/05/2025).

Detailed Network State & Physical MAC Address:

• My Unraid server's physical onboard NIC (RTL8125B 2.5Gbps, identified as eth0 in previous boot logs) has a MAC address of 34:5a:60:62:fd:f9.

• Before troubleshooting attempts (and as seen in older syslog entries), this MAC (34:5a:60:62:fd:f9) was associated with IP 192.168.1.67 in my router's DHCP bindings.

• After applying the "clean slate" DHCP configuration to the Unraid USB drive and rebooting:

  • The MAC address 34:5a:60:62:fd:f9 is NO LONGER PRESENT in my router's DHCP client list.

  • A new IP address, 192.168.1.139, appeared in the list, but it is associated with a different MAC address (54:e1:ad:37:0d:2d). This is not the MAC of my Unraid server's physical NIC and is likely from another network device or a virtual component not related to the Unraid host OS itself.

• Therefore, despite efforts, the Unraid host OS's primary network interface (34:5a:60:62:fd:f9) is still not acquiring a recognizable IP lease from the router.

Troubleshooting Steps Already Taken (and Results):

1. BIOS Configuration:

   • Verified and enabled Intel VT-d/AMD-V IOMMU/SVM Mode.

   • Verified and enabled Above 4G Decoding.

   • Verified and disabled PCIe ASPM and Resizable BAR Support.

   • Confirmed PCIe E1 Gen Switch is Gen4.

   • Confirme Resume By PCI-E Device is Disabled.

   • Confirme PCIe ARI Support and PCIe ARI Enumeration are Auto.

   • Confirme Intel VMD Controller is Disabled.

   • Confirme iGPU Multi-Monitor is Enabled.

   • Confirme Unraid USB is first boot device.

   • Result: No change to host network/display access.

2. Unraid USB Drive Network Configuration (Manual Edits on another PC):

   • Performed graceful VM shutdown, then dirty server shutdown, removed USB.

   • Edited network.cfg to contain ONLY: # Generated settings: and USE_DHCP="yes".

   • Renamed network-rules.cfg to network-rules.cfg.bak (if present).

   • Renamed network-extra.cfg to network-extra.cfg.bak (due to Tailscale plugin detected).

   • Safely ejected USB, plugged back into server, rebooted.

   • Result: Physical NIC (34:5a:60:62:fd:f9) still not acquiring an IP. Web GUI still "refused to connect."

3. VM Configuration File Location:

   • Confirmed via domain.cfg that VM XML configuration files are located on the Unraid array (/mnt/user/domains/), not on the USB drive.

   • Result: Cannot manually disable iGPU passthrough by editing the VM XML directly, as the array is inaccessible.

4. Syslog Analysis:

   • Reviewed syslog (identified as from a previous boot when static 192.168.1.67 was active) confirming eth0 (RTL8125B, MAC 34:5a:60:62:fd:f9) was detected and network services (nginx, sshd) attempted to start on 192.168.1.67.

Current Status:

• Unraid host's physical network interface (34:5a:60:62:fd:f9) is not acquiring a DHCP lease from the router after BIOS update and config resets.

• Unraid host's web services are inaccessible ("connection refused").

• No direct console access to troubleshoot further due to iGPU passthrough to a functioning VM.

• Cannot edit VM configuration to release iGPU, as VM configs are on the array.

Request: Seeking urgent guidance on how to regain direct console access to the Unraid host, or specific diagnostic steps that can be performed when the host network is unresponsive and GUI/SSH are inaccessible, given the clear physical NIC MAC and its current failure to acquire an IP. A full OS reinstallation is a last resort.

Edited July 28, 2025Jul 28 by mrstephenkennedy
Incorrect information.

If the NIC is not getting an IP, try another NIC, cable, router port, etc.

The VM is loading and getting an IP from the LAN DHCP server. The NIC is getting an IP.

1 hour ago, mrstephenkennedy said:

The NIC is getting an IP.

Don't follow:

19 hours ago, mrstephenkennedy said:

The physical network interface for the Unraid host is not acquiring an IP address from the router's DHCP server that we can identify

Please post the diagnostics.

I mispoke on the original post, it was AI-assisted...

34-5A-60-62-FD-F9, my physical NIC on the server, is getting a DHCP assigned IP from the LAN DHCP server - it is the only NIC on the server....as the VM itself works (it is close to bare metal - all pass-thru), and the VM is fully operational, however the management IP of the server isn't present on the router (DHCP nor static tests were successful).

Therefore, I cannot get/give a diagnostic...the dashboard, ssh, nor telnet are accessible without a server IP.

I do have the boot USB drive pulled and can access syslog before and after the BIOS upgrade if that helps any.

Edited July 29, 2025Jul 29 by mrstephenkennedy

You can disable the VM service from starting by editing /config/domains.cfg on the flash drive and changing SERVICE="enable" to "disable"

If the iGPU is bound to VFIO-PCI also delete or rename /config/vfio-pci.cfg, and you should then be able to get the diagnostics from the CLI.

Embarassing as it is, I'm going to share that this was my own fault....getting the VM as bare metal as possible, the VM OS was installed directly to the NVME drive and after BIOS update, the new BIOS naturally reset boot order to the NVME drive and not my USB drive. Issue solved, but thanks for the replies and efforts.

I love it when a solution reminds us to check some of the simpler things first.

Definitely not an embarrassing error or oversight, it's not something most people would think to check for.