@dinhngtu

Thanks and good point. After my previous post I did stumble across some info (can't find the links) that suggested something similar. If I'm remembering correctly, the basic idea was the flash/NVRAM memory on the motherboard, which stores boot entries, is limited. If it's full, it's possible / may be necessary to do some cleanup using the bios itself or utilities available for Linux (efibootmgr) and Windows (bcdedit).

I've not tried this myself as our install is working properly, but perhaps that can help someone else in the event they stumble across this particular issue.

@olivierlambert @laurentm

I know this is an old thread. That said, I ran into this identical issue on some older Dell R720's. I was able to work around the issue as follows:

1. Enter the servers bios (F2). Go to System Settings -> Boot Settings and make sure boot mode is set to "BIOS".
2. Save settings and reboot. While booting press F11 and choose "UEFI Boot Options" and select your thumb drive from the list of boot devices.
3. Perform the XCP-NG install. It "should" finish without giving the "unrecoverable error". Reboot once installation is complete.
4. Again enter the server bios (F2). Go to System Settings -> Boot Settings and make sure boot mode is set to "UEFI". Save and reboot.

At this point the server should boot normally and should now be using UEFI. If you do not switch the bios to "UEFI" in step #4, you'll get a funky GRUB C prompt.

Hope this helps someone out there.

@Andrew

Thanks for clarifying again. I had missed that.

I see the option in the schedule, but it's only a checkbox. My guess is you have to combine it with the Settings -> Advanced -> Full Backup Interval input? It's not clear from the docs if those two things are related or separate.

I have mixed feelings about the deltas. There's clearly some thought on the part of someone that someone may need to do the deltas-forever thing due to the ability to create an initial seed for a remote site due to bandwidth constraints. In my case this is a remote NFS store, but it's a low latency (~5ms) and high throughput (1Gbps) connection so it's not too onerous to do a full periodically.

At the end of the day, I've ticked the "Force Full Backup" checkbox and put a value the same as retention in the advanced settings. We'll see how it goes.

I'm still puzzled by why this is a recent issue and didn't used to exist. Also it would be nice if there was some graceful timeout or something that will kindly bring the replication to a close in the event that no data is being transferred for a prolonged period of time.

@Andrew

Thanks for the response. In my case, the CR and the delta backups run as separate jobs, on different schedules, with different retention. It's my understanding that CR is delta by nature and that's not really an option to do otherwise. Essentially an initial full, subsequent deltas, and then coalesce depending on retention.

How are you automating a full base once per week under CR?

Yes, there is plenty of drive space available (1.2TB) and a delta is only MB to a couple GB.

I'm wondering if anyone else has had an issue with continuous replication not finishing? Starting sometime around October, CR jobs that had been running unchanged for 1-2 years started having issues. Ultimately one, and on rare occasion, two VM's will never finish their transfer (see screenshot). They remain in the transfer state indefinitely or until xoa process is restarted.

As a consequence, all future runs fail as the job believes, rightly so, that the previous job is still in progress.

There doesn't not seem to be any pattern between which VM it fails on. I've tried re-basing each VM, by removing all CR VM's for a given VM, making sure no files for said VM exist on the SR, and then re-creating the initial full. Regardless, sooner or later CR will time out again.

FWIW, I also run delta backups to the same SR and have no such problems. It's only with CR and only for the past few months.

I know I've seen a related post to this, but I'm struggling to find it again. I'll keep searching and add it to this thread once located.

I'm running from source and will typically pull the latest version 1-2 times per week, looking for updates that may resolve the issue. Currently on the following versions.

Xen Orchestra, commit b0846

xo-server 5.106.1

xo-web 5.107.0