I'm currently testing the "fixed" version. At the time I ran the replications the first time, I expected and accepted it doing new "first" full backups/transfers, but even this small, singe-disk VM (the one for my XO) is still doing full transfers: [image: 1758020284677-fe04762a-02ed-4b4e-9e14-fcb7be8330d9-image.png] This simple operation previously taking 2-5 minutes now takes 44 minutes: [image: 1758020534306-39bc2c0a-93dc-4627-8901-e24fb5ddf729-image.png] Compared to the previous "normal" backup time: [image: 1758020783674-19407049-8301-4a15-8afd-d6e3f78f36c6-image.png] The same goes for "Admin Ubuntu 24", single but slightly larger disk (50GB) which yesterday took 4 hours (initial "new" "first" backup, so I don't know if it still takes that time)

Hmm could the module causing the crash if the device isn't accessible? @TeddyAstie any opinion?

@Cygace Someone from the community may jump in and help troubleshoot this. The best approach would be to not modify the Dom0 installation by installing Zabbix via a community post, as you're customizing the installation. The vates team and XCP-ng specifically need to include these packages to ensure you're able to get support. Best of luck

@olivierlambert Sorry for the noise. The issue turned out to be a DNS issue. The IT guys nightmare is when a client says "I didn't touch it"! Ha! well, I didn't! Yet somehow DNS stopped working during the update and left the host and xoa in a strange state and of course NTP could not update. I fixed the resolve.conf and 99 patches showed up in the pool. I will install those after hours and I hope all will be well after that. Thank you for the response.

@Berrick Ah cool, I was anticipating that doing it live would've caused boot issues but I think I've just got a bug in my head about how it actually works, I'm conflating two separate things based on an incorrect interpretation of a previous experience I had once with XCP. Thanks!

I did stick to version: 1 in my working configuration [image: 1757959695876-01998ae9-bb3f-4a3c-b3f6-b1d34ae23704-image.png] Had to rename my "Ethernet 2" nic name to Ethernet2 without the space You have to put the exact template nic name for this to work.

@cgasser are the backup job running normally (if any ) ? can you disable temporary the backup network ? the rrd stats should be visible immediately afte if this is the root cause

I would recommend Intel or Mellanox NICs, and generally avoid Broadcom due to sub-par drivers.

What about the browser console?

Hi, Does this work nowadays in XOA ? I'm on latest update, did modify /etc/xo-server/config.toml like so (last lines) : [image: 1758019004625-cf95a01c-88d1-4eaa-a8f2-5d7accf5d87c-image.png] But bothing comes from XOA to my Graylog server (I have all 7 XCP hosts okay to this same server) Xo-server restarted... XOA rebooted... still nothing incoming.

@benapetr This is driven by hacky logic from 16 years ago: on revert, unserialize the previous state, and update the VM record with its saved values. As we do not want to modify that each time we add a field in the datamodel, use some low-level database functions to iterate over the fields of a record. Not very nice as it makes some assumptions on the database layer, but seems to work allright and I don't think that database layer will change a lot in the future. I think it might be a good idea to add a revert rpc call to the storage interface that xapi can call to, with a backup to use the current logic if necessary; xapi should be able to clean up the database afterwards. I'll ask other maintainers about this or possible alternatives, but since SMAPIv1 is considered deprecated, I doubt it will happen. I have to say that SMAPIv3 was finally fixed upstream on June by Xenserver (migrations were finally done!) and XCP-ng should get the update that fixes it in the coming weeks. Given this, I would encourage you to take all the learnings you've acquired while doing the driver and porting it to SMAPIv3. SMAPIv1 just simply has too many problems, some of them are architectural, so in general xenserver and xcp-ng maintainers would like to see it finally go away. for now I am still targetting XCP-ng 8.2 as that's what I use in production, and I haven't seen many SMAPIv3 drivers there. 8.2 is out of support for xenserver, and for xcp-ng yesterday was the last day it was supported, you really should update

That's because you are using DMC (dynamic memory control). Try on a VM with static == dynamic.