This is unconditional for a reason. The CSTATE errata in Nehalem are crippling - IIRC a core going in an out of a deep C state does not maintain cache coherency correctly, resulting in arbitrary memory corruption.
You really do care about not hitting this errata, even on a test/hobby server.
@olivierlambert For now I am going to script it with 'xe vm-export" command. Also it would be good to be able to export to the server itself, instead of downloading to the client. My VMs are over 500Gigs
As far as I understand it, this will give us multiple tcp streams over an LACP link, truely aggregating traffic on multiple interfaces. (Until now, you needed to use iSCSI multipathing for this, which isnt able to thin provision.).
You're neigher right nor wrong: LACP is more complex than just bundling NICs and in many cases it will NOT give you any benefit.
Why? Simple: For that you need to have NFS using multiple ports but stay with same MAC and IP, which means that your LACP balancing algo needs to be set (and support) L4.
Many just go L2 or L3 (means they decide on MAC or IP-Address).
As a quick search didn't answer me: If it even doesn't go that 'passive range' multiple port way: In typical environments it won't help you at all with LACP.
@olivierlambert sure. it's very long though, I grepped out the intel devices for a shorter version on the forum, and attached txt files with the full output.
I forgot there is also a gt 8800 present but i don't have the internal power cables for it (yet) and it looks like it needs them to even show up (some will work just die when they need more power). ill take it out next time I open it up.
the riser layout physically is this (from the back):
@fohdeesha Very interesting, thanks for the info! I did a double-take at the notion that wireless APs rely on the MAC address for authenticity... that's what the session key is for! But then I realised that the AP needs to be able to map IP/MAC address to session key for incoming packets, so it makes sense; we'd need one session per MAC address.
Welp, I guess it's cable-running time...
I do wonder, though: could the hypervisor act as the gateway for a subnet containing the guests, so that only the hypervisor is using the wireless connection? I don't know how challenging that would be to implement in XCP-ng, but I expect there'd be security implications, and one would still need a router that allows you to manually configure routes. Although I don't think I've ever come across a residential router/gateway that doesn't allow that, I haven't messed around with them, and I expect the ISP would just remotely reset custom routes after a restart, which would be a nuisance.