@TeddyAstie thank you for investigating.

I don't think you need the --unit declaration. Try serial --port=pci,0b:00.0 perhaps?

What latency are you referring to?

Could you collect a crash dump using a boot CD?

@high-voltages Just wanted to thank you again, its working now with the commands i did in the screenshot.

@olivierlambert thank you for the quick answers, just to put it into context the plan was to use accelerated Wireguard VPN in pfSense+ which comes with own FreeBSD optimized kernel modules: Some more info on CPU extensions / QAT / IPSsec-MB / AES-NI related to that: https://github.com/intel/intel-ipsec-mb https://docs.netgate.com/pfsense/en/latest/hardware/cryptographic-accelerators.html https://networkbuilders.intel.com/docs/networkbuilders/intel-avx-512-and-intel-qat-accelerate-wireguard-processing-with-intel-xeon-d-2700-processor-technology-guide-1647024663.pdf https://2023.asiabsdcon.org/program/_p05b/paper.pdf https://forum.opnsense.org/index.php?topic=37808.0 https://forum.netgate.com/topic/173606/solved-intel-qat-driver-with-wireguard-support/9 https://github.com/pfsense/FreeBSD-src/blob/devel-main/sys/dev/qat/include/common/adf_accel_devices.h#L38 Example CPU's having the relevant features incl. AVX-512: https://ark.intel.com/content/www/de/de/ark/products/226102/intel-xeon-d-1713nt-processor-10m-cache-up-to-3-50-ghz.html https://ark.intel.com/content/www/de/de/ark/products/226113/intel-xeon-d-1722ne-processor-10m-cache-up-to-2-70-ghz.html Some older Atoms have Intel SSE4.2 but miss the AVX-512 which i think bring the most performance: https://ark.intel.com/content/www/de/de/ark/products/97937/intel-atom-processor-c3558-8m-cache-up-to-2-20-ghz.html https://ark.intel.com/content/www/de/de/ark/products/134803/intel-atom-processor-c5115-9m-cache-2-8ghz.html Best regards

You can redirect its serial port to a TCP port on the host (xe vm-param-add uuid=<uuid> param-name=platform hvm_serial=tcp::7001,server,nodelay,nowait) then connect a Windbg remote kernel debugger using a connection string (com:ipport=7001,port=192.168.1.xx)

For migration between vendors (AMD/Intel) I suggest the warm migration feature of XOA, solving the problem with only few minutes of interruption.

This is absolutely something to write about in the release note of 8.3. Agreed, this should be in the release notes. I'll add it. It's now in the release notes: https://docs.xcp-ng.org/releases/release-8-3/#pool-metadata-backup-temporarily-unavailable-from-console

Passing through the usb adapter I am getting roughly 30ms response times which is acceptable. Definitely not as fast as the m.2 version but good enough to keep me from buying a mini-pc or SBC. I would love to switch to the m.2 if someone could post here if they get a success. Just a strange side note, I couldn't get it to list in xoa and use the gui to do the passthrough. I had to manually hide it from the dom and pass the usb adapter to the vm. I couldn't figure out how to refresh the pci list and tried doing reboots to see if it would pick up the new device but no luck. If anyone knows how to refresh that list I'd be interested. Thanks, SFD

@633kD4d Same issue here trying to pass through a UPS usb device to a Linux guest. VM won't start with VUSB active and the same error about fail to reset.

@Ascar said in Neofetch on XCP-NG: @Forza Not a bash script, a package that requires installation. XCP-NG has all repos wisely disabled. That's why installing it on this specific type of host is not a trivial task. Sure it is packaged for many distros, but it is just a bash script. Neofetch is a command-line system information tool written in bash 3.2+ https://github.com/dylanaraps/neofetch Neofetch only requires BASH, the rest of the dependencies are entirely optional https://github.com/dylanaraps/neofetch/wiki/Dependencies But to state what others already said, it is not recommended to install stuff in dom0.

@olivierlambert Thank you! Do you actually "feel" the difference in terms of VM performance for your services? OF COURSE! Was very slow. You cannot imagine the difference... This is an AMD Ryzen 9 7950X3D host. Moreover, since the problem started we migrated several VMs to other hosts. If you see the screenshots above, in xentop output, besides Dom0, all other VMs where like hardly using 2-3 CPUs in total. And everything was dead slow (steal time always high). My feeling here is that this was somehow related to networking (tap*), but really don't know what and why. Glad this was resolved after the reboot.

Topic restored. @gtuminauskas Please don't remove threads that have been responded to by other forum members.

@Affonso Looks like it might have been Bug 15684 in 24.03 that was resolved for 24.11 (release notes).

@dsmteam Still trying to browse the web and various xo forum but it looks like those parameters are in the .c and other precompile file so the build in xcp-ng are probably using those default parameters.

@Ascar In XO cloud means pool, "hamburger" means host. If VM is running, it belongs to host where it runs, and receives host icon, no matter where it is kept in stopped state. If VM is stopped, it belongs to pool if kept on pool shared storage (cloud icon), or to host, if on host's local storage (hamburger).

@BenjiReis The xapi is written in OCaml? That is pretty cool. I would love to learn OCaml one day. Anyways, doesn't seem intuitive to design it this way: [image: 1729609345601-334b8d7a-6f7e-4796-97c2-3c1fe4144fb6-screenshot-from-2024-10-22-08-02-03.png] Going to file an issue in that repo to see what happens. I suppose they would have to fix the OCaml code you linked as well.