@bazzacad great, glad it worked for you

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

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

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.