Libvirt Storage Pools Remain Defined After CLVM_NG Primary Storage Removal

Aberta
  • Algo errado?
#14,449 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
52/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
java, linux
Domínio
backend, infrastructure

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Java
Estrelas
3.1k
Forks
1.4k
Merge médio
7d 16h
PRs com merge (30d)
15

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apache/cloudstack

Todas as issues de apache/cloudstack

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.