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.

Dear all,

I've got a suspicious topic about reporting of free space of backup HDDs. First of all my system:

• XCP-ng latest version incl. all updates
• XO from sources, latest version

First of all, the vm backup is working as expected, no issues with non-working backups.

About the backup situation:

• raid1 HDD (each HDD 1 TB) for backup as local drive on XCP-ng
• vmbackup connected to XOA via additional disk
• vmbackup formated in XOA with ext3 or ext4 (doesn't make any difference for the issue)
• vmbackup path defined as "local drive" in "remotes setting page" of XOA

Issue: remaining free space on backup drive is not reported correct (used / free)

• report of XOA "remote settings page": 297.86 GB / 856.13 GB -> these are the right values
• report of XOA "disk page of VM": 37.87 GB / 870.8 GB -> wrong after deleting some backups
• report of XCP-ng "storage": 37.87 GB / 870.8 GB -> wrong after deleting some backups

The issue seem to be if removing some backups, the free space is reported within VM page in the right way (also "df" show the right values), but the remaining space after deleting is not reported back to XCP-ng?

Has anyone an idea about the issue?

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.

my solution for now:

• implement new vApp
• writing start script to start vApp-uuid after boot

By the way, the start delay feature edits the time delay between two start up groups of the vApp feature.

Is it possible to turn on HA mode on a single machine Setup?

The topic you mention is using vApps or high availability.

I mean this quite new feature "Start delay (seconds), programmed the last days in XO:

Do I need to define a HA mode?

Hi all,

there is a new feature available in XO to set a defined time in seconds to delay the autostart of a VM.

For details about the new feature can be found here: implementation of start delay for VM - issue #3909

It seems the parameter is also set in the VM correctly. Here is a shortened part of result of xe vm-param-list uuid=...:

                     live ( RO): true
            guest-metrics-last-updated ( RO): 20190313T06:38:53Z
                   can-use-hotplug-vbd ( RO): unspecified
                   can-use-hotplug-vif ( RO): unspecified
              cooperative ( RO) [DEPRECATED]: true
                                  tags (SRW): 
                             appliance ( RW): <not in database>
                     snapshot-schedule ( RW): <not in database>
                      is-vmss-snapshot ( RO): false
                           start-delay ( RW): 240
                        shutdown-delay ( RW): 0
                                 order ( RW): 0
                               version ( RO): 0
                         generation-id ( RO): 6481430157605823834:6102110844557853395
             hardware-platform-version ( RO): 0
                     has-vendor-device ( RW): false
                       requires-reboot ( RO): false
                       reference-label ( RO): 

I tested with 2 VMs:
VM1: auto-start enabled with 0 seconds boot-delay
VM2: auto-start enabled with 240 seconds boot-delay (see above)

What is happening:
Instead of starting VM1 on boot and start VM2 240s later, it happens that VM2 is starting immediately and VM1 is started an undefined time later. For my point of view, XO implementation is working but there is something not working in my XCP-ng installation.

Can anybody help?