Hi!

The first reflex when you have an issue is to check:

Pre-requisites: https://xen-orchestra.com/docs/installation.html#packages-and-pre-requisites Being up to date

In your case, it was 1 🙂

Note: Node 20 compatibility will come soon but it doesn't mean 1 & 2 should be done before anything else 🙂

Also, nice catch @Danp 😉

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.

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

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

ab68fa1c-49a8-4d15-afcf-ecdc8bcd9d04-grafik.png

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

Any ideas for a more elegant way than to write a script? For my point of view vApps should work without HA mode but unfortunately it doesn't work on my XCP-ng server. Only console/script start of the vApp using

xe appliance-start uuid= "set here the uuid of the vAppp"

is working. But it is again rework for the next XCP-ng version, I think manually set vices in systemd are not persistent through an update. Will vApp supported also in future? there are some discussions about it, if really needed.