This message was deleted.
# harvester
a
This message was deleted.
p
it sounds like basically consumer/homelab hw (cpu/mobo) limitation. like might be possible to hack around depends on reqs, but it's not surprising they physically don't support secure pcie virt. it's more like "HIGHLY recommend avoiding v1.8 if wanting to do secure multi-tenant pcie virt on NUClab hw"?
t
agreed.
b
I'm on Intel Xeon + L40S with v1.8.0, and my IOMMU groups are fine. But I'm hitting the same controller bugs: duplicate
permittedHostDevices
entries, stale PCIDeviceClaims, and devices that show as enabled but don't appear in the GUI
These reproduce on Intel as well, so they seem separate from the IOMMU group change. So there may be two distinct problems here: the IOMMU grouping (hardware/kernel behavior) and the pcidevices-controller bugs (which reproduce across hardware).
t
I have seen that as well. rebooting usually fixes that.
b
That’s a fair workaround. The reason I’m digging deeper is that in a more production-leaning setup a reboot is costlier
It means draining the node and restarting every VM on it just to re-attach a single GPU. So Im hoping to understand the root cause well enough to avoid the reboot
t
agreed that reboots are not ideal. Open a Github issue?