@dinhngtu Yes, I am using the rust based guest agent (https://gitlab.com/xen-project/xen-guest-agent) on all of my Linux guests. [image: 1773241554771-ade3a347-2452-4d9d-977d-bad46c490ee0-image.jpeg] Good job tracking the issue down to that! Is a suspend/resume performed automatically during live migration? //EDIT: I switched from Citrix/Xenserver guest agent to the Vates rust one somewhere in January so maybe my assumption of this issue being related to January round of patches was wrong. Or maybe I did not see this issue since the ballooning down to dynamic min was broken before said round of patches according to changelog.

@MathieuRA Thank you for the PR merge. I've tested this and both REST API and XO6 seem to work perfectly. As this issue is resolved, do I need to close this topic or how does things work here? Br, Aki

@Pilow Yeah, true. Also during my CBT-enabled-backups tests live migrations did trigger the fallback to a full from time to time aswell (VM residing on a different host during backup run compared to last backup run). But I did those tests ~6 months ago so maybe some fixes have been applied in that regard. You are right, in a thick provision SR / block based scenario taking a snapshot would result in the same size of base VHD being allocated again for the purpose of snapshotting... not really practical. I really hope that CBT receives some more love as we plan to move our storage to a vSAN cluster and intend to use iSCSI instead of NFS by that time so using CBT would also be our best bet then... CBT also reduces the load on the SR (as in I/O) as it removes the need to constantly coalesce disks during backup job re-creation / deletion of snapshots. @acebmxer Interesting during my tests CBT was not really stable as in backups falling back to full quite often. I recall reading somewhere in the documentation that CBT has some quirks so it seems to be a known issue.

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).

@florent Thanks for the reply. I will rebuild XO and test with current master.

@FritzGerald workaround yum update --exclude=net-snmp*

patch done by @bastien-nollet

The update mentioned by Pau should has just been released along with other updates. For more information, you can consult the corresponding blog post: https://xcp-ng.org/blog/2026/03/10/march-2026-maintenance-updates-for-xcp-ng-8-3-lts/

Commenting for my future self and others as I just came across this issue too and it's not overly well documented and comments on the forums are often missing a a full story for how to debug and get this working...... When using Ubuntu 24.04, the usual apt method of installing XE Guest Utilities via the command; apt-install xe-guest-utilities Works, but doesn't. It successfully brings through the Memory information through to XO/XOA/XCP-ng Server, but not the IP Address, which is a tad strange. When checking the version of xe-guest-utilities that is contained within the APT Repository that comes configured out of the box with Ubuntu 24.04 using the following command; apt info xe-guest-utilities You can see the response is that it is running version "7.20.2-0" (as at the time of writing, which is before running an apt update command. Even when after running an update command; sudo apt update Then checking what packages are available to be updated using the following command; apt list --upgradable xe-guest-utilities wasn't available for an update past this point unfortunately. So to uninstall xe-guest-utilities installed via APT, simply run the following command; sudo apt remove xe-guest-utilities Then install via XO/XOA/XCP-ng Guest-Tools.iso Mount + Command Line by following these steps. Firstly, Select the guest-utilities.iso from the Disk within the XO/XOA/XCP-ng Platform for the VM. Then SSH into the box/console view and run the following commands; sudo mount /dev/cdrom /mnt sudo bash /mnt/Linux/install.sh sudo umount /dev/cdrom What you will notice when you run the second command is that gets installed here is "xe-guest-utilities_7.30.0.12_amd64.deb" - So is further ahead. Then you'll need to use the following commands to start the service on boot and also start the service. systemctl enable xe-linux-distribution.service systemctl start xe-linux-distribution.service And that now results in the IP Address of the virtual machine flowing through to XO/XOA/XCP-ng, which ever you are using.

@florent That would be great. Thanks again!

@samuelolavo Thanks for your answer It's very weird because by seeing the command outputs that you pasted, it looks like everything is behaving as it should be. Even the PCI ID (segment:bus:device:function) seems to stay correct (0000:03:00.0) I'll ask others internally.

Hello, following up on this. Can anyone help decipher what the issue is? I'm stuck on this trial deployment until I can get the storage configured. Thanks!

@florent One last update. I reverted to Master branch (6699b) yesterday evening and the backup ran without issues overnight.

@TeddyAstie Thanks for the update. I do actually have a VBIOS for that GPU, but I wasn't entirely sure what to do with it - is there a process to inject it? I've found resources for Proxmox and others, but I really like XCP and equally I don't want to migrate my entire setup just for that. If it's really tricky then I'm not too worried about it, as I say the VM actually runs the cameras perfectly fine on CPU alone, it's negligible. Edit: Looks like this post might answer my question: https://github.com/xcp-ng/xcp/issues/786 "Even when specifying romfile and rombar properties on the xen-pci-passthrough device in QEMU, the ROM region is not mapped into guest memory." timemaster5 created this issue in xcp-ng/xcp open PCI ROM BAR not exposed to guest when using xen-pci-passthrough #786

502 is an answer coming from your S3, telling the server is having an issue. Adding @florent in the loop

I've had a lot of updates happening in the homelab. I've replaced the T620 with an R740, expanded my storage for both HDD and NVME pools. Also did a little min-maxing on the hardware to help separate traffic, decrease some latency and jitter for internet traffic and introducing IDS There are a lot of additions and modifications, but I guess the other big one is setting up a Dell Precision 5820 with XCP-NG as a studio and prototyping rig. Replaced Ansible with AWX, added some more VMs and migrated others but in all that I've updated the diagrams as well! Will say that XCP-NG offers up the flexibility and performance that I've needed so far. Would love to try out the XOSTOR storage at some point but will have to move around my entire setup haha. This reference diagram breaks down each VLAN [image: 1772850854389-networking-and-vlans-reference-diagram.drawio.png] The physical equipment reference diagram gives a breakdown of the server equipment and NAS at both locations, including the home rack. It also shows a basic breakdown of each server configuration. [image: 1772850854434-physical-equipment-reference-diagram.drawio.png] The physical topology reference diagram gives a simplistic overview of the major networking and server equipment. [image: 1772850854468-physical-topology-reference-diagram.drawio.png] The logical topology reference diagram gives a more in-depth view of the networking, servers, VMs, VLANs and endpoint devices. [image: 1772850854364-logical-topology-reference-diagram.drawio.png] The colo reference diagram contains my off-site location with a rented dedicated server [image: 1772850854295-colo-reference-diagram.drawio.png] The Authentication reference diagram gives a break down of how user access is sourced or what security route it takes. [image: 1772850854275-authentication-reference-diagram.drawio.png] The shared storage and access reference diagram gives a break down of how most hardware interacts with each other in regards to network routing for users, endpoints, and member servers. [image: 1772850854483-shared-storage-and-acess-reference-diagram.drawio.png]

@hawkpro I believe it will be worse with continuous replication because your replica will be in a shut down state. When you decide to start it, you will have to shut down the original VM and start the replica. You will have a downtime during shut down and start up sequence. Downtime during VM migration is a necessity so there is nothing unexpected there. All types of migrations require a VM to be suspended for some time (usually seconds) during the switchover from one host or SR to the other host or SR. If you have extended downtimes of your VM migrations, then something is not quite right with your setup.