@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.
Sadly, it's not that simple. Allowing to change the partition layout will add probably a lot of complexity to maintain. However, we are not against a contribution, then we could judge the risk on getting it upstream or not 🙂
I am playing a bit with SMAPIv3, I created a storage of type file in /mnt/ and a VM, after restarting xcp-ng /mnt/ was not mounted so the storage was not mounted, I did it manually and when starting the VM Throw me
Error code: SR_BACKEND_FAILURE_24
Error parameters: VDIInUse, The VDI is currently in use
I did a detach to the disk from the vm and I also deleted the vm and created a new one but it still gives the same error.
From my experiments using a GTX1080ti you'll have to follow the instructions for generic pcie-passthrough to the letter, which mostly means that the passthrough needs to be done on both sides, on the Dom0 for relinquishing device control and for the DomU to pick up the device (section 5). Perhaps now that the restrictions from Nvidia have gone, Vates will kindly include some GUI support for those operations in XOA.
Note, that if your dGPU has multiple devices (e.g. my GTX 1080ti also has a USB-C controller on-board), both entries need to be added in a single 'xe vm-param-set' statement, otherwise only the latter device (USB in my case) will wind up in the VM.... (yeah, at least 30 minutes of puzzling on that one)
Of course, if the dGPU is your console device, it means flying blind afterwards, but I'm getting used to that with all the recent iGPUs as well (then again, I have some DisplayLink hardware that's currently unused and EL7/8 drivers for those have popped up recently...)
Thankfully the dreaded error 43 issues have gone away with the more recent Nvidia drivers, sadly Kepler support has been retired (got a lot of those still around), so you may want to preserve the latest CUDA 11.4 release as one that offers both, but for Maxwell you should still be fine.
Before trying to diagnose with the Nvidia drivers, you should be able to see the device transition via lspci on both sides, Dom0 and DomU.