@bazzacad great, glad it worked for you

So I have had some more time to play around with this, and I think I got it working except for one part. After I convert the vm to a template and go deploy new vm with newly created template. Even if i put in the network config as such. #cloud-config network: version: 2 ethernets: enX0: dhcp4: true dhcp6: false set-name: "enX0" The new vm does not get IP address. When i log into new vm it does not have /etc/netplan/50-cloud-init.yaml with the above network config. If i manually create the file with the above config and reboot the vm gets an IP address and a different one then previous vm

@nuentes Oh no, no. Your system is not destroyed beyond repair. It can be repaired. It's just that it is almost impossible or too much of a hustle for anyone to try to help you over forum. Someone has to sit in front of your machine to do it. My only guess is that ChatGPT instructed you to make changes based on a CentOS system but XCP-ng and Xen virtualization in general is much different than regular CentOS. It has two stage boot process. First the Xen kernel boots and then a special virtual machine called Dom0 is booted. What you are accessing and reconfiguring is in fact this VM, not the underlying "system". So it's like a two layer system and some configuration must be done on Xen layer, some on Dom0 layer. I'm unfortunately unfamiliar with exact specifics on kernel and initrd image generation for this case so I can't spot where thing have gone wrong. In short terms. Instead of going back and forth and trying a lot of different things, it's more time saving and simpler to reinstall the system and restore metadata if you already have a backup.

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