@bvitnik You're right. I added a lot of details, but neglected to mention that I'm not booting from USB. I'm really not convinced I've destroyed my system. I truly think that's an over-reaction. I think I ruined my initrd and initramfs files, yes. But that should be recoverable. I haven't done nearly as much as you think I have. The reason I haven't succeeded in that yet is because I'm not really convinced I've been doing it the right way. Since my my disks run in RAID, my system has like 6 partitions. md127p1 md127p2 md127p3 md127p4 md127p5 md127p6 From memory, p1 and p2 are very similar. However p1 doesn't include grub (/boot/efi/EFI). P4 is grub. P2 looks very similar to p1, but it includes grub. P3 is my VHDs. P5 is maybe swap, and I can't remember what the other one is. My point is that I don't believe that I've mounted everything correctly through the shell in order to be able to successfully chroot into the device and be able to run the dracut commands successfully. When I run the dracut commands, I see failures for applications that I can see in the sbin folder. So there is something that I'm missing in mounting these disks in the shell that is preventing me from solving this issue. This is why I'm here. I'm not here for lectures about the dangers of USB. Alternatively, I could boot the install media and simply perform a metadata/pool restore from backup, but I just want someone to tell me that's an actual viable option. I'm not going to simply re-install the OS. If I do, I'll clone it first, and then boot the clone and test a metadata restore. But that's a lot of work for it to fail.

@bazzacad you do not seem to have the same number of PIFs in each host I wish you do not have to, but you can swap names if needed, read the doc here https://docs.xcp-ng.org/networking/#renaming-nics

We'd recently got a relevant experience regarding this weird renaming to uuids. We had one orchestra managing one pool. ISOs were in an ISO SR, with an nfs4 serving it underneath. All fine till then. We added one second pool to the orchestra. Just a single host by itself. One of the very next days we discovered that all names in the ISO SR had been replaced by uuids. Removing/readding the sr to the new pool helped temporarily. Usual names appeared again. But after a few more days, again uuids. Where uuids were appearing, we could not select anything from the dropdown list in the console's cdrom. The list per pool was unpopulated. We tried separate the shares by offering the new pool an nfs4 share from the NAS, actually sharing the same source dir. It did mount but now there was a uuid uniq constraint that was violated, so we could not see no files at all in this new SR. It would not be an illogical thought to have an 'iso sr' attached once to the orchestra and be offered by the orchestra to all managed pools, without uuids, without uniqs etc. There seems to be an unnecessary complication here I think.

Adding @clemencebx for review/ideas on this;

So I actually posted these findings to the ZFSBootMenu Discussion github: https://github.com/zbm-dev/zfsbootmenu/discussions/787 Looks like they have tested ZBM against KVM but not Xen. Can Xen not handle a kernel being kexec'd?

@nikade indeed, customer will have limited view on that. resellers too, they will manage a quota of ressource and dispatch ressources like CPU/ram/disk /bandwidth amongst their clients. VM création is already auto-dispatched to the more appropriate host in term of load and vcpu to cpu ratio. vdi distribution is based on available luns with respect of free size available. to not saturate the SRs.and distribute evenly. my screenshots are from Global Admin view, we can see all info and force some choices.

@olivierlambert I'd like to see replicated vms in netbox, perhaps not syncing their IP address to avoid conflict DR VM as well

Hi, I was about to suggest to use backup health check but it seems you'd like to avoid it In this case, I don't really have an answer, maybe @Bastien-Nollet or @florent does.

I haven't had too much difficulty hitting the esc key in time to get into the EFI config. Click the start VM button, quickly click away from the display area and click in the display area, then toggle the esc key until I see it take effect. I know I have a couple running at 1920x1080, but that's actually kind of a pain. I only did that to try and get a larger RDP window, RDP may be limited by the original "monitor" resolution, but this might also be fixed in later updates. This one VM has been up for a few years. (edit, yes this has been changed, VMs with a 4x3 monitor now RDP is whatever I have set).

[edit] I just realized this was from 2024. So far I only have 1 of my 2022 servers changed to the XCP-ng drivers and management agent, the only thing that happened was the NIC went back to DHCP and a short struggle to shift it back to static. I use the e1000 profile when I set up a VM. This was previously using the Xen 9.4.x drivers downloaded from Xenserver. The only other glitch is that if you migrate the VM to another host in the pool, the management agent is no longer detected. But additional migrations and rolling pool updates and reboots are not bothered by this. I'm told this will be fixed in the next version. As far as the drivers themselves, I don't see any issues on this one VM. I think I have another 2022 in my lab with the XCP-ng stuff installed, I'll have to check later. I've had no issues with it. These were both installed from the new Tools ISO that is default with the latest XCP-ng 8.3.x

@Forza I keep hoping to see an Alpha or Beta of XCP-ng 9 soon, but I think there is still a lot of work to be done on the host side and on the Xen Orchestra 6 side.

@k11maris Same on my side. Delta backup for all VMs show this message. [image: 1763710321097-bildschirmfoto-2025-11-21-um-08.30.44.png]

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

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!

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

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

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