@julien-f @olivierlambert
2371109b6fea26c15df28caed132be2108a0d88e
Fixed now, thanks you.

After bunch of last fixes i removed some broken backup chains and now all errors gone. Thanks.

@florent it begins few days ago and increase every day. Probably after backup tasks - most of them happens at night.
Update itself don't change this number.

commit 41bb1
After last patches of backup refactoring i got some orphan backups with new reason Missing schedule.
92 yesterday, 184 today.

What is this?

i can say that timeout option is still ignored. Also after last backup refactoring commits.
Some of my jobs hangs almost every day. I'm going to test how it will works with 1 remote + mirror instead of 2 remotes backup.

@olivierlambert to not create new topic, small continue here.

timeout option still ignored.

probably because of network problems i got backup error and job hangs every day.
doesn't matter why it happens, but job will never get terminated by timeout.

21h job with 7h timeout. https://pastebin.com/U5HgKEzM
just 1 Gb.

i setup scheduled task to reboot xo once a day, to close this endless tasks.

my config is fine, but problem still here for this one pool.

i don't understand what happens.
Reinstalled xen to 8.2.0, CR was succeed for few times, but now i got this error again.

Tried few tests - 2-3 fails in row then it succeed again.
Only way to never use this pool for CR.

well, i'm just made some tests and got some result. Have no idea how it should work)

i mean it could be XO issue, since it not communicate with xen. Otherwise it should write some logs.

if i have no smlog - xen\dom0 not related with backup task. right?
smlog that usualy i got during this 5min have no any errors anyway, only some locking operations.
And it always takes 5min, some hardcoded timings?

don't forget that problem also happens with FC connection, so it may concern any block based storage types.

@olivierlambert
sr_not_supported that not a error and not a reason. That because of default multipath Dell config for 3xxx series. Persist at 8.2.0 where CR working, so that just a warning.
As we have no any problems before, we never investigate to this setting. My bad again yay.

Replaced it to official for 4xxx and this warning gone. I see at 8.3 it already more universal for any generation.

        device {
                vendor "DellEMC"
                product "ME4"
                path_grouping_policy "group_by_prio"
                path_checker "tur"
                hardware_handler "1 alua"
                prio "alua"
                failback immediate
                path_selector "service-time 0"
        }

since it no default config for huawei, so we always used the official one.

        device {
                vendor                  "HUAWEI"
                product                 "XSG1"
                path_grouping_policy multibus
                path_checker            tur
                prio                    const
                path_selector           "round-robin 0"
                failback                immediate
                fast_io_fail_tmo        5
                dev_loss_tmo            30
        }

• 8.2.1:

• CR not working:
  both huawei, dell iscsi - multipath enabled
  both huawei, dell iscsi - multipath disabled

• working:
  nfs vm disk
  local thin\ext
  local thick\lvm

• 8.3

• working:
  both huawei, dell iscsi - multipath enabled
  local thick\lvm

and now interesting. After i solved this false warning, detach extra hosts from pool, detach all additional links (trunk, backup) to decrease comunications and log itself - it's no any SMlog generated during backup task.

MP enabled - with 2nd link for backup https://pastebin.com/URcnDckR
MP enabled - only Mng link, no SMlog generated https://pastebin.com/RHw40uzg