|Summary:||[HP3Par-8400] Instance creation failed.|
|Product:||Red Hat OpenStack||Reporter:||Nilesh <nchandek>|
|Component:||openstack-cinder||Assignee:||Cinder Bugs List <cinder-bugs>|
|Status:||NEW ---||QA Contact:||Tzach Shefi <tshefi>|
|Severity:||urgent||Docs Contact:||Chuck Copello <ccopello>|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Comment 3 Alan Bishop 2019-07-16 19:40:09 UTC
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.
Comment 6 Alan Bishop 2019-07-23 20:15:31 UTC
The symptoms match a known problem with the 3par driver . 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.  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.