Pool is resource pool, yes.

pool can consist of multiple hosts which can live migrate VMs

Server = host

@olivierlambert Sorry, meant to reply earlier. I'm on source, commit 1643d.

So there's an issue when there's so many drives it seems. We'd like to have private access to this OVA to try to see what's going on.

Good news then 🙂

Please provide the config output of your template (xe template-param-list uuid=<template UUID>)

Not everyone is affected, and not everytime either. Otherwise, we would already have done something. As you can see, it's pretty calm here since 6 months.

That's why it went down in our backlog. For our next XOA release (a fresh new virtual appliance with everything already updated) will be likely released with a US based mirror.

@andrewreid Not that this helps with your error, but my nightly S3 delta backups to Wasabi have been working just fine. I'm using XO source and keep mostly up to date with master.

S3 and NFS are different backup formats so NFS working does not mean S3 will work.

Sometimes Wasabi causes failures but not recently and not that last more than a few VMs in one night. The next backup run (manual restart or next nightly) seems to work correctly.

I force a full backup every 3 months just to make sure I have a good checkpoint in case undetected corruption creeps into the delta data. Plus I have replication and other backups.

I did have a problem once (not exactly yours) with a VM and just deleted the S3 backup data which forced a full backup again. Sucks because you don't have the weeks of deltas anymore.

Error #3 (date-time) is strange. May be a backblaze issue.

You could create a new S3 remote to backblaze (new bucket or directory) and test one failing VM backup to the new remote and see if it works (and works again for delta). You could set the retention low to test merge too. I have a setup like this with a local MinIO server for S3 testing and local backups.

@florent Looks like they're all during the transfer phase, usually it's this error:

EINVAL: invalid argument, open '/run/xo-proxy/mounts/fbd663b9-57f1-4610-ae32-3f1d69fea68d/xo-vm-backups/f92970cd-523f-3915-7254-5f0b4a37d713/vdis/1d5ddf64-2165-4d26-b05c-330546b48ee0/69786d14-81ea-446c-8870-e43dfedae766/20220622T050722Z.vhd'

I did have an HTTP time out last night for 8 / 12 VMs, but 4 backed up just fine which seems odd, the VM was up the whole time.

This is backing up over a proxy to a TrueNAS system local to the proxy, but my home backups also running over a proxy to an unRAID system are running fine.

I could be off the mark here, loving XCP-NG and XO so far though!

haha that's exactly the purpose of the remote test button 😛 No grand mastery, just experience 😉

@olivierlambert I want to move them on NFS in order to be able to backup later from NFS to S3 in more granular way 🙂

Generally, we are talking about XO - NFS. S3 would be out of XO.

Hi does the Backup job still create the Snapshot (and therefore required time and space) when not doing an offline backup or has this been improved by now ?

@someone2b Just install this work-around xenstore-read with the following commands and hopefully it will work.

sudo -s cd /usr/local/bin curl -O https://gist.githubusercontent.com/julien-f/a6f98de3bd5a775f3f04b2fa14a9a102/raw/xenstore-read chmod +x xenstore-read

@Darkbeldin Excellent thanks a million 🙂

Hi,

This is documented. https://xen-orchestra.com/docs/xoa.html#first-console-connection

Just if somebody else is searching for the same thing, although it is not directly related to XOA:

If you want to get these alerts by mail and you are not using XCP-ng-Center, you can activate them with:

xe pool-param-set uuid=pool-uuid other-config:mail-destination=mail@example.com xe pool-param-set uuid=pool-uuid other-config:ssmtp-mailhub=mailserverip:port

KPS

@geoffbland No problem. 🙂 It's the first time I see this error with tapdisk (and it's it's even more surprising to have it on this type of SR...).

It had all been working fine and I had not changed anything on the share - it just stopped working

In this case, maybe there was a problem with the XAPI, a lock on the device or something else. Not easy to find the cause without remote access. Don't hesitate to ping us if this problem comes back. 😉

@florent It might also be worth looking into why the XO OVA export function created a file that had problems importing.