GitHub user RyanP-Testing added a comment to the discussion: VMware VM import fails when primary storage is a datastore cluster with multiple LUNs (LUN paths missing in DB)
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. GitHub link: https://github.com/apache/cloudstack/discussions/12561#discussioncomment-18071249 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
