Using 3 Mini-ITX Atoms J5005 boards to build a three node HC test environment (actually
there is a fourth to simulate a remote DC)
These boards have a RealTek 8169 Gbit controller, which for hardware/firmware or driver
reasons comes up just fine on cold boots, but struggles on warm-boots or whenever the
interface is re-configured, as is the case when the OVS overlay is configured, ...
* unless link-speed autonegotiation is enabled
after which it works just fine.
So for a normal system, I can just put a proper ETHTOOL_OPTS="autoneg on" into
/etc/sysconfig/network-scrkipts/ifcfg-<device-name> to avoid trouble on warm boots,
but once the overlay network is put on top, the network manager no longer controls the
device and the standard "ignore" setting of driver/hardware evidently causes the
link to fail: dmesg reports the interface toggling and ovs isn't happy either.
The Ethernet switch is unmanaged, so there is nothing I can do there to speed up or
eliminate negotiations, and I currently see three options:
1. Find/be told where to renable Ethernet link speed autonegotiation with the OVS/VDSM/??
so the RTL8169 is happy again
2. Use a known USB3 GBit NIC (no space in the chassis to put e.g. an Intel NIC)
3. Make an USB3 2.5Gbit NIC based on RealTek's 8156 work, but currently that requires
compiling from source and loading it at boot
Option 3 works just fine with a CentOS base, but I got tons of problem making oVirt hosted
engine work with that.
Option 3 for the oVirt node image seems to class with the read-only nature of the oVirt
node imge: While I can load a pre-compile driver interactively, I can't make it stick
with dracut -f.
I haven't immediately found a way to patch/fix/build derivative oVirt node images with
that driver included and am somewhat to impatient to wait until it's mainstream, so
any help would be appreciated.
I've verified option 2 with a single USB3 GBit adapter natively supported by the
kernel that I already had available, but I then opted to jump the gun and buy the slightly
more expensive 2.5GBit variant as a better match to a Gluster environment: A mistake in
this context as it turned out.