@ph7 I ask the XO team about it, thanks for the report.

@syscon-chrisl Note that when changing the management interface, it's highly recommended to reduce the PMI down to just one NIC on all your hosts before you make the change. That said, it's always a scary thing to do and as others have stated, best avoided if at all possible. Making sure all hosts are at the same hotfix levelasand that their NICs are all in the same order and speeds are essential requirements.

@yeopil21 Run top, xentop, and iostat to see if dom0 and.or the storage device might be a bottleneck. The configuration of your storage device can also be a big factor, and in some casaes, various performance tweaks are possible. The specific configuration would be helpful: connectivity (NFS, fibre channel, iSCSI), number and size and speeds of disks, RAID configuration, total number of VMs resident on the device, number of independent SRs, provisioning (thin or thick), network (if not fibre channel) speed and settings. STorage optimization is a bit of an art and in many cases, can be the limiting factor, but as stated, so can the lack of dom0 resources. Also, what clock speed and number of CPUs are on your hosts?

That's great, those are companies with 100% backup dedicated products We cannot be everywhere and we have to prioritize on what most people expect. Recovery capabilities on a second site is like one of the most needed feature, that's why we did CR. From a technical stand point, when a VM is replicated, it's on another SR and XO doesn't have any direct access to the SR to mount it. IDK how VEEAM is doing, likely accessing the SR or similar (at least not on XCP-ng )

@kosa7 from what the XO devs told me : for now you have to handle it completly manually, since we have separated collection a not a relationnal db... You could maybe use a smart mode backup with a VM tag. We plan to implement a relational database in the future, which would at least offer the possibility to handle this. "Reasonnably : warm migration should be more a one off , so the user must handle the consequence. If he uses this regularly, he should add a tag to the VM " DBPRODBACKUPPLZ" and then configure his job to use this tag" FYI @olivierlambert

@olivierlambert Indeed, xe vm-export uuid=<uuid of the vm> filename=/<path>/backup.xva exports the current disk state. Thank you.

@olivierlambert yes, I started to work on friday, and hopefully will have a fix today

@lsouai-vates P.S. This HAS been working a while ago!! I just noticed that it broke when there was a backup job, which had an error and I didn't receive an email. So I can't say when the issue started.

@henri9813 hello, thnaks for the feedback. I propose that you open a git feature in xen orchestra project so we can add it to our roadmap. Have a good day

Changing python system wide on XCP-ng shows that the appliance nature of XCP-ng is really not well understood.

@McHenry hello, thanks for the report. Can you open a suggestion on Github so we can plan it or next roadmap? Have a good day.

I got this error on a backup, that the VM was created on 8.2 but at this point the hosts are both updated to 8.3. Is there something I am missing? I am new-ish to XCP/Xen, but really liking it. Not sure what other info to include here. I was trying to do DR. I am trying CR now, and assuming it will work based on your conversation. I don't think I really need CR in this case, I am probably only backing up this VM once a year. Zabbix (zabbix-host) Snapshot Start: 2025-04-23 11:34 End: 2025-04-23 11:34 VM (2.09 TiB free - thin) - xcp-dr-zabbix transfer Start: 2025-04-23 11:34 End: 2025-04-24 00:26 Duration: 13 hours Error: (intermediate value) is not iterable Start: 2025-04-23 11:34 End: 2025-04-24 00:26 Duration: 13 hours Error: (intermediate value) is not iterable Start: 2025-04-23 11:34 End: 2025-04-24 00:26 Duration: 13 hours Error: (intermediate value) is not iterable Type: full

@McHenry xo-cli backupNg.getLogs --json limit='json:500' should work ( the command line parameter are considered as string )

@vmpr there is a high chance that we improve the scheduler , so maybe be able to plan more precisely when the full occurs, but we will always keep one full backup as the beginning of the chain You can mitigate the risk on infinite schedule by using health check : restoring the backup automatically after the job, this ensure that , at the time of backup, the files are correct, and that if an issue occurs in the backup you can start a new chain, thus detecting a backup storage issue before needed it after having a production issue

@olivierlambert Hyper-V has the concept of Dynamic memory as documented below. This allows a startup mem value to be specified and something similar could be used for health checks as this is only needed for the network to connect then them VM gets killed. [image: 1745470452383-f746e366-9f3a-4d78-a6d7-219c8faac555-image.png]

@Greg_E Not sure what or why, but fresh install of everything in my lab has allowed a successful "standard" backup, I'll get into the other flavors when I have a chance as I build the lab back out. [image: 1745247353511-stuckbackup4.png]

@olivierlambert for what concern backup, I think you should ping @florent for XO-5...

@manilx we will consider it in XO-6 to improve the backup view, thanks for you reply