Divyen Patel

@gnufied even if there is a timeout during controller publish, CSI might get a call again to re-attach the same volume to the same node, and if the prior call...

> Do we know what is causing the failure in the first place? Happy to jump in a call if that helps. Based on the workflow we are speculating there...

got logs from @gnufied Volume Registration as FCD was successful as part of the Migration. Volume ID: cb96305a-352a-4f3a-b22f-824e658f31d4 for PV - pvc-72ec9236-1da4-46d8-b3b0-ad5a44815b7a having Volume Path `[vsanDatastore] d644b863-84ba-f34c-3d6a-3cfdfe98c6b8/jcallen3-ndk95-dynamic-pvc-72ec9236-1da4-46d8-b3b0-ad5a44815b7a.vmdk` ``` 2023-03-22T20:37:53.187112444Z {"level":"info","time":"2023-03-22T20:37:53.187050892Z","caller":"migration/migration.go:519","msg":"Registering...

We have update from FCD team. As part of the migration process, we can reduce the likelihood of encountering this issue by waiting for all in-tree PVs to be registered...

The FCD team also needs a verbose log to continue debug why FCD is lost.

The issue we observed based on the logs and resolution is published here - https://kb.vmware.com/s/article/91752

@gnufied if both vCenter and ESXi on vSphere 8.0u1, then we will not hit into this issue while setting control flag.

7.0p07 and 8.0u1 has the fix for allow setting control flag even when volume is attached to some VM, so we will not hit into error while setting the control...

Second issue is not present in 7.0 but only there in 8.0 and 8.0u1. in 8.0u2 we have fixed the second issue regarding CNS volume not found in the memory....

7.0p07 and 8.0u2 (GA in Aug 31st) is recommended for in-tree vSphere volume to CSI migration.