Great job, worked perfectly! Thank you very much for your fast support!

Ok, found the value, „xapi_build: 25.27.0“

How can I upgrade to this special version?

So just for my understanding. For restoring a metadata backup or maybe also other backups I need the correct XAPI version, but a XCP-ng user is not able to select/control the needed version? Sounds lika a chicken-egg-problem…

Is it not possible to have a new .iso-Image, whenever such updates are provided? It would be an easy way on case of new Installation.

No the old pool is fully gone. There was a risk for compromised network incl. hypervisor password. So the pool is destroyed. VMs are still available or available by backup. Need to access some of them without network to backup so data and to re-install win11-VMs without new activation. For the win11-VMs I need all the settings/data not only the VHD disk file.

And possibility to upgrade to different xcp-ng-versions for restore? At the moment the hypervisor is at latest 8.3 .iso -> so at least I think I Need to update to the latest version before 09/12/2025.

@danp Restoring with installation from latest .iso the error was different. Don't remember the exact failures, but there was a statement about "missing columns". Searching the forum brought me to your post in 06/2024 to apply all the available patches. Patched then with "yum" and 155 packages were updated. Then the new failure with "restore incompatible version" came up. Due to missing XO capability that moment, I did the update using command line, maybe that's the failure?

Dear all,

I needed to do a complete new installation of xcp-ng 8.3 LTS. I have backups of all VMs incl. the pool metadata. The latest daily backup was done on 09th of December and now, if upgrade the fresh installed xcp-ng to v35 release, the metadata backup can't be restored. Either by XenOrchestra or with "xe pool-restore-metadata" the restore is possible, always same error: "failed: restore incompatible version".

Any ideas what I'm doing wrong?

Dear all,

I'm using xcp-ng 8.3 and I'm trying to update Win11 VM version 23H2 to 24H2, but the VM fail to boot. The Win11 VM is automatically reboot during update as it should and then starts upgrade until 30% reached. After next reboot the VM hangs up showing the blue window sign and the moving circle. Waiting a few hours, still no change.

After automatic update roll back error 0xc1900101 is shown. It seem to be a generic error, but

• enough space is available (39gb free space)
• citrix drivers up to date, version 9.4 is used
• no system critical software like anti-virus, ... is used
• no special features like pass-through hardware

Tried the update with and without secure boot. Does anybody has an idea what I can do to upgrade?

Great, node version 18.18.2 seem working again!

Thank you very much

Dear all,

after upgrade to version 5.125.1 / 5.127.1 the connection to xcp-ng is only stable for a few seconds. After connecting for a few seconds the connection to the server is droped and no reconnection is done. Only "disable" and "enable" in server/settings the connection is stable again for a few seconds. Then dropped again. Any ideas?

The only thing is to think on that script during a major update of xcp-ng to a newer version. Because after installation the autostart.service has to be implemted again.

I don't really remeber about the solution, but assume I deleted the old logfiles too. I did never observe the same failure again.

I'm also running xcp-ng on a Supermicro X11 with a XEON Silver 4210 CPU.

Hi all,

got some weird "crypto_comp_decompres failed" messeges during boot of XCP-ng. Does anyone no if it matters or not? Investigated this for the first time.

Some internet search stated to delete old logfiles in /sys/fs/pstore, but not sure if this helps.

Thanks and best regards.

Just goto your VM -> disks -> button on right side with "boot order" -> boot order can be set by drag/drop between the shown possibilities.

I switched due to SSD replacement and XCP-ng new installation. I didn't think about that switching from ext3 to lvm does also have an effect from thin to thick provisioning

Anyway I found the explaination, here -> "a snapshot on a LVM based SR will double the whole VM disk size!"

But I will think about to switch to ext4 -> topic solved, thank you!!

Yes for sure, but in the past the snapshot didn't stay on the local storage drive with the full volume. Don't know what is different now. I did run delta-backups over a year now without any topics. In the past I used ext3, now using lvm, does this make any difference?

Second issue seem to be that there is now "no remaining space" reported, but the drive has ca. 50% volume free...

ok understand, thank you!

But why is the behavior different? Here is an example what's happening at the moment:

1. restored some VMs, local storage is 150GB free space, local storage as LVM
2. new daily backup via XO as delta-backup
3. after 1st delta-backup (which is a full backup, because no previous one), a full snapshot of ca. 50GB is left on the local storage; backup-drive is a different one
4. local storage is running out of space!

Why is this happening? In previous versions there where no remaining snapshots on the local storage left.

Hi all,

I'm using XO from the sources. After update to 5.51 (xo-server) and 5.50 (xo-web) the "backup NG" is gone, only "backup" is available now.

If I'm runing a daily delta-backup, the delta-backup-files are stored to the remote backup share but the local-storage is flooded with a snapshot-file. The snapshot-file is not deleted and the local-storage run out of capacity.

Can anybody help?

that's relatively easy to explain, only the naming is doubled:

• the backup-hdd are local disks raid1 in xcp-ng and there brought to xcp-ng as a local "vmbackup" volume, called vmbackup
• on xcp-ng-volume a disk is created with the name "backup_raid1_1tb" and connected as 2nd disk (xvdb) to XO

• to make the disk available for backup-usage the disk xvdb is mounted via "remote" as a local
• now usage for backup-ng is possible, but the usage is not xo_disks

Deleting updates does show no difference, it is never updated, even waiting for some days. Also a reboot does not make any difference.

screenshot from "remotes" in XOA:

screenshot from "storage" of host:

If setting up the share completely new, free space is reported correct. After deleting old backups, free space is only correct in remotes.

unfortunately "start delay" is not working as expected. The function what you marked above is to change the start delay of an existing "vApp". Here is an example of my setup:

The value whould change the "Delay interval" later by XOA, nothing else. Otherwise is vApp feature also not working on my XCP-ng installation, I think it was never really tested.

If you want to implement start delays to your VM's you can follow this guide:

1. define vApp for autostart in xcp-ng center including start order
2. find out the uuid of the vApp:

xe appliance-list

3. write autostart script containing

#!/bin/sh
xe appliance-start uuid=uuid-autostart-vApp

4. implement new systemd.service in /etc/systemd/system/autostart.service

[Unit]
Description=autostart script for boot VM
After=graphical.target

[Service]
Type=simple
ExecStart=/path/to/your/autostart-script.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target

5. enable the service

systemctl enable autostart.service

Editing of boot delay time is then possible via XOA which is already a nice feature at all for "fine tuning" or adapt if new VMs are added to the autostart vApp.

@olivierlambert whould it make sense to open an additional feature request? vApp-implementation was several times discussed with no "final statement" I think.