I can confirm that when using Citrix/Xenserver guest utilities version 8.4 (https://github.com/xenserver/xe-guest-utilities/releases/tag/v8.4.0) memory ballooning / DMC is working fine. After live migration the RAM of the linux guest is expanded to dynamic_max again. So this issue was in fact caused by Rust based xen-guest-agent. For now I'll keep using Citrix/Xenserver guest utilities on my Linux guests until the feature is implemented in Vates rust-based guest utilities. Best regards

@TeddyAstie Attached is the output you requested xen-cpuid -p.txt

@TeddyAstie That's more like it. I'm not finding the com2tcp though. I at least have something to search for. Once configured, is this persistent or do I need to create some sort of start up script that runs/loads a config on machine boot? Thanks!!

@abudef Some quotes from the documentation to clarify the situation: https://docs.xcp-ng.org/compute/#-nested-virtualization

Having help from OpenBSD side could be the way to go. Please forward your report to bugs@openbsd.org (with a link to this post too) For the record, I am able to reproduce it too (on XCP-ng 8.3 too, using OpenBSD -current).

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