I haven't had too much difficulty hitting the esc key in time to get into the EFI config. Click the start VM button, quickly click away from the display area and click in the display area, then toggle the esc key until I see it take effect. I know I have a couple running at 1920x1080, but that's actually kind of a pain. I only did that to try and get a larger RDP window, RDP may be limited by the original "monitor" resolution, but this might also be fixed in later updates. This one VM has been up for a few years. (edit, yes this has been changed, VMs with a 4x3 monitor now RDP is whatever I have set).

[edit] I just realized this was from 2024. So far I only have 1 of my 2022 servers changed to the XCP-ng drivers and management agent, the only thing that happened was the NIC went back to DHCP and a short struggle to shift it back to static. I use the e1000 profile when I set up a VM. This was previously using the Xen 9.4.x drivers downloaded from Xenserver. The only other glitch is that if you migrate the VM to another host in the pool, the management agent is no longer detected. But additional migrations and rolling pool updates and reboots are not bothered by this. I'm told this will be fixed in the next version. As far as the drivers themselves, I don't see any issues on this one VM. I think I have another 2022 in my lab with the XCP-ng stuff installed, I'll have to check later. I've had no issues with it. These were both installed from the new Tools ISO that is default with the latest XCP-ng 8.3.x

@Forza I keep hoping to see an Alpha or Beta of XCP-ng 9 soon, but I think there is still a lot of work to be done on the host side and on the Xen Orchestra 6 side.

Ping @Team-Documentation-Knowledge-Management

Hi @jshiells, After some tests, I don't think it can be caused by the load balancer. If the load balancer tries to migrate a VM that is being backed up, the migration instantly fails and nothing happens. Reversely, if a backup job starts when a VM is being migrated by the load balancer, the backup will fail for that VM with error "cannot backup a VM currently being migrated".

I think it's planned for XO 6 adding @gregoire in the loop

On the bottom of each documentation page, there's an "Edit this page" link you can use to contribute

@florent Sorry for the late reply, yes, we had previously tried that setting and found that it did not provide any speed increase in our case. One thing to note is that we do have our backup jobs configured to merge backups synchronously, we're starting to test some of our jobs with that setting disabled. We had originally turned it on because we experienced a lot of backup failures due to locking errors. We've since added additional proxies as we've found that the amount of data that a single proxy can backup in a nightly window was the primary bottleneck in our environment. Since adding the additional proxies we've started disabling the synchronous backup merge for several of our jobs and so far it has been working pretty well and our backup times have been running faster (obviously since the final merge was the vast majority of the time that we observed in our backup steps).

Starting from Other install media with BIOS (not uefi) is the only combo that is working with Terraform

xe pool-enable-tls-verification Was exactly what I needed, thanks! Worked after that.

@Joe_dev I have a MF unit with similar igpu. I was not able to get it working under any virtualization platform. There is something about amd igpu that makes passing it hard. I believe some have had it working under proxmox with custom kernel and video bios. I never bothered trying all that out so i just gave up on the unit.

@joeymorin try to check the merge backup synchronously to avoid other jobs messing with this one ?

Maybe that's my issue ? Investing this part # journalctl -k | grep -i nvidia [image: 1763219509282-aaed86b6-1384-434e-ac5d-bca510405f33-image.png]

@Danp My apologies for not being more specific. I’m encountering an issue with XOA deployment on a home lab environment. Environment Details: Installation source: USB Hardware: 16GB RAM, 1TB NVMe HDD Initial install: Completes successfully Dashboard: Displays expected status Steps Taken: Installed XCP-NG from USB — installation and setup completed without errors. Verified dashboard — all components appeared healthy. Deployed XOA to the existing HDD — process executed as expected. Observed Behavior: After deployment, XOA appears healthy overall, but the final item labeled “NEW” does not appear in the interface. Expected Behavior: The “NEW” item should be visible after deployment. Mark

@k11maris Same on my side. Delta backup for all VMs show this message. [image: 1763710321097-bildschirmfoto-2025-11-21-um-08.30.44.png]