@olivierlambert THX Olivier looks like it Working I hope i can build a Coreboot with a Supermicroboard

@stormi Actually you are correct and it is call "xen" https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source I see that on the XCP-ng 8.2 ISO that you are using a variant of the 4.13 Xen hypervisor. I think that is where I will start my reading up on things. Thanks again and I appreciate your help

@olivierlambert I also just did not see the actual Hypervisor repo on the XCP-ng Github (https://github.com/xcp-ng) Thanks my friend. You are so very helpful to me as I endeavor to get deeper ingrained into XCP-ng.

Hi All, Actually what I think that I am looking to patch into XCP-ng is a way to have a "console" Passthrough which I think would do the job perfectly. I am developing a PoC project using XCP-ng just for a heads up so some questions may sound non-standard but in my mind I have a rationale for looking in that direction so any help that you could provide would be greatly appreciated. Thanks again

If you need virtual desktop infrastructure, also take a look to UDS Enterprise

XOA is meant to be disposable. Config is pretty thin, all Xen objects are in memory only. In case of problem, just deploy a new one and import the config. Works well for people who even lost their physical hypervisors (thanks for backup being entirely self-contained, even a fresh XOA is able to restore backups made by an old lost XOA)

Hi, I just wanted to report facing the same issue, and the exact same error message for the same BFD device number as OP. In my case, I'm attempting to pass one of the USB 2.0 Controllers from my Supermicro X10SDV-TLN4F motherboard (featuing a xeon-d 1541 CPU). Since it is the same BFD number as OP, I wouldn't be suprised it's similar hardware. 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05) After the device is hidden in grub.cfg it is correctly reported by xl pci-assignable-list. The error I get on VM start-up after assignation is: Internal error: xenopsd internal error: Cannot_add(0000:00:1d.0, Xenctrlext.Unix_error(30, "1: Operation not permitted")) FYI, passing the entire USB Controller was my 2nd attempt at passing a USB Bluetooth dongle which I was unssuccessfull in acheiving due to similar issues as in https://xcp-ng.org/forum/topic/266/usb-passthrough-test-reports-in-7-5rc1. The RMRR explanation makes a lot of sense to me as well. I wouldn't mind passing more BFD devices to the same VMs if it fixes the issue, but I haven't found a combination that works. I was hoping someone extrapolated a way to make this works in XCP-ng from the work done in the Qubes community as mentionned by @hkparker.

See also https://xcp-ng.org/docs/security.html And https://xcp-ng.org/blog/tag/security/

@maxcuttins "But I have to say: developers are crazy." Yes I am using an own GitLab instance, too. And yes they are crazy, in one more way ... they are doing sooo many updates but then there is this ONE 4 year old one with a central feature I was looking for and can't imagine, why it is not done since the beginning https://gitlab.com/gitlab-org/gitlab/-/issues/14207

Good Thanks @Danp feel free to update the doc with the things that unclear, so more people can do that kind of build!

@olivierlambert @stormi So I have been working on this repo for about a month now and it is in a far worse state than I ever imagined. I showed the codebase to some golang pro's and they pretty much roasted every aspect of the original source code. It uses multiple depreciated packages, breaks multiple best practices that golang considers to be fundamental to portability and future-proofing, has a complete lack of any documentation on a variety of esoteric calls, and the source code does not compile against GOOS=freebsd. I was hoping I could just make some quick changes to clean up this repo for the XCP-NG community but this is a huge endeavor to get in a good place for the future. I would very much like to continue work on this but it has become clear to me that a small team of developers will be required to finish this in a timely fashion. I would suggest creating a new repo called XCP-guest-tools as a properly upgraded version of this repo would rewrite 40%-60% of the original source code to bring it up to a reasonable standard. I also think at that point it would be extremely unlikely that Citrix would ever merge the changes so splitting off to a newly named package would go a long way to avoid confusion about versions and source.

@fx991 Mostly fine means that you may run into issues. Just shut down your VM and restart it on the new host.

Current priority of our storage dev ( @ronan-a ) is to finish LINSTOR implementation on SMAPIv1, so SMAPIv3 work is paused until we finish that first. I'll be happy to have another storage developer, but we are still a small team.

Initial brief test seems ok Will see if i can do more of the tests later... Updated from 8.1 via yum which caused windows 10 & windows 2019 server to hang on the tiano logo. Interestingly a debian 10 uefi vm worked fine... After the update to uefistored both windows VMs started in recovery and did whatever it is windows does besides spin dots on your screen After a reboot both Windows 10 2004 and windows 2019 server booted just fine

I have good experience with WiBu Key dongles and a "Matrix USB-Key" (also license dongle) but couldn't get an Aladdin HASP working. I can pass it through (it's visible and attached) but the VM doesn't show it in device manger (Windows 10 1909). I gave up for now and will probably use a network USB thingie from SEH - already have 2 of their devices running in different environments and they work flawlessly.

Yeah, coffee lake support wasn't added until about a year ago. It was added separately from most of the other supported iGPUs. I believe its kernel 5.1 or newer that adds native coffee lake igpu support.

@stormi said in Looking for a temporary test host with a nVIDIA GPU: For the tests we had a need for 1 week ago, it's now fine, however I'll probably update this thread once we have an ISO image that can be tested by users that have such hardware. Note: it's not about using the GPU itself, but simply about making sure that the hypervisor works well with the changes we made to replace the not-built-by-us gpumon tool whose absence would make XCP-ng 8.1 unbootable (as we sadly found out after the release) with a dummy one built by us. Now is time for the tests I was talking about earlier. XCP-ng 8.2 beta is now available with our dummy gpumon and we need users who have nVIDIA GPUs to test it and give us feedback. There may be situations we have not tested where our dummy gpumon is not enough to make the XAPI happy, despite the fact that we don't support nVIDIA vGPUs (proprietary software from Citrix required for that feature).

Ahh good news! Thanks for the feedback