Thank you all for your answers—now it's clear.

@Greg_E Thanks, I've got another thread up and it's potentially being addressed!

Latest XO can be new tested along XCP-ng (with OpenSSL 3): https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/363 Feedback welcome

@benapetr said in New project - XenAdminQt - a cross-platform GNU/Linux, macOS, Windows native thick client: @Pilow I know them a little bit, I will have a look, but I am now working on another new cool thing! It's called xen_exporter: https://github.com/benapetr/xen_exporter It's a prometheus exporter that hooks directly to xen kernel via xenctrl library from dom0 and extract all low-level metrics from the host, allowing very detailed graphs with very low granularity with stuff I always missed in both XenOrchestra and XenAdmin: ... We have a similar project : https://github.com/xcp-ng/xcp-metrics, but unfortunately it's not used as of today (though it could get revived as Rust for Xen matures, i.e easier to build). There is also Xen Orchestra OpenMetrics support but it's not on XCP-ng itself.

I know it's actively worked as we speak (ACLv2). So I would say this year at least It's in our (soon published) roadmap in the "Next" section, just after the "now".

@mjr99 I bypassed it weeks ago. Didn't have to downgrade netbox. At the time. I upgraded to the latest Xo from sources. Then netbox worked. I shall be upgrading xo soon again Thank you all.

@Cyrille

@Pilow Yeah I was following your post. At first I thought i was having random backup issues with backups via proxies with the occasional issue with backups via xoa. Then just yesturday see the error about memory. For now I just rebooted XOA and it down under 2gb currently. Will wait and see how long for it to build back up again or untill Dev team finds a solution to the problem.

@AtaxyaNetwork Hi yes, Sorry I'm not super experienced in this area at all. I'm SSHd into the host and just ran dmesg -T in the root. [image: 1771509732474-0583e493-4d70-40b7-afc0-a88b0d9fd1a4-image.png]

@blueh2o Ooops, sorry - I read your message the wrong way around. You're right, that sounds really weird in your case....

@User-cxs si ici :[image: 1774010356739-c9d11a94-06d8-4a3c-b191-f95b2e2ef6f7-image.jpeg] tu DISABLE le serveur. tu nous confirme que c'est "comme" le probleme que tu constates ? un XOA tout vide en page d'accueil ? tu re ENABLE, et ça reviens ok ? tu n'as pas de probleme réseau / micro coupures / host distant au XOA (ipsec/openvpn?) ? la déco/reco que tu as me fait penser a un simple probleme réseau (si ça reviens tout seul et aucun autre impact...)

@yann Item Opened on Gitlab.

@MathieuRA Thanks for the quick response and for flagging it, really appreciate it! No rush at all. Thank you for all the hard work being put into the REST API, it's been fantastic.

@yann Ce n'est pas de la PROD. Si ma compréhension est bonne, après recherche, le stockage vers la LUN NetAPP (iSCSI) a été perdu, la mode HA étant actif (les volumes HA n'était plus accessible). [10:05 xcp-ng-poc-1 ~]# xe vm-list The server could not join the liveset because the HA daemon could not access the heartbeat disk. [10:06 xcp-ng-poc-1 ~]# xe host-emergency-ha-disable Error: This operation is dangerous and may cause data loss. This operation must be forced (use --force). [10:06 xcp-ng-poc-1 ~]# xe host-emergency-ha-disable --force [10:06 xcp-ng-poc-1 ~]# xe-toolstack-restart Executing xe-toolstack-restart done. [10:07 xcp-ng-poc-1 ~]# Côté stockage [10:09 xcp-ng-poc-1 ~]# xe pbd-list sr-uuid=16ec6b11-6110-7a27-4d94-dfcc09f34d15 uuid ( RO) : be5ac5cc-bc70-4eef-8b01-a9ed98f83e23 host-uuid ( RO): 0219cb2e-46b8-4657-bfa4-c924b59e373a sr-uuid ( RO): 16ec6b11-6110-7a27-4d94-dfcc09f34d15 device-config (MRO): SCSIid: 3600a098038323566622b5a5977776557; targetIQN: iqn.1992-08.com.netapp:sn.89de0ec3fba011f0be0bd039eae42297:vs.8; targetport: 3260; target: 172.17.10.1; multihomelist: 172.17.10.1:3260,172.17.11.1:3260,172.17.1.1:3260,172.17.0.1:3260 currently-attached ( RO): false uuid ( RO) : a2dd4324-ce32-5a5e-768f-cc0df10dc49a host-uuid ( RO): cb9a2dc3-cc1d-4467-99eb-6896503b4e11 sr-uuid ( RO): 16ec6b11-6110-7a27-4d94-dfcc09f34d15 device-config (MRO): multiSession: 172.17.1.1,3260,iqn.1992-08.com.netapp:sn.89de0ec3fba011f0be0bd039eae42297:vs.8|172.17.0.1,3260,iqn.1992-08.com.netapp:sn.89de0ec3fba011f0be0bd039eae42297:vs.8|; target: 172.17.0.1; targetIQN: *; SCSIid: 3600a098038323566622b5a5977776557; multihomelist: 172.17.1.1:3260,172.17.10.1:3260,172.17.11.1:3260,172.17.0.1:3260 currently-attached ( RO): false [10:09 xcp-ng-poc-1 ~]# xe pbd-plug uuid=be5ac5cc-bc70-4eef-8b01-a9ed98f83e23 Error code: SR_BACKEND_FAILURE_47 Error parameters: , The SR is not available [opterr=no such volume group: VG_XenStorage-16ec6b11-6110-7a27-4d94-dfcc09f34d15], [10:10 xcp-ng-poc-1 ~]# Après ca, XO-Lite s'est correctement relancé.

Thank you for the input everyone. I've tested XenAdminQt and it sees iso library, thank you for advice! Reason for using XCP-ng center is ease of use/simplicity during quick testing deployments in comparison to XO.

patch done by @bastien-nollet

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

@simonp I'm not sure which one as I can see 2 config.tom file. 1st is under "/root/.config/xo-server/" config.toml.txt 2nd is under "/opt/xo/xo-server/" config.toml2.txt Both config.toml attached. Thank you. Best regards, Azren

No worries, it happens! Glad you found the problem

@kent you would have to rollback to early december 2025 XO/XOA (before the 10 of december) quite a long way I'm just waiting the devs to eventually fix it as we have other way to manage VDIs (API calls)