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

首先查看已合并的 pull request #13830，然后检查 plugins/storage/sharedfs/storagevm/src/main/java/org/apache/cloudstack/storage/sharedfs/lifecycle/StorageVmSharedFSLifeCycle.java 中的 deploySharedFSVM。使用混合的 hypervisor 类型重现 createSharedFileSystem，并验证缺少模板不再导致 NPE，且可以选择有效的 system VM 模板。

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.