VM Creation Fails on Dell PowerStore Backend With Duplicate Host Registration Error

Problem

New virtual machine creation fails immediately at the volume-attachment stage on a Dell PowerStore iSCSI backend. Boot-from-volume instances enter ERROR state within seconds of launch, while standalone (empty) volume creation continues to work normally. The instance fault reports a storage backend failure of the form: Build of instance [INSTANCE_UUID] aborted: Unable to update attachment.(Bad or unexpected response from the storage volume backend API: ... Failed to create PowerStore host [HOST_UUID]-iSCSI.). (HTTP 500).

The failure typically surfaces immediately after a management-plane upgrade, but the upgrade is not the underlying cause. The trigger is the number of hosts registered on the PowerStore array crossing a threshold, which commonly coincides with an upgrade because the upgrade is the next significant cluster event.

Environment

• Private Cloud Director Virtualization - v2025.10 and Higher
• Self-Hosted Private Cloud Director Virtualization - v2025.10 and Higher
• Component: Block Storage Service (Dell PowerStore iSCSI backend)

Cause

The Dell PowerStore Block Storage driver looks up existing array hosts through get_all_hosts() in client.py, which issues a single unpaginated GET /host request to the PowerStore REST API. The PowerStore API enforces a default response limit of 100 objects per query.

When the array has more than 100 registered hosts, the response is truncated to the first 100. If the compute node's iSCSI initiator name (IQN) is registered under a host that falls outside those first 100 results, the driver does not see it and concludes the host does not exist. The driver then attempts to create a new host with that IQN, and the PowerStore array rejects the request because it enforces global IQN uniqueness, returning HTTP 400 with code 0xE0A01001002D — "One of the provided port names is already registered with another host."

This is not a naming or IQN-mismatch defect. The iSCSI initiator name in /etc/iscsi/initiatorname.iscsi is not modified during a management-plane upgrade, and the IQN on affected compute nodes remains unchanged. The defect is latent: while the array holds 100 or fewer hosts, every host is returned and the lookup always succeeds. Once the array grows past 100 hosts, any host beyond the first 100 becomes invisible to the driver. An upgrade often appears to "introduce" the failure only because it is the first VM-creation activity after the host count crosses the threshold.

Standalone volume creation does not register an iSCSI host on the array and is therefore unaffected. Only boot-from-volume VM creation — which triggers host registration at attachment time — fails.

This is tracked as a bug under PCD-6294.

Diagnostics

1

Confirm the failure pattern

Confirm that boot-from-volume VM creation fails while standalone volume creation succeeds. Create an empty volume to verify the Block Storage backend itself is functional, then inspect the failed instance.

OpenStack CLI

$ openstack server show <INSTANCE_UUID> --fit

The instance fault confirms the failure occurs during volume attachment.

Sample Output

| OS-EXT-STS:vm_state | error                                                                  |
| fault               | {'code': 500, 'message': 'Build of instance [INSTANCE_UUID] aborted:   |
|                     |  Unable to update attachment.(Bad or unexpected response from the      |
|                     |  storage volume backend API: Driver initialize connection failed       |
|                     |  (error: ... Failed to create PowerStore host [HOST_UUID]-iSCSI.).).    |
|                     |  (HTTP 500) (Request-ID: [REQ_UUID])'}                                  |
| image               | N/A (booted from volume)                                               |
| status              | ERROR                                                                  |

2

Confirm the PowerStore rejection in the Block Storage logs

On the Persistent Storage role host serving the backend, inspect the Block Storage volume log for the PowerStore REST rejection. The definitive signature is the 0xE0A01001002D error code returned by the array.

Persistent Storage Host

$ grep -E "0xE0A01001002D|Failed to create PowerStore host" /var/log/pf9/cindervolume-base.log

Sample Output

ERROR cinder.volume.drivers.dell_emc.powerstore.client REST Request: POST https://[POWERSTORE_IP]/api/rest/host with body {"name": "[HOST_UUID]-iSCSI", "os_type": "Linux", "initiators": [{"port_name": "[HOST_IQN]", "port_type": "iSCSI"}]}
ERROR cinder.volume.drivers.dell_emc.powerstore.client REST Response: 400 with data {"messages":[{"code":"0xE0A01001002D","severity":"Error","message_l10n":"One of the provided port names is already registered with another host. Please use port names unique to all hosts."}]}
ERROR cinder.volume.drivers.dell_emc.powerstore.client Failed to create PowerStore host [HOST_UUID]-iSCSI.

3

Confirm the IQN is already registered on the array

Verify the compute node's IQN is already present on the PowerStore array under an existing host object. A match confirms there is no IQN mismatch — the host exists, but the driver cannot see it.

The compute node IQN is read from /etc/iscsi/initiatorname.iscsi on the affected hypervisor. This value is not changed by a management-plane upgrade.

Persistent Storage Host

$ curl -k -u '<POWERSTORE_ADMIN_USER>:<POWERSTORE_PASSWORD>' \
  'https://<POWERSTORE_IP>/api/rest/host?select=id,name,host_initiators&host_initiators->0->>port_type=eq.iSCSI' \
  | python3 -c "import json,sys; h=json.load(sys.stdin); print([x['name'] for x in h if any('<HOST_IQN>' in str(i) for i in x.get('host_initiators',[]))])"

4

Confirm the pagination limit is the cause

Compare an unpaginated query against one with an explicit high limit. If the default query returns exactly 100 hosts while the explicit-limit query returns more, the pagination limit is confirmed as the cause. Confirm the affected compute node's IQN is absent from the 100-host result but present in the full result.

Persistent Storage Host

$ curl -k -u '<POWERSTORE_ADMIN_USER>:<POWERSTORE_PASSWORD>' \
  'https://<POWERSTORE_IP>/api/rest/host?select=id,name,host_initiators&host_initiators->0->>port_type=eq.iSCSI' \
  | python3 -c "import json,sys; print(len(json.load(sys.stdin)), 'hosts returned')"

Sample Output

100 hosts returned    # actual total registered on the array: [ACTUAL_HOST_COUNT]

If all checks above match, proceed to the Workaround.

Resolution

A permanent fix is tracked under PCD-6294. The corrected host-lookup logic is expected from the upstream Dell PowerStore driver and will be backported to the Platform9 Block Storage driver once it is merged. No fixed release is available at this time.

In the meantime, apply the Workaround below.

Workaround

Add an explicit high page limit to the PowerStore host-lookup query so that all registered hosts are returned. Apply this change on every host that has the Persistent Storage role assigned.

This workaround edits a file inside a Platform9-managed package. The change is reverted whenever the host is upgraded or the pf9-cindervolume-base package is updated, and it must be reapplied. The change must also be applied to any new host that is later assigned the Persistent Storage role.

1

Edit the PowerStore driver host-lookup query

SSH into the Persistent Storage role host and update the get_all_hosts function to include an explicit limit.

Persistent Storage Host

$ sudo vi /opt/pf9/pf9-cindervolume-base/lib/python3.9/site-packages/cinder/volume/drivers/dell_emc/powerstore/client.py

Replace the get_all_hosts function with the following:

Persistent Storage Host

    def get_all_hosts(self, protocol):
        r, response = self._send_get_request(
            "/host",
            params={
                "select": "id,name,host_initiators",
                "host_initiators->0->>port_type": "eq.%s" % protocol,
                "limit": 1000,
            }
        )
        if r.status_code not in self.ok_codes:
            msg = _("Failed to query PowerStore hosts.")
            LOG.error(msg)
            raise exception.VolumeBackendAPIException(data=msg)
        return response

2

Restart the Block Storage volume service

Restart the service so the driver change takes effect.

Persistent Storage Host

$ sudo systemctl restart pf9-cindervolume-base.service

3

Verify all hosts are now returned

Re-run the host query with the explicit limit and confirm the count exceeds 100 and includes the previously missing IQN.

Persistent Storage Host

$ curl -k -u '<POWERSTORE_ADMIN_USER>:<POWERSTORE_PASSWORD>' \
  'https://<POWERSTORE_IP>/api/rest/host?select=id,name,host_initiators&host_initiators->0->>port_type=eq.iSCSI&limit=1000' \
  | python3 -c "import json,sys; print(len(json.load(sys.stdin)), 'hosts returned')"

Sample Output

[ACTUAL_HOST_COUNT] hosts returned

4

Confirm VM creation succeeds

Create a boot-from-volume test VM and confirm it reaches ACTIVE state, then delete the test VM.

OpenStack CLI

$ openstack server create --flavor <FLAVOR> --volume <VOLUME_UUID> --network <NETWORK_UUID> <TEST_VM_NAME>
$ openstack server show <TEST_VM_NAME> -c status

Sample Output

| status | ACTIVE |

A successful ACTIVE result confirms the workaround is effective.

If a Persistent Storage host must be brought back to a clean state instead of patched, the stale PowerStore host entry for the affected node can be removed so the driver re-creates it on the next attachment. See How to Delete Stale Storage Host Entries in PCD. This is a per-node relief that recurs for any host outside the first 100 results until the driver fix is in place.

Additional Information

This issue is tracked in PCD-6294. The permanent fix is expected from the upstream Dell PowerStore driver and will be backported to the Platform9 Block Storage driver once merged. The workaround above is temporary and does not survive a host upgrade or package update.