Bug 1911603
| Summary: | [machines] The disk, which is attached by command, can not be removed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | YunmingYang <yunyang> |
| Component: | cockpit-appstream | Assignee: | Katerina Koukiou <kkoukiou> |
| Status: | CLOSED MIGRATED | QA Contact: | YunmingYang <yunyang> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.4 | CC: | leiwang, mpitt, skobyda, wshi, xchen, ymao |
| Target Milestone: | rc | Keywords: | MigratedToJIRA, Reopened |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | ppc64le | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-18 11:29: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
2020-12-30 09:53:22 UTC
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: Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |