Bug 1824722
| Summary: | cdrom tray state is not updated on VM reset | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Peter Krempa <pkrempa> | ||||||
| Component: | libvirt | Assignee: | khanicov | ||||||
| libvirt sub component: | Storage | QA Contact: | Han Han <hhan> | ||||||
| Status: | CLOSED ERRATA | Docs Contact: | |||||||
| Severity: | low | ||||||||
| Priority: | high | CC: | chwen, dzheng, hhan, janorel, jdenemar, jsuchane, khanicov, lmen, mprivozn, rjoyce, vgoyal, virt-maint, xchen, xuzhang | ||||||
| Version: | 9.0 | Keywords: | Reopened, Triaged | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | libvirt-9.0.0-1.el9 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2023-05-09 07:26:10 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: | 9.0.0 | ||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 1714397 [details]
the libvirtd log of step4
Hello, I found the cdrom media cannot be updated or eject after retore
Version:
libvirt-6.6.0-4.module+el8.3.0+7883+3d717aa8.x86_64
qemu-kvm-5.1.0-5.module+el8.3.0+7975+b80d25f1.x86_64
or
libvirt-6.0.0-25.2.module+el8.2.1+7722+a9e38cf3.x86_64
qemu-kvm-4.2.0-29.module+el8.2.1+7990+27f1e480.4.x86_6
Steps:
1. Start an VM with cdrom
2. Save it by virsh save
3. Restore it from the saved file by virsh restore
4. Try to eject or update the media
➜ ~ virsh change-media ide sda --eject
error: Failed to complete action eject on media
error: internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'scsi0-0-0-0' is not open
➜ ~ virsh change-media ide sda --update /var/lib/libvirt/images/BOOT.iso
error: Failed to complete action update on media
error: internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'scsi0-0-0-0' is not open
➜ ~
➜ ~ virsh qemu-monitor-command ide --hmp info block
libvirt-2-format: /var/lib/libvirt/images/ide.qcow2 (qcow2)
Attached to: ide0-0-0
Cache mode: writeback
libvirt-1-format: /var/lib/libvirt/images/boot.iso (raw, read-only)
Attached to: scsi0-0-0-0
Removable device: locked, tray closed
Cache mode: writeback
Please help check if comment1 is the same issue of this bug Possibly. You didn't attach the state in the XML along with the 'info block' output and also didn't check it prior to issuing 'virsh change-media', so I'm not sure whether the root cause is similar. Created attachment 1714549 [details]
the xml of VM in each step
Detailed Steps:
➜ ~ virsh qemu-monitor-command ide --hmp info block
libvirt-2-format: /var/lib/libvirt/images/ide.qcow2 (qcow2)
Attached to: ide0-0-0
Cache mode: writeback
libvirt-1-format: /var/lib/libvirt/images/boot.iso (raw, read-only)
Attached to: scsi0-0-0-0
Removable device: locked, tray closed
Cache mode: writeback
➜ ~ virsh save ide /tmp/ide
Domain ide saved to /tmp/ide
➜ ~ virsh restore /tmp/ide
Domain restored from /tmp/ide
➜ ~ virsh qemu-monitor-command ide --hmp info block
libvirt-2-format: /var/lib/libvirt/images/ide.qcow2 (qcow2)
Attached to: ide0-0-0
Cache mode: writeback
libvirt-1-format: /var/lib/libvirt/images/boot.iso (raw, read-only)
Attached to: scsi0-0-0-0
Removable device: locked, tray closed
Cache mode: writeback
➜ ~ virsh change-media ide sda --eject
error: Failed to complete action eject on media
error: internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'scsi0-0-0-0' is not open
➜ ~ virsh qemu-monitor-command ide --hmp info block
libvirt-2-format: /var/lib/libvirt/images/ide.qcow2 (qcow2)
Attached to: ide0-0-0
Cache mode: writeback
libvirt-1-format: /var/lib/libvirt/images/boot.iso (raw, read-only)
Attached to: scsi0-0-0-0
Removable device: locked, tray closed
Cache mode: writeback
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release. Bug 2013523 which seems similar is describing it as a regression, but this bug seems to be around at least for a year. Can we please clarify? Tentatively assigning it a high-priority for now This bug describes reset, which is not that common (although when implemented in libvirt it would probably be tied to RESET event coming from QEMU which is emitted not only on plain 'virsh reset' but also on reboot). Whereas bug 2013523 describes a different behavior: QEMU mysteriously locks tray on incoming migration (restore from a file). While they might look similar they are different bugs. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. (In reply to Michal Privoznik from comment #9) > This bug describes reset, which is not that common (although when > implemented in libvirt it would probably be tied to RESET event coming from > QEMU which is emitted not only on plain 'virsh reset' but also on reboot). > Whereas bug 2013523 describes a different behavior: QEMU mysteriously locks > tray on incoming migration (restore from a file). While they might look > similar they are different bugs. That means this bug is duplicated to bug 2013523? (In reply to Han Han from comment #11) > (In reply to Michal Privoznik from comment #9) > > This bug describes reset, which is not that common (although when > > implemented in libvirt it would probably be tied to RESET event coming from > > QEMU which is emitted not only on plain 'virsh reset' but also on reboot). > > Whereas bug 2013523 describes a different behavior: QEMU mysteriously locks > > tray on incoming migration (restore from a file). While they might look > > similar they are different bugs. > > That means this bug is duplicated to bug 2013523? No, as I say these are two different bugs. This seems to be the same issue: https://gitlab.com/qemu-project/qemu/-/issues/933 Patches merged into upstream as: f47af66624f qemu: refresh internal domain state after reset 75952d18740 qemu: refresh state after reboot initiated from the guest v8.10.0-71-g75952d1874 tested on qemu v8.10.0-87-ga2ae3d299c and qemu-kvm-7.1.0-6.el9.x86_64
1. Start VM and then eject the CDROM in guest. Check the tray status:
# virsh qemu-monitor-command rhel-9.2 --hmp info block
libvirt-2-format: /var/lib/libvirt/images/rhel-9.2.qcow2 (qcow2)
Attached to: /machine/peripheral/virtio-disk0/virtio-backend
Cache mode: writeback
libvirt-1-format: /var/lib/libvirt/images/boot.iso (raw, read-only)
Attached to: scsi0-0-0-2
Removable device: not locked, tray open
Cache mode: writeback
2. Reboot the VM by guest, `virsh reset`, `virsh reboot`. Then check the tray status:
# virsh qemu-monitor-command rhel-9.2 --hmp info block
libvirt-2-format: /var/lib/libvirt/images/rhel-9.2.qcow2 (qcow2)
Attached to: /machine/peripheral/virtio-disk0/virtio-backend
Cache mode: writeback
libvirt-1-format: /var/lib/libvirt/images/boot.iso (raw, read-only)
Attached to: scsi0-0-0-2
Removable device: locked, tray closed
Cache mode: writeback
The tray status is reset to locked, tray closed.
However, no tray-change event is emitted. Expect to emit the tray-change event with the reason TRAY_CLOSE.
I did not consider emitting an event as part of the bug, but I found the issue and fixed it. Proposed patch on the list: https://listman.redhat.com/archives/libvir-list/2022-December/236300.html (In reply to khanicov from comment #21) > I did not consider emitting an event as part of the bug, but I found the > issue and fixed it. > > Proposed patch on the list: > https://listman.redhat.com/archives/libvir-list/2022-December/236300.html Tested on v8.10.0-118-g5ef2582646 and qemu-kvm-7.1.0-6.el9.x86_64: 1. Start VM and then eject the CDROM in guest. 2. Reboot VM by `virsh reset`, `virsh reboot` or guest, the tray-change event is emitted as expected Check tray-changed event without tray status change 1. Start VM 2. Reboot VM by `virsh reset`, `virsh reboot` or guest, the tray-change event is NOT emitted as expected 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 (libvirt bug fix and enhancement update), 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-2023:2171 |
Description of problem: state of cdrom tray is not updated (changed to 'closed') when resetting a VM, but the internal tray state in qemu is actually changed to 'closed' without emission of the tray-changed event. Version-Release number of selected component (if applicable): 6.2.0/upstream How reproducible: always Steps to Reproduce: 1. boot VM with cdrom 2. issue 'eject' in the guest OS on the cdrom 3. virsh reset VM 4. check tray state in qemu and in libvirt: Actual results: $ virsh dumpxml upstream | grep tray <target dev='sda' bus='scsi' tray='open'/> $ virsh qemu-monitor-command --hmp upstream info block libvirt-3-format: /var/lib/libvirt/images/systemrescuecd-amd64-6.1.2.iso (raw, read-only) Attached to: ide0-0-0 Removable device: locked, tray closed Cache mode: writeback libvirt-2-format: /tmp/blocktest/cd.iso (raw, read-only) Attached to: scsi0-0-0 Removable device: not locked, tray open Cache mode: writeback $ virsh reset upstream Domain upstream-bj was reset $ virsh dumpxml upstream | grep tray <target dev='sda' bus='scsi' tray='open'/> $ virsh qemu-monitor-command --hmp upstream info block libvirt-3-format: /var/lib/libvirt/images/systemrescuecd-amd64-6.1.2.iso (raw, read-only) Attached to: ide0-0-0 Removable device: not locked, tray closed Cache mode: writeback libvirt-2-format: /tmp/blocktest/cd.iso (raw, read-only) Attached to: scsi0-0-0 Removable device: not locked, tray closed Cache mode: writeback Expected results: Tray state in the XML matches the tray state in qemu. Additional info: Same situation happens on 'reboot' initiated from the guest OS.