Your starting point will be https://xcp-ng.org/docs/develprocess.html#local-rpm-build

Sure go ahead you should be able to do it in terms of permissions. If not, let me know

You might ask Xen project upstream directly (on appropriate mailing list), see https://xenproject.org/help/mailing-list/ However, if there's nobody interesting to do this, it means no money. If your company is interesting in it, we can try to see the amount of work needed (IMHO: not trivial at all) and get a rough price estimate.

Updated xcp-ng-pv-tools on my one XCP 8.2 server. (We have mostly (citrix)7.1 and (xcp)7.6 because of hardware RAID limitations) Found the ISO located at /opt/xensource/packages/iso. (verison 8.2.0-9) Moved this to my local workstation, and then to my ISO-repo file server. Went to my XCP 7.6 server, and then to the Rocky Linux 8.4 VM i just set up. Removed the EPEL xe-guest-utilities-latest package. (7.21.0-1) Mounted the XCP ISO from the ISO-repo and installed the guest tools from that. (7.20.0-9) Agent detected! and the service seems to run without error.

For the exertion start, I have run over sensible RDP stuff from the FreeRDP project just as OGON. bestrdp (https://www.freerdp.com/) The FreeRDP project has a worked on shadow worker that may be utilized as the reason for a RDP worker and the OGON project as a comparable, however further developed, type worker that likewise considers plugable modules in that it very well may be utilized for RDP and even SPICE later on, on the off chance that I recollect effectively while I feel that they have VNC previously coded up. My musings are to discover where XCP-ng at present handles the entirety of the VNC stuff for the hypervisor which I imagine that @olivierlambert just sent the connection in order to check whether it very well may be feasible to work out likely the OGON worker from that point to permit supporting the VNC, RDP, and SPICE numerous conventions. I will take some time, yet on the off chance that all works out in a good way, the client ought to have the option to associate with any of the VM consoles (Linux, Windows, and so on) with any of these conventions and not need to do it from inside the Guest VM. At any rate that is objective

Hi, No, at least not yet, due to the lack of demand for that.

Packer is an option (better than Ansible in this case). Otherwise, use xo CLI to do that.

We should probably talk in private for some details @throk Also ping @ch_s

The documentation is now in a much better shape than when I started this thread, has been available for months at https://xcp-ng.org/docs/. You can still contribute to it. Each page footer has a "help us improve this page" link that allows to create a pull request with your changes. Many thanks to everyone who contributed to the documentation and to those who will.

@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/