Unraid seems to have a real issue with paravirtualized NICs.

 

Using E1000E drivers, I was able to stop that from happening on one NIC (the only gigabit one), but it did seem to cause issues with docker containers' webuis*.

(*and going back to VirtIO, it's still borked. Somehow now no docker container has the webui option, and the ones using bridge/host now can't be accessed anymore in bridge/host mode, even typing the port manually.

Only way I could fix that behavior was, for some containers, to remove-reinstall them, or to change the port back and forth until it worked. Changing between host, bridge, br0 and such did nothing.)

 

Virtio drivers do "work" somewhat on the 10G paravirtualized NIC, but not only they do cause kernel: eth1 - bad gso: type: 1, and this kind of unsightly states:

it happens also that SMB/NFS shares on these networks are thoroughly unstable.

 

It's actually somewhat surprising that an hypervisor that uses VirtIO drivers for its VMs seems to dislike so much being served with what it dishes.

 

And yes, do note that Unraid VM does use host cpu passthrough.

Edited November 2, 20241 yr by Keexrean

Possible solution I'm currently testing, one on eth0, one on eth1 and both on eth2:

 

ethtool -K eth0 rx-gro-hw off

ethtool -K eth0 rx-lro-hw off

 

Any other idea?

Its a kernel bug, pretty sure its fixed in unraid 7 beta4, though not tested myself.
I'm still on 6.12.13, so using vmxnet3 drivers is my workaround.

@tjb_altf4 Haven't tested vmxnet3... is it also a 1gbps virtual nic or is it 'adaptative'? (I would very much prefer my unraid VM to be able to still benefit from the fact its host is equipped with 2x 10gbps links)

 

So far, post-'ethtool -K eth0 rx-gro-hw off', I haven't had any kernel whining tho!

Edited November 4, 20241 yr by Keexrean

1 hour ago, Keexrean said:

@tjb_altf4 Haven't tested vmxnet3... is it also a 1gbps virtual nic or is it 'adaptative'? (I would very much prefer my unraid VM to be able to still benefit from the fact its host is equipped with 2x 10gbps links)

 

So far, post-'ethtool -K eth0 rx-gro-hw off', I haven't had any kernel whining tho!

it should work fine at higher speeds... I've seen it use 5Gbps on my own system (25GbE), not done any formal testing... I just needed a quick fix after migrating 😅
Note that cpu utilisation will be higher compared to virtio (when its not broken), which is why when its fixed virtio will be the better option.

10 hours ago, tjb_altf4 said:

it should work fine at higher speeds... I've seen it use 5Gbps on my own system (25GbE), not done any formal testing... I just needed a quick fix after migrating 😅
Note that cpu utilisation will be higher compared to virtio (when its not broken), which is why when its fixed virtio will be the better option.

Gotcha! So far disabling generic recieve offload on VirtIO interface within the Unraid guest seems to have fixed the issue on my side on 6.12.13. 

Update: it did fix the kernel errors, but my proxmox cluster still sometimes loose connection to SMB/NFS shares, or the backups do report an error linked to being unable to reach storage.... but still do the backup just fine and the files are there and proper.

I'd guess it might have something to do with disks spinning down though and taking a bit of time to spin back up? Eh.

Update: NFS drops happen way less often, half-resolved by the gro disabling that shut the kernel error on unraid guest.

 

The other reason of drop on NFS seem to be the mover and other types of file changes, causing NFS to error for a fileid change and not remount properly

Nov 10 15:32:29 PVESERVERNAME kernel: NFS: server UNRAIDNFSSHAREIP error: fileid changed fsid 0:91: expected fileid 0x280000001eab92, got 0xfe000000cbd76753
Nov 10 15:32:29 PVESERVERNAME systemd[1]: mnt-pve-NFSSHARENAME\x2dNFS.mount: Deactivated successfully.

 

Still don't know what the cause was for SMB though (it's actually the same share over 2 sharing protocols, I have been running the NFS one for the past week, can't tell if the SMB still has an issue since it is deactivated atm)

 

 

 

 

Currently, to force a remount, I use this script on host side, on each of the PVE nodes:

#!/bin/bash
while true
do
        list=$(ls /mnt/pve)

        for i in $list
        do
                status=$(ls /mnt/pve/$i 2>&1)

                if [[ $status =~ .*Stale.* ]]
                        then
                        umount /mnt/pve/$i
                fi
        done
        sleep 10
done

Running it as a service, it won't spam the system logs in GUI, stays fairly lightweight (while, for, 1 ls command +1 per share), and basically make the drops not incidental on neither backups (even though they sometimes throw an error, they do work) nor regular use from the GUI (like downloading LXC templates, moving a vdisk from local storage to the share to convert it between nodes running local-lvm or a zfs rpool to be able to migrate the vm/container between them, etc)

I have Unraid 7.0.0-beta.4 running on Proxmox 8.2 with virtio, and I see no errors or having any issues. Running on a Terramaster f6-424 Max.