Thanks. I also used "disaster recovery" with the "offline backup" option before. I also just noticed: Every time I open the backup settings, the email address field is empty. Btw: It is really confusing that it still says "disaster recovery" while the documentation uses other names....

@mguimond Not sure how old your XO is but this is the current Commit. Master, commit 5349f. Suggest try updating and try again. Maybe someone from Vates will have more information.

Small warning: XenTools are still a clusterfuck. On (allmost) all machines without our main environment it keeps the ip-configuration within the Realtek emulated NIC and never transfers it to the Xen device. It's fucked for long now - but doesn't matter if all VMs are getting their IPs via DHCP. Currently struggling with: Windows Server 2016 + XenTools/Management 9.4.2. At least it didn't break the whole VM by destroying the disk device drivers this round. tl;dr: Snapshot your VMs and have a documentation at hand, when upgrading the tools/drivers.

Ping @Team-Documentation-Knowledge-Management

Hi, IIRC, it's a known (cosmetic) problem (just the report, but the tools are still working). Also IIRC, @dinhngtu has or works on a patch.

Hi @jshiells, After some tests, I don't think it can be caused by the load balancer. If the load balancer tries to migrate a VM that is being backed up, the migration instantly fails and nothing happens. Reversely, if a backup job starts when a VM is being migrated by the load balancer, the backup will fail for that VM with error "cannot backup a VM currently being migrated".

@florent Is there anything in the logs he provided that stand out?

I think it's planned for XO 6 adding @gregoire in the loop

@TestForEcho No ETA for now. Even before supporting QCOW2 on LINSTOR, we have several points to robustify (HA performance, potential race conditions, etc.). Regarding other important points: Supporting volumes larger than 2TB has significant impacts on synchronization, RAM usage, coalesce, etc. We need to find a way to cope with these changes. The coalesce algorithm should be changed to no longer depend on the write speed to the SR in order to prevent potential coalesce interruptions; this is even more crucial for LINSTOR. The coalesce behavior is not exactly the same for QCOW2, and we believe that currently this could negatively impact the API impl in the case of LINSTOR. In short: QCOW2 has led to changes that require a long-term investment in several topics before even considering supporting this format on XOSTOR.

I even had a case where my XOA had multiple NICs (and multiple IPs) The IP that it used to access NFS was not the one I expected... the debug mode of the mount nfs CLI did put that into light. is it the case for you ?

@wezke said in Ansible Role - Install XO from source - Now available: @probain Thank you for sharing your ansible role, ill have a look at it It's far, far from perfect. So there might be a few rough edges that I solved manually. But I welcome feedback.

Hi, I just responded to your ticket with the steps to update XOA to match your new license. Regards, Dan

@WorkAccount1000 Prior to myself finding that option in the config file use to run this command that worked as well.. cd /opt/xo/xo-web sudo yarn run turbo run build --filter @xen-orchestra/web

@Pilow - so...I powered down the VM and re-attempted the RPU. It seems snapshots is a deterrent for being able to perform a RPU, because I see VMs migrating now so the RPU can run. For specificity - yes, my XCP Hosts are identical (CPU, RAM, etc); there were no affinities set (see screenshot) [image: 1763483116773-cf9b9ae2-5363-4b66-b367-1b0474e54538-image-resized.png] , etc. Thank you for the assist! I think @olivierlambert or his tech writers need to update the RPU requirements area of the docs. Snapshots cannot be present or RPU will fail. Weird why that is

On the bottom of each documentation page, there's an "Edit this page" link you can use to contribute