CA-402901: Update leaked dp to Sr

[changlei-li]

When add leaked datapath:

1. add leaked datapath to Sr.vdis
2. write to db file
3. log enhance

If there are storage exceptions raised when destroying datapath,
the procedure fails and the state of VDI becomes incorrect,
which leads to various abnormalresults in subsequent operations.
To handle this, the leaked datapath is designed to redestroy the
datapath and refresh the state before next storage operation via
function remove_datapaths_andthen_nolock. But this mechanism
doesn't take effect in current code.
This commit is to fix this bug. leaked datapath should be added
to Sr.vdis to make the leaked datapath really work. And write to
db file to avoid losing the leaked datapath if xapi restarts.

[changlei-li]

Ring3: BST+BVT passed

[minglumlu]

Just to help myself to understand...
This is only for SMAPIv1.
There are two cases in which the destroy_datapath_nolock will be called:

1. DP.destroy_sr: this happens when SR.detach or VBD.unplug.
2. remove_datapaths_andthen_nolock: this happens before all VDI related operations.
   In the case 1, it is to deliberately remove the datapath. Now with the fix, if the removal failed due to exceptions from e.g. SM, the datapath will be recorded as leaked in both memory and file. So that in case 2, it could be identified and be removed again. Furthermore, the removal failure again in case 2 will fail the then VDI operation and eventually expose the error. I think this is expected as it would be bad to ignore the error which might cause more issues.
   After all, from a user's perspective,
   if the case 1 is for a VM.reboot or VM.shutdown, the failure would get the VM in halted state, and a VM.start would get the VM running back;
   if the case 1 is for a VM.pool_migrate or VDI.pool_migrate, the VM could be started on the destination again after the toolstack restart on the source host.

[minglumlu]

But in VM.pool_migrate or VDI.pool_migrate case, the toolstack restart only remove the DPs used in migrations, would it remove the leaked DPs of the VM? The VM doesn't resident on the source host actually. But the leaked DPs still blocks the VM attach on the destination host.

[robhoes]

This is only for SMAPIv1.

On master (XS 8), yes, as the Storage_smapiv1_wrapper covers only SMAPIv1 SRs. Before, the module was called Storage_impl and covered both SMAPIv1 and SMAPIv3. The change was made following an update on how qemu-dp is used inside SMAPIv3 plugins.

[robhoes]

But in VM.pool_migrate or VDI.pool_migrate case, the toolstack restart only remove the DPs used in migrations, would it remove the leaked DPs of the VM? The VM doesn't resident on the source host actually. But the leaked DPs still blocks the VM attach on the destination host.

If a dp was leaked during a VM.reboot, then it will now be properly recorded as such. A following VM.pool_migrate includes a VDI.deactivate call on the source host, where now the wrapper will notice the leaked dp and will get rid of it before proceeding. This happens before VDI.activate is called on the remote host.