Repository navigation
Conversation
…tostarting CLVM pools
There was a problem hiding this comment.
🟡 Changes recommended
Error handling, resource cleanup, and an existing failing test must be addressed.
4 open findings
What changed in this PR
Fixes CLVM/CLVM_NG pool deletion by handling inactive libvirt pools correctly.
Changes:
- Adds CLVM-specific pool deletion.
- Disables libvirt autostart for CLVM pools.
| File | Description |
|---|---|
ClvmStorageAdaptor.java |
Undefines CLVM pools without requiring activation. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| @@ -290,7 +326,6 @@ private StoragePool createCLVMStoragePool(Connect conn, String uuid, String host | |||
| try { | |||
| StoragePool pool = conn.storagePoolDefineXML(poolDef.toString(), 0); | |||
| logger.info("Created libvirt pool definition for CLVM/CLVM_NG VG: {} (pool will remain inactive)", volgroupName); | |||
| } | ||
| } | ||
|
|
||
| private boolean undefineInactiveClvmPool(Connect conn, String uuid) throws LibvirtException { |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #14379 +/- ##
============================================
+ Coverage 20.21% 20.66% +0.45%
- Complexity 20750 21731 +981
============================================
Files 6426 6492 +66
Lines 580181 590759 +10578
Branches 71033 72453 +1420
============================================
+ Hits 117287 122089 +4802
- Misses 450180 455394 +5214
- Partials 12714 13276 +562
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🔴 Test Coverage Grade:
|
| Metric | Value |
|---|---|
| Line coverage | 25.76% |
| Branch coverage | 20.07% |
Grade Scale
| Grade | Line Coverage | Meaning |
|---|---|---|
| 🟢 A | ≥ 80% | Excellent - this code sleeps well at night 😴 |
| 🟡 B | 60-79% | Good - almost there, don't stop now 😉 |
| 🟠 C | 40-59% | Acceptable - your code is wearing a seatbelt, but no airbags 😬 |
| 🔴 D | 20-39% | Marginal - boldly shipping where no test has gone before 🖖 |
| ⛔ F | < 20% | Failing - tests? what tests? 🔥 |
Branch coverage is shown as a secondary signal. Grade is determined by line coverage.
View full Actions run
| } | ||
|
|
||
| @Override | ||
| public boolean deleteStoragePool(String uuid) { |
There was a problem hiding this comment.
@Pearl1594 , sonar has a good point here; this either returns true or throws an exception. I realise it is an override but is the return needed at all? (here or in undefineInactiveClvmPool(..))
There was a problem hiding this comment.
I think this is the same pattern we follow for most the storageAdaptors too - LibvirtStorageAdaptor
There was a problem hiding this comment.
As said the override may not be helped, but that doesn't mean the private method has to as well. Also the pattern might well need an anti-pattern.
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
5 open issues
Update create test to verify autostart remains disabled Wrapping withnew CloudRuntimeException(e.toString(), e)loses important context about what… · New This override changes deletion semantics in a non-obvious way (removes only the libvirt storage… · New The method nameundefineInactiveClvmPoolis misleading because it also destroys the pool when it… · New Add unit tests for storage pool deletion behavior and failures
2 resolved since last review
Review effort: Lite
| try { | ||
| undefineInactiveClvmPool(LibvirtConnection.getConnection(), uuid); | ||
| } catch (LibvirtException e) { | ||
| throw new CloudRuntimeException(e.toString(), e); |
| @Override | ||
| public boolean deleteStoragePool(String uuid) { | ||
| logger.info("Attempting to remove CLVM/CLVM_NG storage pool {} from libvirt", uuid); | ||
|
|
||
| if (decStoragePoolRefCount(uuid)) { | ||
| logger.info("deleteStoragePool: CLVM/CLVM_NG storage pool {} still in use", uuid); | ||
| } else { | ||
| try { | ||
| undefineInactiveClvmPool(LibvirtConnection.getConnection(), uuid); | ||
| } catch (LibvirtException e) { | ||
| throw new CloudRuntimeException(e.toString(), e); | ||
| } | ||
| } | ||
| return true; | ||
| } |
| private void undefineInactiveClvmPool(Connect conn, String uuid) throws LibvirtException { | ||
| StoragePool sp = lookupClvmPool(conn, uuid); | ||
| if (sp == null) { | ||
| logger.warn("CLVM/CLVM_NG storage pool {} doesn't exist in libvirt. Assuming it is already removed", uuid); | ||
| return; | ||
| } | ||
|
|
||
| try { | ||
| if (sp.isActive() == 1) { | ||
| sp.destroy(); | ||
| } | ||
| if (sp.isPersistent() == 1) { | ||
| sp.undefine(); | ||
| } | ||
| } finally { | ||
| sp.free(); | ||
| } | ||
| logger.info("CLVM/CLVM_NG storage pool {} was successfully removed from libvirt", uuid); | ||
| } |
|





Description
This PR fixes: #14204
CLVM/CLVM_NG pools are deliberately kept inactive in libvirt, because LVM is driven directly with
vgs/lvs.ClvmStorageAdaptorhad nodeleteStoragePoolof its own, so it used the genericLibvirtStorageAdaptorversion. That version callsdestroy()on the pool, and libvirt rejectsdestroy()on an inactive pool. As a result, a CLVM pool could not be deleted, and enabling maintenance on it failed the same way.With this fix, deleting the pool in CloudStack only removes the CloudStack record and the libvirt pool definition on each host. It does not touch the volume group or the shared storage behind it. The VG, the lvmlockd/sanlock lockspace are left as they are, as CloudStack does not set any of these up. It only checks that the VG exists when the pool is added.
Tearing them down is the operator's responsibility, for example
vgchange --lockstop,vgremove, iSCSI logout and releasing the LUNs.Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Added a CLVM_NG/ CLVM pool
Put it in maintenance
Deleted the pool - Observed that the records were marked removed in the DB and the
virsh pool-list --allno longer showed the volume group.How did you try to break this feature and the system with this change?