CloudStack 4.22: `prepareHostForMaintenance` throws NPE when stale destroyed volume references removed storage pool
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 55/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- java, mariadb, mysql
- Bereich
- backend, cloud, infrastructure
Rechercherichtung
Beginne bei UserVmManagerImpl.isAnyVmVolumeUsingLocalStorage in Zeile 7558 und verfolge seine Aufrufer in isVMUsingLocalStorage und ResourceManagerImpl.doMaintain. Stelle den Zustand eines veralteten, zerstörten Volumes und eines entfernten Storage-Pools nach und überprüfe anschließend, dass die Wartung keinen unbehandelten NullPointerException mehr auslöst und dass das gewählte Verhalten für das veraltete Volume durch einen passenden Test abgedeckt ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
problem
Description
While attempting to place a KVM host into Maintenance mode in CloudStack 4.22, the maintenance operation failed with a NullPointerException.
The issue appears to occur when a VM has a stale/destroyed volume entry in the volumes table that still references a removed storage pool.
Instead of gracefully ignoring the stale volume metadata or returning a user-facing validation error, CloudStack crashes during maintenance preparation.
Environment
- CloudStack version: 4.22
- Hypervisor: KVM
- Primary storage: NFS
- Database: MySQL/MariaDB
Steps to reproduce
-
Have a VM with:
- one valid active ROOT volume
- one stale/destroyed ROOT volume entry still present in the
volumestable
-
The stale volume references a storage pool which has already been removed.
-
Attempt to place the host running the VM into Maintenance mode.
Example problematic DB state:
VM
SELECT id, uuid, name, instance_id, pool_id, state, removed
FROM volumes
WHERE instance_id = 446
ORDER BY id;
Result:
+------+--------------------------------------+----------+-------------+---------+---------+---------+
| id | uuid | name | instance_id | pool_id | state | removed |
+------+--------------------------------------+----------+-------------+---------+---------+---------+
| 928 | 6dea3d6f-bd6d-4e8b-9524-6e99c029694c | ROOT-446 | 446 | 4 | Destroy | NULL |
| 1554 | 80acf9ae-b047-41b8-bded-cdceb6de7051 | ROOT-446 | 446 | 2 | Ready | NULL |
+------+--------------------------------------+----------+-------------+---------+---------+---------+
Storage pool state
The stale volume references storage pool ID 4, which is already removed:
storage_pool_name: Export-Domain
storage_pool_removed: 2026-04-23 13:44:08
Actual result
Host maintenance fails with:
java.lang.NullPointerException: Cannot invoke
"org.apache.cloudstack.storage.datastore.db.StoragePoolVO.isLocal()"
because "storagePool" is null
Relevant stack trace:
at com.cloud.vm.UserVmManagerImpl.isAnyVmVolumeUsingLocalStorage(UserVmManagerImpl.java:7558)
at com.cloud.vm.UserVmManagerImpl.isVMUsingLocalStorage(UserVmManagerImpl.java:7121)
at com.cloud.resource.ResourceManagerImpl.doMaintain(ResourceManagerImpl.java:1553)
at com.cloud.resource.ResourceManagerImpl.maintain(ResourceManagerImpl.java:1653)
at org.apache.cloudstack.api.command.admin.host.PrepareForHostMaintenanceCmd.execute(PrepareForHostMaintenanceCmd.java:99)
Expected result
CloudStack should not throw an unhandled NullPointerException.
Possible expected behavior:
- ignore destroyed/removed stale volumes during maintenance evaluation
- skip volumes attached to removed pools
- or return a proper validation error identifying the problematic VM/volume
Workaround
Marking the stale destroyed volume row as removed allowed maintenance to proceed:
UPDATE volumes
SET removed = NOW()
WHERE id = 928
AND instance_id = 446
AND state = 'Destroy'
AND removed IS NULL
AND pool_id = 4;
Additional notes
The issue appears to be triggered specifically by:
- stale destroyed volume rows
- still linked to an active/running VM
- referencing removed storage pools
- while evaluating VM local-storage usage during host maintenance
versions
The versions ACS 4.22, KVM (should not be relevant)
The steps to reproduce the bug
...
What to do about it?
No response
- Vorherrschende Sprache
- Java
- Sterne
- 3.1k
- Forks
- 1.4k
- Ø Merge
- 6 T. 20 Std.
- Gemergte PRs (30 T.)
- 27
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/cloudstack
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
apache/cloudstack#14222 ·
-
create-kubernetes-binaries-iso.sh builds the ISO without setting a volume ID on EL8 based os's Offenbug component:kubernetes
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
apache/cloudstack#14180 ·
-
bug component:projects component:UI
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
apache/cloudstack#14070 · 5 Kommentare ·
-
component:backup
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
apache/cloudstack#14013 ·
-
KVM agent fails to connect to Ceph RBD storage pool after upgrading Ceph client to Tentacle 20.2.4 Offenbug component:ceph
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
apache/cloudstack#13989 · 3 Kommentare ·
Alle Issues in apache/cloudstack
Ähnliche Issues
-
certification
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 80/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Offenbug ecr
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Needs: Triage Type: Feature request
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
github/copilot-sdk#2760 ·