The FreeRDP project has a simplified shadow server that might be used as the basis for an RDP server and the OGON project as a similar, but more advanced, type server that also allows for plugable modules in that it could be used for RDP and even SPICE in the future, if I remember correctly while I think that they have VNC already coded up.
My thoughts are to find out where XCP-ng currently handles all of the VNC stuff for the hypervisor which I think that @olivierlambert just sent the link so as to see if it might be possible to build out probably the OGON server from there to allow supporting the VNC, RDP, and SPICE multiple protocols.
I will take some time, but if all goes well then the user should be able to connect to any of the VM consoles (Linux, Windows, etc.) with any of these protocols and not have to do it from within the Guest VM.
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.
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)
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:
@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 😁
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.