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.

Bug 1708193

Summary: [machines] Deactivation of a transient storage pool does not remove the pool from the list
Product: Red Hat Enterprise Linux 7 Reporter: YunmingYang <yunyang>
Component: cockpitAssignee: Katerina Koukiou <kkoukiou>
Status: CLOSED CURRENTRELEASE QA Contact: YunmingYang <yunyang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.7CC: leiwang, mpitt, qiyuan, tbowling, wshi, xchen
Target Milestone: rcKeywords: Extras, Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-01-22 15:25:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description YunmingYang 2019-05-09 10:56:56 UTC
Description of problem:
Create a storage pool was created by command which is 'virsh pool-create-as ${name} --type dir --target ${path}'.

Then, if user click the 'Deactivate' button on the page, there will be no error shown on the page, but there is a error which is 'U {problem: null, name: "org.libvirt.Error", message: " Storage pool not found: no storage pool with matching uuid '6dd7bc5d-b954-4df8-9ab3-e994983335ba' ", toString: ƒ}'  in the browser console, but the pool will be deleted in the back-end, and the row of pool will be still existing on the page. After refreshing, it disappear. 

If user click the 'Delete button on the page', there will be a error shown on the page which is 'Error message: Storage pool not found: no storage pool with matching uuid '6dd7bc5d-b954-4df8-9ab3-e994983335ba' ', but the pool will be deleted in the back-end, and the row of pool will be still existing on the page. After refreshing, it disappear. 


Version-Release number of selected component (if applicable):
cockpit-ws-191-1.el7.x86_64
cockpit-machines-191-1.el7.noarch
cockpit-system-191-1.el7.noarch
cockpit-191-1.el7.x86_64
cockpit-bridge-191-1.el7.x86_64
libvirt-dbus-1.3.0-1.module+el8+3081+58d4aeb5.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a storage pool with command which is 'virsh pool-create-as ${name} --type dir --target ${path}'
2. Click 'deactivate' or 'delete' button of the storage pool  

Actual results:
1. There will be a error shown on the page if click the 'Delete' button.
2. There will be a error shown in the browser console if click the 'Deactivate' button
3. The pool will be deleted on the back-end after clicking the button
4. The row of storage pool is still accessible on the page.It will disappear after refreshing


Expected results:
The storage pool can be deleted correctly.

Additional info:
If click the 'Delete' button, the error message is 'U {problem: null, name: "org.libvirt.Error", message: " Storage pool not found: no storage pool with matching uuid '6dd7bc5d-b954-4df8-9ab3-e994983335ba' ", toString: ƒ}'

if click the 'Deactive' button the error message is ' Error message: Storage pool not found: no storage pool with matching uuid '6dd7bc5d-b954-4df8-9ab3-e994983335ba' '

Comment 2 Katerina Koukiou 2019-05-09 11:36:52 UTC
It's because in cockpit-machines we don't really support transient resources.

After you create you pool see that it's not listed under persistent pools with 'virsh pool-list --persistent'
That is because, when you created the storage pool with `virsh pool-create-as` you created the pool but you didn't define it. You need to use 'virsh pool-define-as' command to define it after creation to have a pool that we be still available to libvirt after deactivation.

This would never happen if you had created the pool from cockpit UI since we define it in the background.

I will leave the bug open, so that I will handle pool deactivation of transient pools properly.

Comment 5 Martin Pitt 2019-07-25 08:09:20 UTC
The fix still didn't land upstream yet, it still needs work. Moving to 7.8.

Comment 6 Martin Pitt 2019-10-14 12:43:09 UTC
Setting back to assigned, as that PR is stale and needs to be reworked.

Comment 7 Xianghua Chen 2019-11-11 06:03:11 UTC
As "snapshot 1 Only Approved Exceptions and Blocker-rc Issues" according to the release schedule, and also this bug is still not listed in the Errata advisory: https://errata.devel.redhat.com/advisory/47434
Do you want to leave this bug to next release? Please change the Target release to next release if yes, thanks.

Comment 8 Martin Pitt 2019-11-11 13:39:51 UTC
@Xianghua: Correct, we still don't have a proper fix for this, I'm afraid.

Comment 11 Martin Pitt 2019-11-21 06:58:35 UTC
@Xianghua: I'll just drop my dev ack, it's easy enough to re-add once we have a fix.

Comment 12 RHEL Program Management 2019-11-21 06:58:43 UTC
Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.

https://www.redhat.com/support/process/production/#howto

Comment 15 Martin Pitt 2020-02-04 16:59:22 UTC
@Xianghua: We don't have a fix in master yet, so I don't want to commit to that yet. I'm afraid I can't say how complex this is to fix, Katerina or Simon would know better.

Comment 16 Xianghua Chen 2020-04-30 06:35:36 UTC
The same problem exists for transient network by following steps:
cockpit-machines-195.8-2.el7_9.x86_64

1. Prepare a network xml:
# cat test.xml
<network>
  <name>test</name>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <ip address='192.168.1.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.1.2' end='192.168.1.254'/>
    </dhcp>
  </ip>
</network>
2. Create a transient network by: virsh net-create test.xml
# virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     yes           yes
 test                 active     no            no
3. Click  'deactivate' on the page

The network can only disapper after refreshing the page.

Comment 17 Katerina Koukiou 2021-01-22 15:25:38 UTC
That is fixed in release 208 with:

commit 160dbcc044fa525558f19d153305d3ba3ee5c62c
Author: Simon Kobyda <42733240+skobyda.github.com>
Date:   Tue Nov 26 09:35:52 2019 +0100

    machines: Support transient virtual networks and storage pools
    
    Fixed https://bugzilla.redhat.com/show_bug.cgi?id=1715429
    
    Closes #13165