Repository navigation
CreateSharedFileSystem NPE ("template is null") when zone has mixed hypervisor types #13825
Description
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
- Zone with two clusters of different hypervisor types, one of which has no system VM template registered (e.g.
KVM+External/MaaS). - Call
createSharedFileSystemrepeatedly. - 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.
Activity
Dogface2k commentedon Aug 8, 2026
Confirmed with a second independent reproduction, using an enabled hostless External cluster alongside the existing VMware cluster. Three fresh
createSharedFileSystemattempts were made: the first two took the VMware-first path and failed later withFound 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 commentedon Aug 24, 2026
🎯 Triage report
createSharedFileSystemthrows 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 ofcontinue-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
StorageVmSharedFSLifeCycleis server-side shared-filesystem logic🔗 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.
Add this agentic workflows to your repo
To install this agentic workflow, run