Libvirt Storage Pools Remain Defined After CLVM_NG Primary Storage Removal

Aperta
  • Qualcosa non va?
#14,449 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, linux
Ambito
backend, infrastructure

Direzione di ricerca

Start by tracing the primary storage removal flow for CLVM_NG and how it communicates with KVM hosts to remove libvirt pools. The issue names no source files or tests, so first locate the removal handlers and related tests, then reproduce the cleanup behavior with the listed CloudStack and KVM setup. Done means a removed pool that is no longer in use is undefined on affected hosts.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
problem

Title

Libvirt Storage Pools Remain Defined After CLVM_NG Primary Storage Removal

Description

When a CLVM_NG primary storage pool is removed from CloudStack, the corresponding libvirt storage pool remains defined on the KVM hosts.

Although the storage pool is marked as removed in the CloudStack database, the associated libvirt logical storage pool remains active and configured with autostart enabled. This leaves stale storage pool definitions on the KVM hosts after the primary storage has been removed from CloudStack.

Steps to Reproduce

  1. Configure a CLVM_NG primary storage pool in CloudStack.
  2. Verify that the corresponding logical storage pool is defined on the KVM hosts using virsh pool-list.
  3. Remove the primary storage pool from CloudStack.
  4. Check the storage pool record in the CloudStack database.
  5. Run virsh pool-list and virsh pool-dumpxml <pool_name> on the KVM host.

Actual Behavior

The storage pool is marked as removed in the CloudStack database, but its corresponding libvirt storage pool remains defined and active on the KVM host.

For example, the CloudStack database shows the following record:

mysql> select * from storage_pool where name='xxxxxxxxds_test_02_clvm';
+----+-------------------------+------+-----------+------+----------------+--------+------------+------------+----------------+--------------+-----------+-----------------------+---------------------+---------------------+---------------------+-------------+-----------------------+---------+------------+---------+---------------+--------+-----------+
| id | name                    | uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes | capacity_bytes | host_address | user_info | path                  | created             | removed             | update_time         | status      | storage_provider_name | scope   | hypervisor | managed | capacity_iops | parent | used_iops |
+----+-------------------------+------+-----------+------+----------------+--------+------------+------------+----------------+--------------+-----------+-----------------------+---------------------+---------------------+---------------------+-------------+-----------------------+---------+------------+---------+---------------+--------+-----------+
| 68 | xxxxxxxxds_test_02_clvm | NULL | CLVM_NG   |    0 |              1 |      1 |          4 |  268435456 |  4398042316800 | localhost    | NULL      | xxxxxxxxds_test_02_vg | 2026-09-07 17:18:26 | 2026-09-22 16:38:48 | 2026-09-11 17:49:44 | Maintenance | DefaultPrimary        | CLUSTER | KVM        |       0 |          NULL |      0 |      NULL |
+----+-------------------------+------+-----------+------+----------------+--------+------------+------------+----------------+--------------+-----------+-----------------------+---------------------+---------------------+---------------------+-------------+-----------------------+---------+------------+---------+---------------+--------+-----------+
1 row in set (0.00 sec)
 
mysql>

The record has a removed timestamp of 2026-09-22 16:38:48, indicating that the storage pool was removed from CloudStack.

However, on the KVM host, the corresponding libvirt storage pool remains defined and active:

# /usr/bin/virsh pool-list
Name                                   State    Autostart
------------------------------------------------------------
72bf0bc4-b39d-4813-8d1c-26a07b9ea27d   active   no
77be2d95-d3a2-4647-a08d-7f4ba352bda5   active   no
b6b18a84-616b-455e-a71a-1c1a4cda938e   active   no
cff3230f-29ad-4210-9db6-14db918b5e24   active   no
d558ab81-822d-49a6-886b-ccbaae584505   active   no
xxxxxxxxds_test_02_vg                  active   yes
xxxxxxxxds_test_03_vg                  active   yes
xxxxxxxxds_test_04_vg                  active   yes
 
#  /usr/bin/virsh pool-dumpxml xxxxxxxxds_test_02_vg
<pool type='logical'>
  <name>xxxxxxxxds_test_02_vg</name>
  <uuid>a7b66174-d2a7-32bf-be0c-2e1329547986</uuid>
  <capacity unit='bytes'>4398042316800</capacity>
  <allocation unit='bytes'>4398042316800</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>xxxxxxxxds_test_02_vg</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/xxxxxxxxds_test_02_vg</path>
  </target>
</pool>
 
#

Expected Behavior

When a CLVM_NG primary storage pool is removed from CloudStack, the corresponding libvirt storage pool should also be undefined on the affected KVM hosts, provided it is no longer in use and can be safely removed.

CloudStack should ensure that storage pool definitions are properly cleaned up on the KVM hosts during primary storage removal.

Environment

  • CloudStack version: 4.23.0
  • Hypervisor: KVM
  • Primary storage type: CLVM_NG
  • KVM host OS: Red Hat Enterprise Linux 9.8

Additional Information

The CloudStack storage pool name is xxxxxxxxds_test_02_clvm, while the corresponding libvirt logical storage pool name is xxxxxxxxds_test_02_vg, matching the LVM volume group name configured as the storage pool path in CloudStack.

versions

The versions of ACS, hypervisors, storage, network etc..

The steps to reproduce the bug

...

What to do about it?

No response

Lingua principale
Java
Stelle
3.1k
Fork
1.4k
Merge medio
7g 16h
PR unite (30g)
15

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/cloudstack

Tutte le issue di apache/cloudstack

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.