thx i will try it soon

Just updated my homelab server from XCP-ng 7.6 to XCP-ng 8.0 Beta, so far so good. I also tested the new experimental UEFI mode with Windows VM, seems good too. I also tested the new XOA deployment through the Web interface of my host, perfect ! We will see during the following week how it goes

Check if those VM got auto restart in their advanced tab.

Just a guess, but there may be a coalescence process that needs to run, which updates the views where you are seeing this "wrong information". Does the issue persist if you delete a few backups and then wait a few hours and look at the report again?

That's why I thought. NEVER enable base repo. If you want a package from their, just enable it during the yum install command line.

Since ZoL 0.8 is here, supporting O_DIRECT, everything might just work out of the box. We'll try it and report

Okay thanks. Note that with XCP-ng 8.0, it will be even easier to deploy XOA, directly from the host HTTP URL "mini website".

No one raised their hands, and yet an update candidate for 7.5 is available with the fixes backported from 7.6. Install it with yum update --enablerepo='xcp-ng-updates_testing' microcode_ctl xen-dom0-libs xen-dom0-tools xen-hypervisor xen-libs xen-tools We've tested it locally, works fine for us.

@olivierlambert @prilly Just loaded the XCP-ng 8.0 successfully on a Dell C6100 with 2 x L5630. No errors during install, and boots up just fine for use.

@pdonias Thanks for confirming that this issue wasn't caused by the use of a 3rd party script.

Those are likely "base copy". If it's the case, it's normal because they are "parents" of a VDI chain (snapshot, active disks etc.) What you can probably safely remove are orphaned disks.

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: define vApp for autostart in xcp-ng center including start order find out the uuid of the vApp: xe appliance-list write autostart script containing #!/bin/sh xe appliance-start uuid=uuid-autostart-vApp 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 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.

Hi, Before reporting on issues when you use XO from the sources, you must always fetch the latest code available on GitHub. Because it's likely some issues are fixed since then. Please upgrade, and come back if the problem persists

Reviewed my server versions after rolling back to 7.6.3.20, that was a misunderstanding on my part. It's just 6.5 that we are primarily running that is now incompatible. I was mixing that up with another hypervisor's versioning system.

We're deploying support for the incoming release channels and there was an issue with that.

@maxcuttins oops

How about doing your own matrix?