CA-398958 Cope with concurrent read-only activations

[rdn32]

It should be possible to activate a VDI on two different hosts in a pool simultaneously, provided read-only access is all that it required. So, if one host tries to activate in a brief window when another host has put the transient "activating" key on the VDI, it should be allowed to retry.

[rdn32]

This is currently only a draft as I haven't yet worked out how to reproduce the problem, let alone test that the fix works.

[MarkSymsCtx]

You might need a unit test to cover the new cases to get this through SonarQube. The existing lines are covered.

[rdn32]

I've now tested this, probably in an overly complex manner. Using a pool of two hosts and an lvmoiscsi SR:

• Created a VDI, and populated it using with-vdi
• On each host, created a VBD in the manner that with-vdi would, namely using CONTROL_DOMAIN_UUID as the vm-uuid.
• On the first host, modified /opt/xensource/sm/blktap2.py so that there's a 10 second sleep in VDI._add_tag just after the "activating" key has been set.
• Plug each VBD in from its associated host - first first host swiftly followed by the second host.

Without the fix in place on the second host, plugging in it's VBD fails with this in the log: ***** BLKTAP2:<function VDI._activate_locked at 0x7f545ab3c620>: EXCEPTION <class 'XenAPI.Failure'>, ['MAP_DUPLICATE_KEY', 'VDI', 'sm_config', 'OpaqueRef:ebde1b9c-f6d7-c2de-f430-ae14185553ec', 'activating'].

With the fix in place on the second host, plugging in its VBD succeeds (although taking about 10 seconds to complete, as you might expect) and its associated device can be read and shows the expected content.