A Pod Fails to Be Created and Logs Show That an Initiator Has Been Associated with Another Host

Symptom

When a Pod is created using SAN storage, the Pod is always in the ContainerCreating status. The Pod logs report alarm event “rpc error: code = Internal desc = initiator xxx is already associated to another host”.

Root Cause Analysis

Cause 1: CSI automatically creates hosts, host groups, and initiators based on certain rules. If the same resources exist on the storage side before CSI is used, conflicts will occur. The possible cause is that the same initiator has been added before CSI is used.

Cause 2: In the container cluster, the initiator names of different worker nodes are the same. In this case, perform the following steps to rectify the fault:

Log in to different worker nodes in the container cluster and run the following command to check whether different worker nodes use the same initiator name:
- To view the iSCSI initiator name, run the following command:
```
cat /etc/iscsi/initiatorname.iscsi
```
- To view the FC initiator name, run the following command:
```
cat /sys/class/fc_host/host*/port_name
```
- To view the RoCE initiator name, run the following command:
```
cat /etc/nvme/hostnqn
```
If different worker nodes use the same initiator name, rectify the fault according to Solution or Workaround .

Solution or Workaround

Check whether the host associated with the initiator has volumes in use. If the host has volumes in use, migrate the Pod in use to another node.
After confirming that the host has no volume in use, change the initiator name to ensure that the initiator is unique.
Run the following command to restart the iscsid service.
```
systemctl restart iscsid
```
Restarting the iscsid service may cause I/O interruption. Before restarting the service, ensure that the host associated with the initiator has no volume in use.
Restart the huawei-csi-node service.