Once again, the logs were not collected with DEBUG enabled. Please enable DEBUG and collect the cinder-volume logs. My understanding is the os-brick package was a hotfix. Was the hotfix installed by customizing the cinder-volume container image on the director, followed by having the director deploying the hotfixed c-vol image? Or was the os-brick RPM patched into the running c-vol container? I ask because I'd like to confirm the c-vol process was restarted after the os-brick RPM was updated.
The symptoms match a known problem with the 3par driver [1]. The LP bug describes a situation where the FC zoning doesn't allow the controller to access all target ports on the 3par backend, and the 3par driver happens to pick a port that isn't accessible. [1] https://bugs.launchpad.net/cinder/+bug/1809249 Per LP bug, a workaround is to set use_multipath_for_image_xfer=True, which will force the driver to scan all ports. If setting use_multipath_for_image_xfer=True doesn't correct the problem, then we may need to get HPE involved. If that's necessary, then please set hpe3par_debug=True and capture more cinder-volume logs.
HPE provided a fix (actually, more like an alternative workaround) in stable/queens, and the patch is present in the latest osp-13. The customer case is closed, and so I'm closing the BZ too. Note that HPE's "fix" introduces a new 'hpe3par_target_nsp' driver option. This is an obscure option that will likely require using puppet hiera to set the value. There is no support for configuring the value in puppet-cinder, and so there's no associated THT parameter.