Bug 1911603

Yunming is the VM image that you are using when you 're defining the VM containing an installed OS? 
Live-detaching disks needs the cooperation of the guest operating system.

Here are some more information that you might find useful. In the cockpit-machines UI we display the information as seen in the live XML when the VM is running. When you 're clicking the detach button, we will try remove the disk in question, from the inactive XML and the live XML configuration.
Removing the disk from the inactive definition is straightforward but detaching from the live guest needs the cooperation of the guest OS.

Indeed if your guest is unresponsive, clicking on the UI's detach button, will manage to update the inactive XML, but you won't see the changes in the UI till you shut down the VM.


If you want to verify that the CLI has the same behavior you can run the following commands:

After step 2: 

3: virsh detach-disk --domain subVmTest1 --target vdc --live
4: virsh dumpxml subVmTest1

Notice that vdc still exists in the live XML and was not really detached although that the command did not finish with error.

Thanks. the VM image I used is Alpine 3.11. It seems that there is some trouble in the cooperation between this guest OS and remove action. And I installed a fedora 33, and re-try to detach the disk which attached by command. The issue is gone. So let's close this issue. Many thanks.

Re-open as reproducing with fedora 38 cloud base image, but the step may need some specific:

Version-Release number of selected components (if applicable):
cockpit-297-1.el8.ppc64le
cockpit-machines-297-1.el8.noarch
libvirt-dbus-1.3.0-2.module+el8.9.0+18724+20190c23.ppc64le
libvirt-libs-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-dbus-1.3.0-2.module+el8.9.0+18724+20190c23.ppc64le
libvirt-daemon-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-driver-network-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-driver-storage-disk-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-driver-nodedev-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-driver-storage-iscsi-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-glib-3.0.0-1.el8.ppc64le
python3-libvirt-8.0.0-2.module+el8.9.0+18724+20190c23.ppc64le
libvirt-client-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-driver-storage-core-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-config-network-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-driver-interface-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le
libvirt-daemon-driver-qemu-8.0.0-22.module+el8.9.0+19544+b3045133.ppc64le

How reproducible:
100%

Steps to Reproduce:
1 Create a VM by "virt-install --name test --import --disk /var/lib/libvirt/images/ppc64lemini.qcow2 --os-variant fedora38 --memory 2048 --vcpus 2 --noautoconsole --os-variant fedora38 --print-xml > xml && virsh define xml && virsh start test"
2 Create a pool by "mkdir -m 777 /tmp/pool1 && virsh pool-define-as myPoolOne --type dir --target /tmp/pool1 && virsh vol-create-as myPoolOne mydiskofpoolone_1 --capacity 1G --format qcow2"
3 Attach the disk by "virsh attach-disk --domain test --source /tmp/pool1 --target vdc --targetbus virtio" before VM boot completely
4 Wait until the VM boot completely, then try to remove the disk by the page
5 Shut off the VM

Actual results:
1 After step 4, the disk can not be removed
2 After step 5, the disk is removed

Expected results: 
1 The disk can be removed after clicking removed button on the Page

Additional info: