Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
For system storage pool:
1) delete it via cmd `# virsh pool-undefine $poolname` on host, it doesn't disappear immediately on web UI, refreshing web UI could make it disappear.
For session storage pool:
1) stop it via cmd `$ virsh pool-destroy $poolname` on host, it still shows active on web UI, refreshing or re-login cockpit couldn't make the state change to inactive.
2) delete it via cmd `$ virsh pool-undefine $poolname` on host, the pool doesn't disappear immediately on web UI, refreshing web can't make it disappear, but re-login cockpit could.
Version-Release number of selected component (if applicable):
cockpit-machines-184-1.el8.noarch
libvirt-dbus-1.2.0-1.module+el8+2529+a9686a4d.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Login to cockpit with a user in libvirt group, such as mycount.
2. Open storage pools sub page of virtual machines,
1) create a system storage pool
name: syspool
type: Filesystem Directory
target: /var/lib/libvirt/syspool
2) create a session storage pool:
name: userpool
type: Filesystem Directory
target: /home/mycount/userpool
3. Stop the two storage pools by running `virsh -c qemu:///system pool-destroy syspool` and `virsh pool-destroy userpool` on host with the user in step1. Then observe pool status on web UI.
4. Delete the two storage pools by running `virsh -c qemu:///system pool-undefine $systempool` and `virsh pool-undefine $sessionpool` on host with the user in step1. Then observe whether the pools could disappear on web UI.
Actual results:
1. After step3 that stop the two pools on host by cmds, the system pool is inactive on UI, while the session pool is still active on UI.
2. After step4 that delete the two pools on host by cmds, the system pool and session pool are both still present on UI.
Expected results:
1. After step3, the session pool status on UI could change to inactive immediately.
2. After step4, the system pool and session pool could disappear on UI immediately.
Additional info:
Some storage pool event handling was implemented here:
commit 12568f7c882bd3da1640d459d296934c80880779
Author: Katerina Koukiou <kkoukiou>
machines: Add event handler for storage pools events
And specifically the event haldler for undefining pools was implemented here:
commit edcfa9933c82756546c78da9d1d6489fb8f1f5d6
Author: Katerina Koukiou <kkoukiou>
machines: implement delete operation for storage pools
Both are inside release 186.
Test Versions:
libvirt-dbus-1.2.0-2.module+el8.1.0+2983+b2ae9c0a.x86_64
cockpit-machines-193-1.el8.noarch
Test Steps:
1.Login cockpit with root, and stop the default pool with command which is 'virsh pool-destroy default'
2.Undefine the default pool with command which is 'virsh pool-undefine default'
Test Results:
1.The state of the storage pool on the page was changed to 'inactive' after the operations in step 1
2.The storage pool disappeared after the operations in step 2
According to the results, the state of storage pool can be updated immediately when the pool is destroyed or undefined. So move the status to VERIFIED.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2019:3325
Description of problem: For system storage pool: 1) delete it via cmd `# virsh pool-undefine $poolname` on host, it doesn't disappear immediately on web UI, refreshing web UI could make it disappear. For session storage pool: 1) stop it via cmd `$ virsh pool-destroy $poolname` on host, it still shows active on web UI, refreshing or re-login cockpit couldn't make the state change to inactive. 2) delete it via cmd `$ virsh pool-undefine $poolname` on host, the pool doesn't disappear immediately on web UI, refreshing web can't make it disappear, but re-login cockpit could. Version-Release number of selected component (if applicable): cockpit-machines-184-1.el8.noarch libvirt-dbus-1.2.0-1.module+el8+2529+a9686a4d.x86_64 How reproducible: 100% Steps to Reproduce: 1. Login to cockpit with a user in libvirt group, such as mycount. 2. Open storage pools sub page of virtual machines, 1) create a system storage pool name: syspool type: Filesystem Directory target: /var/lib/libvirt/syspool 2) create a session storage pool: name: userpool type: Filesystem Directory target: /home/mycount/userpool 3. Stop the two storage pools by running `virsh -c qemu:///system pool-destroy syspool` and `virsh pool-destroy userpool` on host with the user in step1. Then observe pool status on web UI. 4. Delete the two storage pools by running `virsh -c qemu:///system pool-undefine $systempool` and `virsh pool-undefine $sessionpool` on host with the user in step1. Then observe whether the pools could disappear on web UI. Actual results: 1. After step3 that stop the two pools on host by cmds, the system pool is inactive on UI, while the session pool is still active on UI. 2. After step4 that delete the two pools on host by cmds, the system pool and session pool are both still present on UI. Expected results: 1. After step3, the session pool status on UI could change to inactive immediately. 2. After step4, the system pool and session pool could disappear on UI immediately. Additional info: