xapi-project / xen-api / 31574617646
79%
master: 79%

LAST BUILD BRANCH: private/changleli/lldp-neighbors
DEFAULT BRANCH: master
Ran
Jobs 1
Files 36
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: 78.996%. Remained the same
31574617646

push

github

web-flow 
Start SM service after dbsync to avoid startup deadlock (#7179)

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

3667 of 4642 relevant lines covered (79.0%)

0.79 hits per line

Jobs
ID Job ID Ran Files Coverage
1 python3.11 - 31574617646.1 36
79.0
 GitHub Action Run
Source Files on build 31574617646