Libvirt Storage Pools Remain Defined After CLVM_NG Primary Storage Removal

Offen
  • Stimmt etwas nicht?
#14,449 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java, linux
Bereich
backend, infrastructure

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Java
Sterne
3.1k
Forks
1.4k
Ø Merge
7 T. 16 Std.
Gemergte PRs (30 T.)
15

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/cloudstack

Alle Issues in apache/cloudstack

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.