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.

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