@Pilow Yes, we monitor observability metrics for guest OSes via other means but being able to see this info via the Xen Orchestra web UI along with the other metrics in the Stats tab definitely has is benefits, especially when performing initial troublehshooting or when dealing with groups in our org that only have access to the XO interface and not the other metrics dashboards. Don't get me wrong, I definitely appreciate all of the work that you are all doing to get these tools working and can't wait to start using them in production. I just need to make sure that they work as expected.

@dthenot Thanks for getting back to me. Yes, it seems we still have time to prepare for the robot uprising I did boot from the initrd fallback before, and ChatGPT walked me through hosing that one as well. I ran the command from that doc as verbose. [image: eNSx2yx.jpeg] I ran the exact command a 2nd time as: dracut -f --verbose /boot/initrd-4.19-xen.img 4.19-xen No change. Boot to dracut with the keyboard not working. I've tried multiple kernels.

I will tell you a little secret, you taught me more than that one command for CLI lol One more important note for my Bitwarden Thanks again bud!

new VM wizard 1- Name it [image: 1763659003667-16428ce4-ad0d-4cc9-b37c-ceb2e91de263-ae0a89fa-d00c-4a94-b452-b502fba7f7e8.png] 2- Prep it [image: 1763659022574-32cd4196-f3f3-4609-97dc-08adaf713271-a1507a6f-1532-47ed-b07c-bcb489ceeeff.png] You choose the available pool/host/SR/network, and then template. All choices are driven top to bottom. all filtering happening here is based on TAGs in XOA, hope XO6 will not break it but it was also the easiest way to differentiate "templates" that are HUB templates, and "templates" that are VM config models and need an ISO bios mode is also automagically selected by tags...[image: 1763659613255-51e985b3-38d8-47c3-9bc0-a9254e426a6a-25d7c3e1-2d07-4820-8fd4-28d6a9fc014d.png] 3- Customize it [image: 1763659045584-c4682f85-9c03-4331-8095-89ed9d1159f2-27bd63ac-5510-42c5-b7c8-3b4043409677.png] Dynamic cloudconfig file creation, you fill the form, it changes the config config is manually editable if you want to 4- Deploy it [image: 1763659066278-d8424c75-9207-4c0f-b86e-f110bd8ffef0-b1e16498-1813-4ec2-8e7f-037f84cbf57c.png] Final check before Pulumi does its magic. to be done : ssh-key wallet/generate button hash of user password to avoid plain text in cloudconfig file differentiate windows/linux templates to generate cloud-init/cloudbase-init files DB of tenant/reseller/client logic, full admin view for now beta opens in a couple weeks max I think !

I made a fix for this: https://github.com/vatesfr/xen-orchestra/pull/9228 I'm not that familiar with disaster recovery, I'll discuss your point with the team. b-Nollet opened this pull request in vatesfr/xen-orchestra open fix(backups): fix offlineBackup value #9228

It doesn't work in my case, even though the replicates have different MAC addresses "netboxError": [ { "address": [ "Duplicate IP address found in global table: xxx.xxx.xxx.xxx/xx" ] }, {} Have you done something appart from changing the MAC address?

@Chico008 I think it's not a bug, it's a feature.

@probain No worries, im still learning/improving my ansible/terraform skills aswell

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