@MajorP93 that's nice to hear taht it, at least solved the issue are you using a xoa ? or a compiled fro source ? what is the user that run the xo service ?

@Greg_E Theoretically yes. I've never been in such situation so I would have to learn, experiment and improvise along the way. If you can mount the file system of the host, you can find XAPI database in this location: /var/lib/xcp/state.db This is an XML formated file. I don't know if this is the same format as metadata backup (I think it's JSON instead). So you could possibly restore this file to proper location and restart the host but you would probably need to change some references in it, like UUIDs of local file systems on a freshly installed system. Other possibility is that the state file could be converted to metadata backup and imported but I'm not aware of there being any such conversion tool. It would have to be improvised. There is always alot you can do. It just depends how deep you want to go, how complex you can go and how much time you can spare.

Hi @cbaguzman, Currently there's no way of performing the vhd-cli check command on an encrypted remote, but this is also annoying for us and it shouldn't be too hard to fix, so I'll fix it.

@dnordmann @tsukraw thank you for your patience, we found something while working with the xcp storage team, and there is an issue with the last block size Can you confirm that the failing VM has at least one disk with a disk with a size not aligned with 2MB ? Could you test this PR on the failing import ? https://github.com/vatesfr/xen-orchestra/pull/9233 regards fbeauchamp opened this pull request in vatesfr/xen-orchestra open fix(nbd-client): nbddisk must emit full size block #9233

Adding @florent and/or @Bastien-Nollet in the loop

@acebmxer Did you do: cloud-init clean --logs --seed before converting the VM to template? Also, network configuration is not part of the cloud-config (aka user data). In XO, there is a separate field called "Network config" where it should be specified. See examples at the end of the guide I pasted earlier. network: key should also be removed (commented in the examples).

Adding @gregoire in the loop

@Pilow alright, cool! that sounds pretty much like a standard solution, too much options or details usually just confuses the end users

@bazzacad great, glad it worked for you

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?

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

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!