| 2019-09-19 07:33:55 |
Veda Annayappa |
description |
For Power Hosts with dual Virtual I/O Servers and vSCSI connection to VMAX volumes, sometimes we see the following failure during initialize_connection or terminate_connection():
ERROR ... Volume already in target SG: OS-no_SLO-SG. Message received: Bad or unexpected response from the storage volume backend API: Error modify storagegroup resource. The status code received is 500 and the message is {u'message': u'A problem occurred modifying the storage group resource: Storage Group [OS-no_SLO-SG] already contains the following volumes : [00112]'}.: VolumeBackendAPIException: Bad or unexpected response from the storage volume backend API: Error modify storagegroup resource. The status code received is 500 and the message is {u'message': u'A problem occurred modifying the storage group resource: Storage Group [OS-no_SLO-SG] already contains the following volumes : [00112]'}.
For example, on a detach in a multi-attach situation, the flow again triggers a “move” operation rather than a plain “remove” of the vol from the SG. So it attempts to move the volume to the default group. But it is already in the default group. We have determined the logical location of the problem to be in REST utility method move_volume_between_storage_groups(). If that function fails for any reason, it raises the exception. But for the case when the volume is already in the target storage group, the method should:
1. tolerate the error
2. check to see if the volume is still in the source group, because it could be in both, and for the move operation, it needs to be removed from the source, the code can do that if it is in both the source and target.
Handling this way has the advantage of not needing to check the exact location status of the volume up front and avoid race conditions with it for operations that might be in parallel. |
In VMAX volumes, sometimes we see the following failure during initialize_connection or terminate_connection():
ERROR ... Volume already in target SG: OS-no_SLO-SG. Message received: Bad or unexpected response from the storage volume backend API: Error modify storagegroup resource. The status code received is 500 and the message is {u'message': u'A problem occurred modifying the storage group resource: Storage Group [OS-no_SLO-SG] already contains the following volumes : [00112]'}.: VolumeBackendAPIException: Bad or unexpected response from the storage volume backend API: Error modify storagegroup resource. The status code received is 500 and the message is {u'message': u'A problem occurred modifying the storage group resource: Storage Group [OS-no_SLO-SG] already contains the following volumes : [00112]'}.
For example, on a detach in a multi-attach situation, the flow again triggers a “move” operation rather than a plain “remove” of the vol from the SG. So it attempts to move the volume to the default group. But it is already in the default group. We have determined the logical location of the problem to be in REST utility method move_volume_between_storage_groups(). If that function fails for any reason, it raises the exception. But for the case when the volume is already in the target storage group, the method should:
1. tolerate the error
2. check to see if the volume is still in the source group, because it could be in both, and for the move operation, it needs to be removed from the source, the code can do that if it is in both the source and target.
Handling this way has the advantage of not needing to check the exact location status of the volume up front and avoid race conditions with it for operations that might be in parallel. |
|
