@redakula said in Coral TPU PCI Passthrough: Frigate.nvr which is one of the popular uses for the Coral do not recommend it for new installs either. Frigate updated their recommendations because of the Google decision to sunset the device and because there are alternative options available to frigate for image inferencing. The coral is still supported though, and frigate is not the only use case or platform that can benefit from an accelerator. At the end of the day if you've already got the hardware, and it's efficient enough to run, then not using it is a waste or resources that could be allocated to other VMs.

Hello everyone ! I rebuild a new OME appliance with the latest version (4.6) Dell decided to give this appliance Proxmox, Nutanix and OpenShift compatibility, but no XCP-ng yet... If someone from Dell want to reach out about this, please contact me ! [image: 1771504614561-7f4cc1c1-90c4-4f30-94f8-cf109711cfd6-image-resized.png] What i did on the rebuild: Via live CD add xen-blkfront and xen-netfront driver, and rebuild the initrd change root password activate SSH. Via SSH sed -i -e 's/sda/xvda/g' /opt/dell/omc/utilities/tui/bin/ome_disk_config.sh sed -i -e 's/sda/xvda/g' /opt/dell/mcsi/appliance/scripts/appliance_resources.sh bash /mnt/Linux/install.sh # To install XCP-ng tools As usual, please send a DM if you want the link to the VHD Feedback is welcome ! (Disclamer: This build is something I create on my free time and to help people who have difficulty running Dell appliances on XCP-ng. I do not guarantee a fully functional appliance, but I do my best to make it work. If you have a support contract with Dell and require official support for OME, please contact Dell and request compatibility with XCP-ng.)

@EddieA Ok, good that your setup is now fully operational ! Let's sort this as a self-resolved problem then for now. Don't hesitate to ping us again if the issue comes back.

Thank you all for information. I will try to virtualize GPU to Windows VMs.

@markxc could you tell us what endpoint you used ?

To elaborate: it was already in progress, but delayed due to 1. the fact that I underestimated the impact (I thought we'd overwrite the file only when we'd modify it, not every update the package) and 2. lots of other priorities keeping the team busy. But it's clearly the reminder, and the help in better diagnosing it, that allowed to have it re-prioritized and (partly, we've mostly bought time to fix it properly, by simply avoiding to touch the file at all at the moment) fixed so fast.

I made a list of processes with a small bash script that I am attaching here [image: 1769612600385-screenshot-2026-01-28-alle-16.01.53.png]

Thank you! So in this case, if better option for me to join the hosts to existing pool and then shutdown VMs and start it on host with older CPUs. Thank you again!

For documentation purposes, there's a more general step of "Any VM you can shut down, do". Live Migration is great for VMs which need to stay up, but it's not free, and not even cheep. You will get done quicker if you can shut down VMs you don't need, migrate fewer things, and then (re)boot everything at the end.

I just learned something new, thats awesome

@dinhngtu I believe it was changing the guest TSC Mode that seems to have done the trick.

Yay! Santa came early this year!!

@hitechhillbilly no it doesn't, it just ensures the N-th vCPU of Dom0 only runs on N-th pCPU of the machine. Not sure about the practical impact of it, in the past it has been used for getting meaningful CPU temperatures from coretemp (with physical core matching virtual one), but that doesn't work anymore since Xen filters MSR accesses (including Dom0).

Hi, I can't tell it's the cause, but you should first use an officially supported client to manage it.

@isdpcman-0 said in Install mono on XCP-ng: Our RMM tools will run on CentOS but fail to install because they are looking for mono to be on the system. How can I install Mono on an XCP-ng host so we can install our monitoring/management tools? Reply I think it is advised to consider hosts as appliances and not install any external packages (repos are disabled for that purpose, that's probably your issue for installing anything) even in case of clusters of many hosts in a pool, you should deploy same packages on all hosts to expect compliancy between hosts... better use SNMP to monitor you hosts ? or standard installed packages ?

Ah nice!

@gduperrey said in How to Install XCP-ng Guest Tools on Rocky Linux 10?: but I don't have a release date yet, even for testing Actually it's already available as xcp-ng-pv-tools in the xcp-ng-incoming repository. What Gaël means is that we haven't run CI on it yet, so we haven't moved the package to the testing repository yet, which is when we usually invite users to test. However here I'm able to say that there's no risk in installing it now for testing, with: yum update xcp-ng-pv-tools --enablerepo=xcp-ng-incoming,xcp-ng-ci,xcp-ng-testing,xcp-ng-candidates (the testing repos will only be enabled for the time of the command, not permanently)

Thanks a lot for this In few months ago I have found your topic to try wazuh, and it is working good. After some error on my home lab, I need to install all again and remember your topic. On my installation, I just need to set /dev/xvda1 (if I just put /dev/xvda, VM not start). My home lab is on ProLiant DL360 Gen9.

Yes, and then Xen will reduce the RAM if there's not enough available to boot a new VM (reducing down to dynamic min). Static means it can't be changed live, while dynamic can.

So I actually posted these findings to the ZFSBootMenu Discussion github: https://github.com/zbm-dev/zfsbootmenu/discussions/787 Looks like they have tested ZBM against KVM but not Xen. Can Xen not handle a kernel being kexec'd?