@john.c said: also did you check "dmesg" output on the affected guests? real error messages are more interesting than speculation in this case Yes I did among a ton of other diagnoses, a billion times.. I am talking about findings i did over a long period(months). I am not going to sit down and write a book about something I gave up on almost a month ago. I know what I need to get it working, but I could not get to that state in XCP-ng. I could however get there using Proxmox. But that was on another system though, the x99 6900k. I am running as bare metal now... The former(my current xcp-ng box) was on a ROMED8-2T Epyc Milan. I tested that bare metal on a USB, and it also worked. Yes Above 4G has to be enabled otherwise reBar wont report a bar-0 or bar-1 at 16gb in linux, I got it to report that at one point (Sorry, I was not aware of the importence at that point, I just thought I had missed something, and was at a perfectly normal point in the process), but the guest driver still had issues(So it was no success anyway). All this led me to other findings, both here and in other discussions about people not succeeding with intel pass-through in xcp-ng. Again, I only mentioned those points, because I could see that Teddy, basically hadn't tested it beyond what I had already succeed at. "speculation" I am sry, but that was really I could get to.. I have searched everywhere, I have had Claud and GPT chew on it and looked through Intel's documention as well as my own hardware. The only thing I couldnt see, was what was happening under the xen hood. I will look through my flyby notes and if I find something of interest, or perhaps in regards to getting that reBar to report 16gb on the guest, I will post it here! My current Ubuntu bare metal, works as expected, I get a 16x8 on PCI v3 wich is expected from the 8 lanes electrical of the Arc pro b50. reBar is working and reporting correctly, and the performance numbers match what others have measured in a healthy system. Yes I have run plenty of heavy inference and compute.. mostly inference.. I have not used it for transcoding media yet, as that was a job it was suppose to have on the xcp-ng server.. It is even running a rtx 2080 card in the same box as well, which is running isolated along side the intel card and they are juggling data back and forth every day. No issues. But as I also said, I might suspect PCI grouping of certain motherboards, not playing well with xcp-ng, which might explain your "Its working on my computer" phenomenon. I am not currently at a point where I feel like taking my AI server apart and put the Intel card back in the xcp-ng server.. Maybe when something has actually changed, I would be willing to give it a shot again and I promise at that point, I will be sure to have some notes with me.

I tried this on a lab host this morning. XO's health check waits for XAPI's PV-drivers-detected flag on the restored VM. A test VM with nothing but an empty 2 MiB disk reported that flag as true within 3 seconds when started with UEFI firmware, while the same VM under BIOS just halted and stayed false. So if your two VMs are UEFI, that would explain the pass, though I'm only guessing at why the firmware sets it. Are they? The docs line you quoted doesn't hold in that case, and https://xcp-ng.org/forum/topic/11066 ran into a cousin of this with a FreeBSD guest. If you need the check to prove the OS really came up, the xo-backup-health-check-xenstore tag makes it wait for a script inside the VM instead: https://docs.xen-orchestra.com/backups-and-dr/backup-features-and-settings#backup-health-check. I think it's worth a look from @Team-XO-Backend too, since a passing check on a UEFI VM may say less than people assume.

For anyone reading along who needs the forwarding part today, the [logs.transport.syslog] setting this PR builds on is documented, though on the backup settings page rather than next to the audit log, which isn't where I'd have looked: https://docs.xen-orchestra.com/backups-and-dr/backup-features-and-settings#send-xo-logs-to-an-external-syslog-server On the design question (a log line through the existing pipeline versus a dedicated syslog transport in the plugin) I don't know the plugin well enough to have an opinion worth reading, so I think it's one for @Team-XO-Backend. The PR has been open since late September without a reviewer, so a look from them would help it along. I'm also curious about your second question: if others here already ship audit records to a SIEM, saying so would show how many people need this.

@poddingue Hi, we have a ticket at Vates regarding this. (Ticket#7765809)