This is not a bug, we are precisely emulating the guest's requests.

udev is locking the tray so that the guest will receive "eject request" events.  At this point, there is not much that QEMU can do for eject and change commands.

When doing eject, the guest will receive an eject request.  The response will be to unlock the medium and eject the tray.  If you did "info block" before the second "change" command, you will see that it will report tray-open=1, which is why the second "change" command succeeds.

The workaround is to do "eject" and after a short while "change".  We cannot do anything about this, short of documenting it, but I'll move the bug to libvirt in case they have a bright idea.

Michal, can you comment on this situation and whether there's anything that any component can do?

Sure. After my IRC discussion with Paolo, it is shown libvirt can actually help here a little. I've proposed patches upstream:

https://www.redhat.com/archives/libvir-list/2013-January/msg01845.html

They basically implement Paolo's approach with "eject", wait for a while (libvirt in fact polls for tray to open, with my patches), after which "change" is issued.

Okay, patch pushed upstream:

commit 84c59ffaecc983083e2e885fa59c4f0ec1812656
Author:     Michal Privoznik <mprivozn>
AuthorDate: Thu Jan 24 15:14:14 2013 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Sun Jan 27 08:47:48 2013 +0100

    qemu_hotplug: Rework media changing process
    
    https://bugzilla.redhat.com/show_bug.cgi?id=892289
    
    It seems like with new udev within guest OS, the tray is locked,
    so we need to:
    - 'eject'
    - wait for tray to open
    - 'change'
    
    Moreover, even when doing bare 'eject', we should check for
    'tray_open' as guest may have locked the tray. However, the
    waiting phase shouldn't be unbounded, so I've chosen 10 retries
    maximum, each per 500ms. This should give enough time for guest
    to eject a media and open the tray.

Hence, moving to POST.

Test with: libvirt-1.0.2-1.el7.x86_64

1, start guest with a empty tray
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

2,
virsh # update-device aaa cdrom1.xml 
Device updated successfully

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/iso1.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

3,
virsh # update-device aaa cdrom2.xml    ---> it will wait for 5 seconds
error: Failed to update device from cdrom2.xml
error: operation failed: Unable to eject media before changing it

and tray is open:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/iso1.iso'/>
      <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 # update-device aaa cdrom2.xml 
Device updated successfully

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/iso2.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

4,
in guest, open the tray
# eject /dev/cdrom

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/iso2.iso'/>
      <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 # update-device aaa cdrom1.xml 
Device updated successfully

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/iso2.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>

5,
virsh # update-device aaa cdromnone.xml     ---> it will wait for 5 seconds
error: Failed to update device from cdromnone.xml
error: internal error unable to execute QEMU command 'eject': Device 'drive-ide0-1-0' is locked

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/iso2.iso'/>
      <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 # update-device aaa cdromnone.xml
Device updated successfully

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <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>

And for all steps, cdrom works well in guest.

IMO error msg in step 5 should like in step 3, what do you think?

Correct a typo:
Step4:
virsh # update-device aaa cdrom1.xml 
should be:
virsh # update-device aaa cdrom2.xml

I don't think it should be the same. The difference is, while in step 3 you want to change the ISO, in step 5 you want to just do bare 'eject'. Or if they should be the same, then they should be as in step 5 (the origin of the error is qemu). In step 3 we are just overwriting the qemu error with our own.

(In reply to comment #8)
> I don't think it should be the same. The difference is, while in step 3 you
> want to change the ISO, in step 5 you want to just do bare 'eject'. Or if
> they should be the same, then they should be as in step 5 (the origin of the
> error is qemu). In step 3 we are just overwriting the qemu error with our
> own.

Thanks for your help.
And one more question:

when the cdrom image is mounted in guest, i can update-device successfully without umount it. Is this expect?

virsh # update-device aaa cdrom2.xml 
error: Failed to update device from cdrom2.xml
error: operation failed: Unable to eject media before changing it

virsh # update-device aaa cdrom2.xml 
Device updated successfully

in guest:
before update-device:
#ls /mnt
aaa

after update-device:
#ls /mnt
aaa bbb

That's guest responsibility to lock tray if cdrom is mounted. Some OS allows to eject the tray even if cdrom is mounted so it is not a bug. The update-device command simulates pressing the tray-eject button, removing the old medium and, possibly, inserting a new one, and pressing the buttong again to close the tray. In my experience - I am able to eject mountedd medium as well, however, whenever I try to access the medium again, I am flooded with I/O errors. Moreover, there's nothing that libvirt/qemu can do - mounting a medium is completely in control of the guest OS and is not visible from outside. Having said that, libvirt doesn't know if the medium user wants to change is mounted or not.

I guess the guest agent could be extended to provide a list of mounted medias. But that's really just a workaround. Again, it's guest kernel resposibility to lock the tray.

(In reply to comment #10)
> That's guest responsibility to lock tray if cdrom is mounted. Some OS allows
> to eject the tray even if cdrom is mounted so it is not a bug. The
> update-device command simulates pressing the tray-eject button, removing the
> old medium and, possibly, inserting a new one, and pressing the buttong
> again to close the tray. In my experience - I am able to eject mountedd
> medium as well, however, whenever I try to access the medium again, I am
> flooded with I/O errors. Moreover, there's nothing that libvirt/qemu can do
> - mounting a medium is completely in control of the guest OS and is not
> visible from outside. Having said that, libvirt doesn't know if the medium
> user wants to change is mounted or not.
> 
> I guess the guest agent could be extended to provide a list of mounted
> medias. But that's really just a workaround. Again, it's guest kernel
> resposibility to lock the tray.

Thanks for your information! So i think this bug is verified.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.