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!

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.

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.

@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

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

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

@bazzacad great, glad it worked for you

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

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?

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

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

https://forums.veeam.com/kvm-rhv-olvm-pve-schc-f62/xcp-ng-not-showing-as-virtualization-source-after-restore-t101040.html Et voilà suffit de demander

Adding @clemencebx for review/ideas on this;

@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

@Bill.Oliver license-wise should be the same. now I think virtualisation gurus here could try to explain you what are the challenges with numa and dual sockets i have notions, but couldnt explain quite the optimisation in xen

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

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

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.