[SOLVED] Proxmox Migration – cannot request an IP after moving storage on new miniPC

[randybias]

Hello everyone,

I have a homelab running Proxmox (v6.8.x) on a Dell miniPC. Recently, I got a new barebones miniPC (MinisForum) and attempted to migrate by simply moving the storage and connecting it to the LAN. However, it's not working as expected.

The issue: The new machine isn’t getting a DHCP IP.
To be clear, the old static IP that was given in the first time setup is fine. The problem is that it's not showing up in my router.
The machine simply won't request an IP from the router. The IP itself is more than welcome to stay the same as it was reserved for this kind of device.
I’m using a Mikrotik router and monitoring ARP changes live.
After A LOT of tinkering, I've started to think that this is a Proxmox issue.
So far, I’ve tried:

• Clearing the old machine’s ARP cache on the router
• Manually adding the new MAC address to the router
• Disabling the router firewall
• Flushing IP configs on Proxmox and requesting a new IP
• Many other troubleshooting steps

Has anyone attempted this before? I assume a fresh Proxmox install might resolve it, but since I have a lot of pre-configured setups, it would take weeks to restore.
Any advice would be greatly appreciated!
Thanks in advance!

Note: I have already tried looking on these forums and could not find anything to help. Maybe I don't know how to look, so any tip would be greatly appreciated.

 

[cheiss]

Hi,

The machine simply won't request an IP from the router.

I assume you talk about the host?
The network configuration can be changed manually either directly in /etc/network/interfaces or via the web UI under System > Network.

Proxmox VE itself does not use DHCP, by design - so this behaviour is expected.
More often than not, you do not want servers to have DHCP-dependent (and possibly changing) IP addresses, esp. since the latter isn't trivial.
As Proxmox VE is Debian under the hood, you can configure DHCP for the host, but this is discouraged and not really supported. See e.g. the Debian wiki for this: Network Configuration

 

[randybias]

Yes, I was indeed referring to the host. I don’t necessarily need DHCP; I just want to get the machine online.

The issue seems to persist even after configuring a static IP.

I've tried the following with no success:
- Checking my network interfaces with ip link show
- Manually setting a static IP in /etc/network/interfaces

auto eno1
iface eno1 inet static
      address 192.168.1.100
      netmask 255.255.255.0
      gateway 192.168.1.1

- Restarting the networking service with systemctl restart networking
- Verifying the assigned IP with ip addr show <interface> (no valid IP appears)
- Ensuring correct DNS settings in /etc/resolv.conf

search arpa
nameserver 192.168.1.1

- In /etc/hosts/, I have

127.0.0.1 localhost.localdomain localhost
192.168.1.100 home.arpa home

 

[_gabriel]

show us full output of ip link show
full output of /etc/network/interfaces
you need to update vmbr0 section which is a bridge required for VMs

 

[randybias]

contents of ip link show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc state UP mode DEFAULT group default qlen 1000
    link/ether 28:38:ab:61:56:3c brd ff:ff:ff:ff:ff:ff
    altname enp1s0
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 20:5j:e4:16:dl:bc brd ff:ff:ff:ff:ff:ff
4: br-01d88600f05e: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DETAULT group default
    link/ether 01:56:5a:h1:b3:cc brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 01:56:44:a3:12:7f brd ff:ff:ff:ff:ff:ff

the contents of /etc/network/interfaces are just like above (I had to create that file, it didn't exist)

auto eno1
iface eno1 inet static
      address 192.168.1.100
      netmask 255.255.255.0
      gateway 192.168.1.1

 

[_gabriel]

default PVE /etc/network/interfaces content :

REPLACE enX with interface name provided by ip link show
REPLACE ips with yours.

auto lo
iface lo inet loopback

iface enX inet manual

auto vmbr0
iface vmbr0 inet static
        address ip.of.pve/24
        gateway ip.of.gateway
        bridge-ports enX
        bridge-stp off
        bridge-fd 0


source /etc/network/interfaces.d/*

 

[randybias]

Thanks a lot cheiss and _gabriel!!
I think I may have actually screwed my /etc/network/interfaces with all the tinkering, so I think that helped also.

I didn't give up, continued to search (went further down on cheiss's suggestion) and it appears that under modern Linux kernels (including those like Debian Bookworm), the Intel I225‑V Ethernet Controller is handled by the igc driver. However, there are known issues with this controller that often stem from its Energy Efficient Ethernet (EEE) feature. In many cases, disabling EEE has resolved the “no link” (/or intermittent connectivity problems).
I'll post the steps below in case anyone else has this issue.

Solution for Minisforum UM560 XT (Venus series) Ethernet Connection Issues on Linux based systems (Debian in my case):
1. Use the terminal in order to create a configuration file for the igc module:

vi /etc/modprobe.d/igc.conf

2. then, add the following line to disable EEE:

options igc disable_eee=1

3. save the file and exit the editor (press Esc -> then type :wq!)

4. Update your initramfs to include the new module parameter

update-initramfs -u

5. reboot your system

reboot

After rebooting, you can check your Ethernet connection with:

ip link show