Ubuntu
libvirt package

libvirtd unable to execute QEMU command 'blockdev-remove-medium'

Bug #1930398 reported by gu on 2021-06-01

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	libvirt (Fedora)	Unknown	Low	redhat-bugs #1824722
	libvirt (Ubuntu)	Incomplete	Undecided	Unassigned

Bug Description

env :
   ubuntu 20.04.4
   libvirt-daemon 6.0.0-0ubuntu8.8
   qemu-kvm 1:4.2-3ubuntu6.15

attache a centos/ubuntu iso to VM,after os installation complete , after os reboot , I want to detach iso from VM. faild to detach iso from dvd device

syslog:
Jun 1 17:03:21 dev2cn02 libvirtd[1767]: internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'ide0-1-0' is not open
Jun 1 17:03:21 dev2cn02 java[2968]: libvirt: QEMU Driver error : internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'ide0-1-0' is not open
Jun 1 17:03:21 dev2cn02 java[2968]: WARN [kvm.storage.KVMStorageProcessor] (agentRequest-Handler-3:) (logid:c470e790) Failed to attach device to i-2-354-VM: internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'ide0-1-0' is not open

VM dumpxml:
<domain type='kvm' id='5'>
  <name>i-2-354-VM</name>
  <uuid>1eaae934-82f7-46cf-ac72-c9603d8190c4</uuid>
  <description>CentOS 7</description>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <cputune>
    <shares>500</shares>
  </cputune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <sysinfo type='smbios'>
    <system>
      <entry name='manufacturer'>Apache Software Foundation</entry>
      <entry name='product'>CloudStack KVM Hypervisor</entry>
      <entry name='uuid'>1eaae934-82f7-46cf-ac72-c9603d8190c4</entry>
    </system>
  </sysinfo>
  <os>
    <type arch='x86_64' machine='pc-i440fx-5.0'>hvm</type>
    <boot dev='cdrom'/>
    <boot dev='hd'/>
    <smbios mode='sysinfo'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'>
    <feature policy='require' name='vmx'/>
  </cpu>
  <clock offset='utc'>
    <timer name='kvmclock'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='network' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <auth username='hyperstor'>
        <secret type='ceph' uuid='44069041-572d-32b0-abc4-745b97eae508'/>
      </auth>
      <source protocol='rbd' name='rbd/b660b939-b622-4a97-b21f-f221b1875e1c' index='2'>
        <host name='10.100.250.11' port='3300'/>
        <host name='10.100.250.12' port='3300'/>
        <host name='10.100.250.13' port='3300'/>
      </source>
      <target dev='vda' bus='virtio'/>
      <serial>b660b939b6224a97b21f</serial>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/5155538a-0a91-3468-9c82-a927ec96c539/206-2-7475aee1-70a6-3fe7-bc3e-95f964428d79.iso' index='1'/>
      <backingStore/>
      <target dev='hdc' bus='ide' tray='open'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0' model='piix3-uhci'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <controller type='ide' index='0'>
      <alias name='ide'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='1e:00:f3:00:00:9d'/>
      <source bridge='brbond1-4'/>
      <bandwidth>
        <inbound average='256000' peak='256000'/>
        <outbound average='256000' peak='256000'/>
      </bandwidth>
      <target dev='vnet8'/>
      <model type='virtio'/>
      <link state='up'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/4'/>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/4'>
      <source path='/dev/pts/4'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/i-2-354-VM.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='tablet' bus='usb'>
      <alias name='input0'/>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'>
      <alias name='input1'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input2'/>
    </input>
    <graphics type='vnc' port='5904' autoport='yes' listen='10.226.15.4'>
      <listen type='address' address='10.226.15.4'/>
    </graphics>
    <video>
      <model type='cirrus' vram='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <watchdog model='i6300esb' action='none'>
      <alias name='watchdog0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </watchdog>
    <memballoon model='none'/>
  </devices>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+0:+0</label>
    <imagelabel>+0:+0</imagelabel>
  </seclabel>
</domain>

Tags:

Revision history for this message

In Red Hat Bugzilla #1824722, pkrempa (pkrempa-redhat-bugs) wrote on 2020-04-16:

#12

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

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.

Revision history for this message

In Red Hat Bugzilla #1824722, hhan (hhan-redhat-bugs) wrote on 2020-09-10:

#13

Created attachment 1714397
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

Revision history for this message

In Red Hat Bugzilla #1824722, hhan (hhan-redhat-bugs) wrote on 2020-09-10:

#14

Please help check if comment1 is the same issue of this bug

Revision history for this message

In Red Hat Bugzilla #1824722, pkrempa (pkrempa-redhat-bugs) wrote on 2020-09-10:

#15

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.

Revision history for this message

In Red Hat Bugzilla #1824722, hhan (hhan-redhat-bugs) wrote on 2020-09-11:

#16

Created attachment 1714549
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

Created attachment 1714549
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

Revision history for this message

Ubuntu Foundations Team Bug Bot (crichton) wrote on 2021-06-01:

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1930398/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags:

added: bot-comment

gu (cshaven) on 2021-06-02

affects:

ubuntu → libvirt (Ubuntu)

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-02:

Download full text (3.9 KiB)

Hi gu,
I was trying to reproduce your case and spawned a guest to attach&detach an ISO.

When started the guest had this XMLrepresentation of the cd drive:

Yours was slightly different:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/5155538a-0a91-3468-9c82-a927ec96c539/206-2-7475aee1-70a6-3fe7-bc3e-95f964428d79.iso' index='1'/>
      <backingStore/>
      <target dev='hdc' bus='ide' tray='open'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

So I adapted mine to match.

Detaching it worked fine and gave me:

Also re-attaching was fine.
I did attach/detach the ISO via virt-manager UI as well as via commandline like:
$ virsh attach-disk iso-detach "" hdc --type cdrom --mode readonly
$ virsh attach-disk iso-detach "/var/lib/libvirt/images/ubuntu-20.04.2.0-desktop-amd64.iso" hdc --type cdrom --mode readonly

None of these failed.

From the hipervisor I wasn't able to get the "tray='open'" even when defining it that way at runtime it was not present.
I could get it into that state when ejecting the CD from the guests POV via:
$ eject -m

But even then it detached fine:
$ virsh dumpxml iso-detach | grep -A8 'cdrom'
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/ubuntu-20.04.2.0-desktop-amd64.iso' index='8'/>
      <backingStore/>
      <target dev='hdc' bus='ide' tray='open'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
$ virsh attach-disk iso-detach "" hdc --type cdrom --mode readonly
Disk attached successfully
$ virsh dumpxml iso-detach | grep -A8 'cdrom'
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source index='9'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

So it is unclear to me how you hit this issue, as I tried guest reboots as well as forcing the tray to be open. All ...

Hi gu,
I was trying to reproduce your case and spawned a guest to attach&detach an ISO.

When started the guest had this XMLrepresentation of the cd drive:

So I adapted mine to match.

Detaching it worked fine and gave me:

None of these failed.

But even then it detached fine:
$ virsh dumpxml iso-detach | grep -A8  'cdrom'
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/ubuntu-20.04.2.0-desktop-amd64.iso' index='8'/>
      <backingStore/>
      <target dev='hdc' bus='ide' tray='open'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
$ virsh attach-disk iso-detach "" hdc --type cdrom --mode readonly
Disk attached successfully
$ virsh dumpxml iso-detach | grep -A8  'cdrom'
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source index='9'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

So it is unclear to me how you hit this issue, as I tried guest reboots as well as forcing the tray to be open. All just worked.
Have you done any particular setup step to make this happen?
If you'd have clear steps to reproduce from a guest created from scratch into the error that might be helpful.

P.S. While doing so I realized that you use a machine type of pc-i440fx-5.0.
You reported to use qemu-kvm 1:4.2-3ubuntu6.15 which does not have that type at all.
root@f:~# qemu-system-x86_64 -M ? | grep 5.0
pc-i440fx-wily       Ubuntu 15.04 PC (i440FX + PIIX, 1996)
So something must be wrong in addition to your cdrom issues.
I'd recommend to use the type "ubuntu" which in your case would translate to "pc-i440fx-focal"
Your setup should not work at all as a 5.0 type is not part of that qemu that you are running - so this also seems like an unsupported setup anyway ?

Changed in libvirt (Ubuntu):
status:	New → Incomplete

Revision history for this message

gu (cshaven) wrote on 2021-06-03:

Thank you for your reply，I use the virt-manager and centos7 iso. ubuntu iso will not trigger this
1.attach a centos7 minimal iso.
2.set the boot options cdrom first boot device.
3.start vm ,and install centos 7 ,last step of installtion , is press reboot
4.vm will boot from iso again.
5.then ,detach iso with virt-manager
#tail -f /var/log/syslog
internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'sata0-0-0' is not open

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-03:

Hi,
Thanks for outlining the steps that you follow.

"ubuntu iso will not trigger this" is interesting, so the guest must do something unexpected.
I was fetching the very same iso CentOS-7-x86_64-Minimal-2009.iso and tried this with Focal (as you did) and the virt stack of the most recent Hirsute release.

The defaults of this would create a quiet different guest.
- You had i440fx and the default in virt-manager is q35 for quite a while.
- Also the bus for the cdrom would be SATA by default, I selected IDE as you had in your example.
-> That somehow ties into the odd machine type I asked above which should not work at all in 20.04; your setup must be interesting/complex I guess :-)

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-03:

"4.vm will boot from iso again."
That is due to you having set the boot order manually, usually virt-manager would boot from CD once and not again afterwards.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-03:

Another odd detail I have seen that your error is
internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'sata0-0-0' is not open

But your cdrom isn't sata at all

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-03:

Now I arrived at the same case you had - a slightly off-defaults guest that booted into the ISO again as we have configured it to do it that way. And now - while booted into the ISO you want to detach. Actually that won't work on a physical device either, the CD will refuse to eject as it is in use - something like that could happen here as well.

In both cases (Focal/Hirsute) at this stage it looks like this from the Host:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/CentOS-7-x86_64-Minimal-2009.iso' index='1'/>
      <backingStore/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <boot order='1'/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

Detaching (=selecting to no more apply this iso as backing for the CDrom) this from the virt-manager UI interface gives works just fine.

From the Host it now looks like:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source index='4'/>
      <backingStore/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <boot order='1'/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

If I'd try to use it by now e.g. continue the installer the guest gets an I/O error on the cd, which is pretty much what you'd expect.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-03:

I also booted the - no installed - centos7 and inserted the ISO into the virtual CD.
Then (as your example had tray='open') I ejected the (Virtual) CD via `eject -m`.
Now I have:

Detaching in that state still works fine in both systems.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-03:

Maybe your new examples have used the actual defaults (q35 and sata cdrom) and therefore the recent error messages are that way. But even assuming that still too much is somewhat odd here and I fail to recreate the issue :-/

Sorry, I really tried to get a hold on this issue but there must be more to your use case or your system setup (as by now we've identified quite a bunch of odd details compared to a standard 20.04 system behavior).

I was looking for similar report and found this
https://bugzilla.redhat.com/show_bug.cgi?id=1824722
It looks quite similar to what you see.

If it is that it would be an yet-to-be-solved upstream case.
Could you sort out by goign through the details there if that is really exactly the case you are facing?
And if you are maybe chime in there to revive the bug and driving it to a resolution.

P.S. the bug there is around guest resets which don't match your use-case AFAICS, but still it is similar enough to have a look

Bug Watch Updater (bug-watch-updater) on 2021-06-03

Changed in libvirt (Fedora):
importance:	Unknown → Low
status:	Unknown → Confirmed

Revision history for this message

gu (cshaven) wrote on 2021-06-04:

#10

I create new vm with sata cdrom,machine='pc-q35-4.2' .get the same error
iso :CentOS-7-x86_64-Minimal-1804.iso
set sata cdrom boot first

1.boot from iso and install os ,cdrom show tray is not open, can eject from virt-manager
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/CentOS-7-x86_64-Minimal-1804.iso' index='1'/>
      <backingStore/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <boot order='1'/>
      <alias name='sata0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

2.Complete the installation process,boot from iso again ,the cdrom show tray is open , cannot eject from virt-manager
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/CentOS-7-x86_64-Minimal-1804.iso' index='1'/>
      <backingStore/>
      <target dev='sda' bus='sata' tray='open'/>
      <readonly/>
      <boot order='1'/>
      <alias name='sata0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-06-07:

#11

Hi,
thanks for ruling out the type of the machine and the attachment.

But as I said above I didn't see the same with centos7 guests.
To be sure I had then forced the tray='open' for sata and ide cases but was not hitting the issue either.
Neither on qemu 4.2 nor on 5.2 reproduced this for me so I'm unsure how to help further.

So it seems it fails for you but the very same does not for me.
I don't know what a good next step is at the moment, is this limited to a single (type of) machine and working on others for you?

Revision history for this message

In Red Hat Bugzilla #1824722, jferlan (jferlan-redhat-bugs) wrote on 2021-09-08:

#17

Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Bug Watch Updater (bug-watch-updater) on 2021-09-18

Changed in libvirt (Fedora):
status:	Confirmed → In Progress

Revision history for this message

In Red Hat Bugzilla #1824722, kkiwi (kkiwi-redhat-bugs) wrote on 2022-04-13:

#18

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

Revision history for this message

In Red Hat Bugzilla #1824722, mprivozn (mprivozn-redhat-bugs) wrote on 2022-04-13:

#19

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.

Revision history for this message

In Red Hat Bugzilla #1824722, pm-rhel (pm-rhel-redhat-bugs) wrote on 2022-04-16:

#20

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.

Revision history for this message

In Red Hat Bugzilla #1824722, hhan (hhan-redhat-bugs) wrote on 2022-04-18:

#21

(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?

Revision history for this message

In Red Hat Bugzilla #1824722, mprivozn (mprivozn-redhat-bugs) wrote on 2022-04-19:

#22

(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.

Revision history for this message

In Red Hat Bugzilla #1824722, mprivozn (mprivozn-redhat-bugs) wrote on 2022-07-25:

#23

This seems to be the same issue: https://gitlab.com/qemu-project/qemu/-/issues/933

Revision history for this message

In Red Hat Bugzilla #1824722, khanicov (khanicov-redhat-bugs) wrote on 2022-12-08:

#24

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

Revision history for this message

In Red Hat Bugzilla #1824722, hhan (hhan-redhat-bugs) wrote on 2022-12-13:

#25

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.

Revision history for this message

In Red Hat Bugzilla #1824722, khanicov (khanicov-redhat-bugs) wrote on 2022-12-13:

#26

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

Revision history for this message

In Red Hat Bugzilla #1824722, hhan (hhan-redhat-bugs) wrote on 2022-12-14:

#27

(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

Bug Watch Updater (bug-watch-updater) on 2023-01-14

Changed in libvirt (Fedora):
status:	In Progress → Unknown

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

redhat-bugs #1824722
[POST] Edit
auto-gitlab.com-qemu-project-qemu-- #933
[opened Storage] Edit

Bug watches keep track of this bug in other bug trackers.

Ubuntulibvirt package

libvirtd unable to execute QEMU command 'blockdev-remove-medium'

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
libvirt package