CreateSharedFileSystem NPE ("template is null") when zone has mixed hypervisor types

[amitmvyas]

Bug: CreateSharedFileSystem throws NPE ("template is null") when a zone has more than one hypervisor type

Component: plugins/storage/sharedfs/storagevm/src/main/java/org/apache/cloudstack/storage/sharedfs/lifecycle/StorageVmSharedFSLifeCycle.java
Affected versions: 4.22.1.0 (confirmed present on main as of 2026-08-06 — same code, unrelated to the two unrelated API-signature diffs between main and 4.22.1.0 in this file)

Summary

createSharedFileSystem fails immediately with:

java.lang.NullPointerException: Cannot invoke "com.cloud.storage.VMTemplateVO.getId()" because "template" is null

on any zone that has more than one hypervisor type, where at least one of those hypervisor types has no system VM template available (e.g. an External/MaaS cluster alongside a KVM cluster in the same zone).

Root cause

In deploySharedFSVM():

List<Hypervisor.HypervisorType> hypervisors = resourceMgr.getSupportedHypervisorTypes(zoneId, false, null);
if (hypervisors.size() > 0) {
    Collections.shuffle(hypervisors);
} ...

for (final Iterator<Hypervisor.HypervisorType> iter = hypervisors.iterator(); iter.hasNext();) {
    final Hypervisor.HypervisorType hypervisor = iter.next();
    VMTemplateVO template = templateDao.findSystemVMReadyTemplate(zoneId, hypervisor, preferredArchitecture);
    if (template == null && !iter.hasNext()) {
        throw new CloudRuntimeException(...);
    }
    LaunchPermissionVO existingPermission = launchPermissionDao.findByTemplateAndAccount(template.getId(), owner.getId());
    ...

The hypervisor list is shuffled, and the null-check only throws when the current hypervisor is the last one in the iteration (!iter.hasNext()). If template is null for a hypervisor that is not last in the (randomized) order — e.g. External, which has no CloudStack system VM template by design — the code falls through to template.getId() on the same iteration instead of continue-ing to the next hypervisor. This crashes before ever reaching a hypervisor (e.g. KVM) that does have a valid, Ready system VM template.

Because the list is shuffled, this is intermittent: the call succeeds whenever the working hypervisor happens to be drawn first, and fails whenever a hypervisor with no system VM template is drawn first with more entries still pending.

Reproduction

1. Zone with two clusters of different hypervisor types, one of which has no system VM template registered (e.g. KVM + External/MaaS).
2. Call createSharedFileSystem repeatedly.
3. Observe intermittent NPE vs. success depending on shuffle order, even though the working hypervisor's system VM template is verified Active / Ready / fully downloaded in the DB (vm_template, template_zone_ref, template_store_ref).

Impact

Any deployment mixing hypervisor types within one zone (common with hybrid KVM + MaaS/External or KVM + VMware setups) can hit this nondeterministically for every Shared FileSystem creation attempt, with no workaround short of isolating hypervisor types into separate zones.

[Dogface2k]

Confirmed with a second independent reproduction, using an enabled hostless External cluster alongside the existing VMware cluster. Three fresh createSharedFileSystem attempts were made: the first two took the VMware-first path and failed later with Found unsupported root disk controller [ide]; the third took the External-first path and failed with the exact reported exception: Cannot invoke "com.cloud.storage.VMTemplateVO.getId()" because "template" is null (async job result code 530). This confirms the NPE is caused by the mixed-hypervisor iteration order, not by disabling a cluster or by a fabricated test condition. The temporary cluster and all test resources were removed; the zone is back to its original VMware-only state. We are implementing and validating the fix.

[github-actions]

🎯 Triage report

createSharedFileSystem throws an intermittent NPE ("template is null") on zones with mixed hypervisor types because the hypervisor list is shuffled and the null-template check only fires on the last iteration instead of continue-ing past hypervisors with no system VM template. A second reporter confirmed the exact reproduction and root cause independently, and states a fix is being validated.

📊 Assessment

Dimension	Value	Reasoning
Type	type:bug	Clear NPE with root cause identified in code
Component	component:management-server	StorageVmSharedFSLifeCycle is server-side shared-filesystem logic
Severity	n/a	Not applied — reproducible but has a workaround (isolate hypervisor types per zone)
Labels	type:bug, component:management-server
Coding agent	Suitable	Root cause, exact file/line, and fix direction (continue instead of falling through) are already fully specified in the report

🔗 Similar issues

No similar open issues found.

💡 Notes and suggestions

Second commenter (Dogface2k) independently reproduced this with VMware + External clusters and stated they are "implementing and validating the fix" — worth checking if a PR already exists before assigning new work.

Generated by Daily Issue Triage · sonnet50 233.4K · ◷

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9