Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

VMware VM import fails when primary storage is a datastore cluster with multiple LUNs

Offen
  • Stimmt etwas nicht?
#13,885 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
cloud, infrastructure

Rechercherichtung

Beginne damit, syncStoragePool und syncDatastoreClusterStoragePool in server/src/main/java/com/cloud/storage/StorageManagerImpl.java nachzuverfolgen, und untersuche anschließend die Behandlung von ModifyStoragePoolCommand in VmwareResource.java sowie getDatastoresInDatastoreCluster() in StoragepodMO.java. Vergleiche den Host-Verbindungspfad in DefaultHostListener.java mit der Suche nach nicht verwalteten VMs in UnmanagedVMsManagerImpl.java. Als erledigt gilt die Aufgabe, wenn ein unvollständiges Datastore-Cluster-Ergebnis nicht mehr stillschweigend akzeptiert wird und der betroffene Synchronisierungs-/Importpfad verifiziert wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

component:primary-storage component:vmware type:bug
The required feature described as a wish

claude generated description for problem asked about in #12561

problem

VMware "Datastore Cluster" (Storage DRS pod) primary storage pools can end up with zero child-datastore entries in the storage_pool table, even though syncStoragePool reports success. When this happens, importing an existing/unmanaged VM whose disk lives on one of the cluster's underlying datastores fails with:

Storage pool for disk Hard disk 1 (460-2000) with datastore: <datastore-name> not found in zone ID: <zone-uuid>

Originally reported at: https://github.com/apache/cloudstack/discussions/12561

Root cause (from code inspection)

Child storage_pool rows for a datastore-cluster pool are only created when a live ModifyStoragePoolCommand round-trip to a connected ESXi host returns a non-empty datastoreClusterChildren list:

  • plugins/hypervisors/vmware/src/main/java/com/cloud/hypervisor/vmware/resource/VmwareResource.java (execute(ModifyStoragePoolCommand), around line 5291) calls StoragepodMO.getDatastoresInDatastoreCluster() to enumerate child datastores.
  • vmware-base/src/main/java/com/cloud/hypervisor/vmware/mo/StoragepodMO.java (getDatastoresInDatastoreCluster(), lines ~41-44) reads the childEntity property with no validation or retry — if vCenter's property collector returns an empty/partial list (e.g. permissions/RBAC restricting which datastores the CloudStack service account can see on that specific pod, or a transient inventory glitch), no exception is raised.
  • server/src/main/java/com/cloud/storage/StorageManagerImpl.java (syncDatastoreClusterStoragePool(...), lines ~2760-2815) persists whatever child list comes back. An empty list simply results in "0 added, 0 removed" — there is no check that the returned child count is non-zero or matches expectations.
  • This sync path is triggered by host-connect events (DefaultHostListener.hostConnect, engine/storage/volume/src/main/java/org/apache/cloudstack/storage/datastore/provider/DefaultHostListener.java, lines ~136-186) and by the explicit syncStoragePool API (StorageManagerImpl.syncStoragePool, lines ~2643-2699), which also only samples one arbitrary connected host to answer.

Net effect: if the first (and every subsequent) sync attempt for this specific pod happens to get an empty answer from whichever host was asked, the pool is silently left with no child rows forever, while the API/UI report the sync as successful. Other datastore clusters in the same environment are unaffected because their sync happened to succeed.

Downstream, getStoragePool(...) in server/src/main/java/org/apache/cloudstack/vm/UnmanagedVMsManagerImpl.java (lines ~516-551) does a generic path/name substring match over all pools in the cluster/zone — it works fine for datastore-cluster children when their row exists, so this is not a separate bug in the import code; it's a downstream symptom of the missing storage_pool row.

What versions of cloudstack and any infra components are you using

  • CloudStack: 4.20.0.0
  • Hypervisor: VMware (vCenter, ESXi)
  • Primary storage: Datastore Cluster (Storage DRS pod) containing 4 LUNs
  • Storage: HPE Alletra 5050 (FC/iSCSI LUNs presented as VMFS datastores)

The steps to reproduce the bug

  1. Create a VMware Datastore Cluster (Storage DRS pod) in vCenter containing multiple LUNs/datastores.
  2. Add the datastore cluster as CloudStack primary storage.
  3. Confirm in the storage_pool table that no child rows were created for the individual datastores (parent = the cluster pool's ID) — only the single parent/cluster row exists.
  4. Run syncStoragePool against the pool — it completes successfully but still does not populate child rows.
  5. Attempt to import an existing/unmanaged VM whose disk resides on one of the underlying datastores in that cluster.
  6. Import fails: Storage pool for disk <disk> with datastore: <name> not found in zone ID: <zone>.

Note: other datastore clusters in the same environment, added the same way, do have correctly populated child rows — the failure appears to depend on whether the very first sync happened to get a complete answer from vCenter.

What to do about it?

Suggested fix directions:

  • In StoragepodMO.getDatastoresInDatastoreCluster() / VmwareResource.execute(ModifyStoragePoolCommand), treat an empty (or unexpectedly short) childEntity/datastoreClusterChildren result as suspicious rather than a normal success — e.g. log a warning, or retry against a different host before persisting.
  • In StorageManagerImpl.syncDatastoreClusterStoragePool(...) / syncStoragePool(...), surface a warning (API response and/or logs) when a datastore-cluster sync returns zero child datastores for a pool that previously had none, instead of silently reporting success.
  • Consider having syncStoragePool try more than one connected host when the first host's answer looks incomplete, since host-level permissions/visibility to the storage pod can vary.

As a workaround, users can try re-triggering sync from a different host in the cluster, verify the vCenter service account's permissions on the affected storage pod/datastores, or remove and re-add the primary storage pool to force a fresh full discovery.

Vorherrschende Sprache
Java
Sterne
3.1k
Forks
1.4k
Ø Merge
6 T. 11 Std.
Gemergte PRs (30 T.)
13

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/cloudstack

Alle Issues in apache/cloudstack

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.