@Dani I made a post yesterday about Nvidia MiG support. vGPU support on XCP-ng is tricky because of the proprietary code bit that makes vGPU work can't be freely distributed. On the other hand, MiG (which is supported by many Ampere cards like to A100) doesn't requiring licensing like vGPU and seemingly just creates PCI addresses for the card which could, in theory, be passed through to VMs.
CC: @olivierlambert since we briefly talked about this yesterday in my thread.
@olivierlambert I should have a few of the cards coming in in about a month that I may be able to provide a testbed for if needed. Something to keep in mind. 
@olivierlambert Thanks as always Oliver. MiG is a newer tech from Nvidia, I think it came along with the release of the Ampere architecture. Looking forward to what you have to say/what's possible. It'd be a really cool feature to support.
Does XCP-ng have support for Nvidia Multi Instance GPU (MiG)? I've been successful at using MxGPU on S7150x2's, but would like to see about using Ampere series Nvidia GPUs.
@stormi Is it known that a newer version of Netdata breaks the hypervisor? I'm happy to try it myself in a test environment but if it's known to break things or just not work it'll save me a bit of time.
@wyatt-made In case anyone in the future comes across this looking for answers: I was able to "resolve" the issue by doing an "upgrade" to the same XCP-ng version using the installation media. This way I was able to preserve any VMs sitting on the hypervisor. This did wipe any kernel settings that were changed as stated in the Compute documentation, but that's the point of the reinstall.
@splastunov Will this be hampered by any licensing issues? To my understanding , NVIDIA vGPU requires a license per user per GPU to work properly. Unless this isn't the case on Xen?
@olivierlambert Correct. I tried to migrate the 2 VMs off that host to another remote host, but I'm getting the error "This VIF was not mapped to a destination Network in VM.migrate_send operation" or the connection to the server is lost, or "Error: Connection refused (calling connect )", even after restarting the toolstack.
@olivierlambert XAPI is running. The error in Xen Orchestra is connect ECONNREFUSED [ip address of server:port]. I've verified the ip and credentials to the server.
Restarting the toolstack from the console said it was done, but looking at daemon.log it looks like it's failing to start?
@olivierlambert It should be, the server was functional prior to the config changes, and has been rebooted multiple times.
@ptunstall What commands did you run to resolve this issue? I think I'm having the same issue. I "hid" 4 GPUs from dom0, and now I'm getting the -104 error in Xen Orchestra. I used /opt/xensource/libexec/xen-cmdline –delete-dom0 xen-pciback.hide to try and un-hide the devices from dom0, and using xl pci-assignable-list which still shows one of the GPUs as assignable. Even after removing the GPUs from the server, I'm getting the same result.
@olivierlambert I'm using XOA, version 5.76.0, on the latest channel.
Hovering over the warning icons doesn't produce any hovertext.
In Xen Orchestra, all fo my pools have a red warning symbol next to them. All of the pools have updated patches, running a yum update on them returns no updates to be found. What does this mean?