VMware VM import fails when primary storage is a datastore cluster with multiple LUNs (LUN paths missing in DB)

[midhunpjos]

We are facing an issue while importing an existing VMware VM into CloudStack. The import fails with the following error:

Storage pool for disk Hard disk 1 (460-2000) with datastore: Alletra5050-LUN010 not found in zone ID: b143173c-f373-48de-a850-be34934cbf1c

Environment

Cloudstack Version: 4.20.0.0
Hypervisor: VMware
CloudStack primary storage: Datastore Cluster
Datastore cluster contains multiple LUNs (4 LUNs)

In the CloudStack database, only one entry exists for the datastore cluster.
There are no individual entries for the underlying LUNs and its Path belonging to this datastore cluster. But for other datastore cluster's individual LUN entries are available.

The datastore/LUN paths for the individual LUNs are not present in the DB.
Running syncStoragePool completes successfully but does not populate any LUN-level entries for this datastore cluster.

Is there any recommended workaround to make VM import succeed in this scenario?

[DaanHoogland]

@midhunpjos,

• did you progress with this issue?
• do you have a workaround to share?
  I think this is a hole in the functionality and needs some functional definition to plug.

[DaanHoogland]

@midhunpjos have a look at #13885 and see if this suits your needs.

[RyanP-Testing]

Hi,

This looks like a storage discovery/mapping issue rather than an import issue itself.

Since the primary storage is a VMware datastore cluster with multiple LUNs, CloudStack needs to be able to resolve the individual datastore/LUN and path information for the disk being imported. The fact that the datastore cluster exists in the DB but the individual LUN/path entries are missing, while syncStoragePool completes without discovering them, is the key point here.

Before making any manual DB changes, I would compare the affected datastore cluster with one of the working clusters and verify:

• All underlying LUNs/datastores are visible from the VMware hosts.
• The CloudStack VMware hosts can see the same datastores.
• The datastore names reported by vCenter match what CloudStack expects.
• The storage pool's VMware configuration and cluster membership are correct.
• CloudStack management logs during syncStoragePool don't show discovery or filtering errors.

I would avoid manually inserting the missing LUN/path records into the CloudStack database. If the underlying datastores are visible from VMware but CloudStack still does not create the corresponding mappings after synchronization, this looks more like a CloudStack VMware storage-discovery issue that should be investigated from the management-server logs and the relevant storage-pool implementation.

If you can share the relevant management-server.log entries from the syncStoragePool operation, along with the datastore/LUN layout from vCenter, that should help narrow down why CloudStack is skipping those LUNs.