Containers

Last reply by 03-30-2022 Solved
Start a Discussion
2 Bronze
2 Bronze
1180

Proper way to increase timeouts for PowerMax CSI driver?

Hi,

I've been working with an under-powered PowerMax storage system (or perhaps just too much historical junk), and the CSI driver on my OpenShift cluster keeps timing out with `context deadline exceeded`. There are good days and bad days, but to work on the code for functionality, I wonder if I can make my CSI driver more forgiving for slower responses from the Unisphere.

I've seen it happen when getting the initiators list, renaming the host, mounting an already-bound PV for a pod, and more. I'd love to clean up or add more RAM to the PowerMax/Unisphere and make it more performant, but if that can't happen, can somebody here suggest a proper way to make my CSI driver/attacher more forgiving/lenient with slowness?

 

thanks, - Hiro

Solution (1)

Accepted Solutions
991

@miyamotoh ,

The access mode cell for powermax has 2 lines for 2 different types of the volume type. The first one is for Mount volumes and the second one is for the RAW block as enclosed by "()".
So for the Mount Volumes, we only have RWO (v2.2 and earlier) and RWOP (latest v2.2).

Regards,
Utkarsh

View solution in original post

Replies (7)
2 Bronze
2 Bronze
1152

Hi Miyamotoh,

 

Thanks for reaching out to us. This is a known issue and we have documented the same.

https://dell.github.io/csm-docs/docs/csidriver/release/powermax/

The workaround is to remove the stale/unused entries from the array to get improved performance.

 

Regards,

Yamuna

2 Bronze
2 Bronze
1151

Hi @miyamotoh,

With respect to increasing the timeouts, Please change the default timeout for X_CSI_UNISPHERE_TIMEOUT in the line mentioned below, 

https://github.com/dell/csi-powermax/blob/6219379aafc44d1d2f9eb347c3ad78712a908de8/helm/csi-powermax...

As an option, you can provide the same value in values.yaml as well which will be taken precedence if supplied.

 

Regards,

Yamuna

 

2 Bronze
2 Bronze
1140

Thanks, Yamuna. I tried with `X_CSI_UNISPHERE_TIMEOUT=15m`, and am not sure if that's helping or it's just a "good day," but I'm getting past `GetInitatorList` and finding "valid initiator"!

However, my test pod is failing to mount the volume if created with `ReadWriteMany.` If the PVC is `ReadWriteOnce`, my pod can mount it and start up fine.

 Mount volumes do not support AccessMode MULTI_NODE_MULTI_WRITER

 This is not a "slowness" issue, is it? Could you point me what to check?

1018

Hi @miyamotoh ,

Good Day. Glad that your timeout issue has been now resolved.

CSI driver for PowerMax doesn't support Multi-Node Multi-Writer for Mount Volumes.

Please have a look at the supported capabilities.

https://dell.github.io/csm-docs/docs/csidriver/#csi-driver-capabilities

Please let me know if you have any further queries.

Regards,

Yamuna

2 Bronze
2 Bronze
1005

Well, the table shows "RWX" in the PowerMax column for Access Mode, without any side note, doesn't it? Could you clarify @YamunadeviS ?

992

@miyamotoh ,

The access mode cell for powermax has 2 lines for 2 different types of the volume type. The first one is for Mount volumes and the second one is for the RAW block as enclosed by "()".
So for the Mount Volumes, we only have RWO (v2.2 and earlier) and RWOP (latest v2.2).

Regards,
Utkarsh

2 Bronze
2 Bronze
979

Ah, that's a little hard to read out of the table, but thanks for clarifying!

Latest Solutions
Top Contributor