xcp-ng / xen-api / 31591674110
80%
master: 79%

LAST BUILD BRANCH: gtn-split-quicktest
DEFAULT BRANCH: master
Ran
Jobs 1
Files 34
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 80.459%. Remained the same
31591674110

push

github

gthvn1 
[backport] Start SM service after dbsync to avoid startup deadlock

The patch fixes an issue that can happens if a VDI operation fails on a SR and
keeps the lock. In such case the XAPI can be blocked during the startup. Here
is the scenario:
- Xenopsd and XAPI are restarted
- Xenopsd is looking for existing VBDs and check with hypervisor the status. If
  it needs to be destroyed it pushes a message DP.destroy2 on
  org.xen.xapi.storage queue.
- XAPI starts, nothing listens on the queue
- At some point a thread is started and handle the message posted by Xenopsd.
  Plugins are not yet loaded so an error `No_storage_plugin_for_sr` is returned
  to Xenopsd. Xenopsd will retry in 5s.
- XAPI continues to boot and sync its database:
  - sync_pbds: it is where SMAPI plugins are setup and now we can handle the
    message to destroy the VBD
  - And here there are more syncs: sync_pci_devices, sync_pif_params, ...
  - until sync_local_vdi_activations.
The deadlock can happen here. If it takes more than 5s to reach the sync of
VDIs, Xenopsd has time to post its DP.destroy2. The message is handled by XAPI,
the lock for the VDI is taken and the SM plugin is called. We see in production
that the operation never returns and so the lock is never released. When XAPI
call sync on VDIs, it will sync the VDI that has the problem. And it will wait
for the lock preventing the XAPI to start correctly.

So this patch moves the registration of the queue (Storage_access.start) after the
synchronisation of the XAPI database. Pending messages remains in the queue and
the sync of VDIs asked by XAPI database update process during the start can be
done. Of course the problem with the VDI is still there but XAPI can now start.

Tracking-reference: XCPNG-3515
Signed-off-by: Guillaume Thouvenin <guillaume.thouvenin@vates.tech>
Backport of PR #7179
(cherry picked from commit 246390b58)

3504 of 4355 relevant lines covered (80.46%)

0.8 hits per line

Jobs
ID Job ID Ran Files Coverage
1 python3.11 - 31591674110.1 34
80.46
 GitHub Action Run
Source Files on build 31591674110