Patch posted upstream:

https://www.redhat.com/archives/libvir-list/2010-November/msg00328.html

Created attachment 459504 [details]
Add flag to force eject a CDROM

This can be invoked via virDomainUpdateDeviceFlags with the new flag VIR_DOMAIN_DEVICE_MODIFY_FORCE.

Fixed upstream in v0.8.5-61-g96d52fc

commit 96d52fcf43f61a95d3aec44aaf8738a1495e447a
Author: Cole Robinson <crobinso>
Date:   Mon Nov 8 12:52:48 2010 -0500

    qemu: Add flag to force a CDROM eject
    
    QEMU allows forcing a CDROM eject even if the guest has locked the device.
    Expose this via a new UpdateDevice flag, VIR_DOMAIN_DEVICE_MODIFY_FORCE.
    
    This has been requested for RHEV:
    
    https://bugzilla.redhat.com/show_bug.cgi?id=626305
    
    v2: Change flag name, bool cleanups

The new flag name is not the same in RHEL 6.0.z and RHEL 6.1. I do not care which version gives in, but the difference is too ugly to keep.

# rpm -q libvirt ; pydoc libvirt |grep FORCE
libvirt-0.8.1-28.el6.x86_64         VIR_DOMAIN_DEVICE_EJECT_FORCE = 4
libvirt-0.8.1-27.el6_0.2.x86_64     VIR_DOMAIN_DEVICE_MODIFY_FORCE = 4

6.0.z is correct (the backport ended up requiring two patches rather than one, to match a botch in how the proposed patch was applied upstream).  libvirt-0.8.1-28.el6 is NOT the RHEL 6.1 target; it was built merely as a stopgap measure to be able to move the bug into MODIFIED in order to create the z-stream bug in the first place.  The RHEL 6.1 build will automatically pick up the correct name of DEVICE_MODIFY_FORCE as part of a proper rebasing to 0.8.6 or newer.

Lovely. I'll fix vdsm to use to correct API. I'd appreciate if the not-to-be-published series of libvirt-0.8.1-28 onward is either removed from brew or fixed, so as not to mislead others.

Follow the comment 17,that just fixed a part. 
From bug description and steps it need to change a new ISO file.
From the result shows issue still exists.

Test it on build  :
libvirt-0.8.6-1.el6.x86_64
libvirt-client-0.8.6-1.el6.x86_64
qemu-kvm-0.12.1.2-2.128.el6.x86_64
qemu-img-0.12.1.2-2.128.el6.x86_64
kernel-2.6.32-93.el6.x86_64

Test steps:
1.Create ISO file.
# mkisofs -o  /var/lib/libvirt/images/test.iso  /tmp
# mkisofs -o  /var/lib/libvirt/images/test1.iso  /tmp

2.Add that XML in the domain config XML.
..............................   
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
................................   

3.Define and start the domain
# virsh define test.xml 
Domain http_test defined from test.xml

# virsh start http_test
Domain http_test started

4.Log in the guest domain.
# mount /dev/scd0 /mnt

5.# python
Python 2.6.5 (r265:79063, Jul 14 2010, 11:36:05) 
[GCC 4.4.4 20100630 (Red Hat 4.4.4-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> cd="""  <disk type='file' device='cdrom'>
...       <driver name='qemu' type='raw'/>
...       <source file='/var/lib/libvirt/images/test1.iso'/>
...       <target dev='hdc' bus='ide'/>
... </disk>"""
>>> c = libvirt.open('qemu:///system')
>>> d = c.lookupByName('http_test')
>>> d.updateDeviceFlags(cd,libvirt.VIR_DOMAIN_DEVICE_MODIFY_FORCE)
libvir: QEMU error : internal error unable to execute QEMU command 'change': Device 'drive-ide0-1-0' is locked
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 765, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirt.libvirtError: internal error unable to execute QEMU command 'change': Device 'drive-ide0-1-0' is locked

>>> empty="""<disk device='cdrom'>
... <target dev='hdc' bus='ide'/>
... <alias name='ide0-1-0'/>
... </disk>
... """
>>> c = libvirt.open('qemu:///system')
>>> d = c.lookupByName('http_test')
>>> d.updateDeviceFlags(empty,libvirt.VIR_DOMAIN_DEVICE_MODIFY_FORCE)
0

The patch for this which went into libvirt-0.8.6-1.el6.x86_64 was not the right version (unlike the one which went into z-stream package). Could you retest with libvirt-0.8.7-1.el6?

BTW, libvirt-0.8.7 also includes support for --force flag to virsh update-device command, so you are not forced to use python any more.

Packages:
# rpm -qa |grep libvirt
libvirt-client-0.8.7-1.el6.x86_64
libvirt-0.8.7-1.el6.x86_64
libvirt-python-0.8.7-1.el6.x86_64

Steps to Reproduce:
1.Add that XML in the domain config XML.
..............................   
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
................................   

2.Create ISO file.
# mkisofs -o  /var/lib/libvirt/images/test.iso  /tmp

3.Define and start the domain
# virsh define test.xml 
Domain http_test defined from test.xml

# virsh start http_test
Domain http_test started

4.Log in the guest domain.
# mount /dev/scd0 /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only


5.create eject XML
# cat eject.xml 
 <disk type='block' device='cdrom'>
      <target dev='hdc' bus='ide'/>
    </disk>

6.Force eject cdrom 
# virsh update-device http_test eject.xml --force
Device updated successfully

7.Check guest xml
# virsh dumpxml http_test
...
    <disk type='block' 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' unit='0'/>
    </disk>
...

Update success. 

But when check in the guest, the content still mount under /mnt. And when try to change cd under virt-manager with new iso file, window pops out says it will take effect after guest reboot, but after reboot the guest will back to original which because live update take off effect after guest reboot.
Also try to update device after eject, using 
# cat cdrom.xml
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/temp2.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>

# virsh update-device http_test cdrom.xml
error: Failed to update device from cdrom.xml
error: internal error unable to execute QEMU command 'change': Device 'drive-ide0-1-0' is locked

So, update-device can force eject the cdrom. But i'm afraid after eject, can't attach new iso file. And i don't think this is expected. 
So should i file a new bug again this?

This is actually expected. When cdrom is mounted in the guest and you force eject its image, you could probably still see the content of it in the guest because of dentry cache. However, you shouldn't be able to actually read from the cdrom. If you unmount the cdrom in the guest, you shouldn't be able to mount it back.

BTW, does adding --force to the last update-device command succeed? I haven't tested it and I don't even know if qemu supports that, but you can try. Anyway, even if it succeeds, I can image the guest can be pretty confused without unmounting the cdrom and mounting it back.

(In reply to comment #21)
> This is actually expected. When cdrom is mounted in the guest and you force
> eject its image, you could probably still see the content of it in the guest
> because of dentry cache. However, you shouldn't be able to actually read from
> the cdrom. If you unmount the cdrom in the guest, you shouldn't be able to
> mount it back.
> 
^^^ Yep, after unmount the cdrom in the guest, it can't be mounted back.

> BTW, does adding --force to the last update-device command succeed? I haven't
> tested it and I don't even know if qemu supports that, but you can try. Anyway,
> even if it succeeds, I can image the guest can be pretty confused without
> unmounting the cdrom and mounting it back.

^^^ update-device command succeed with --force option. I first umount the cdrom in the guest then run  
# virsh update-device http_test eject.xml --force
Device updated successfully

But the problem is still can't change the cd content. After eject cdrom after step 7 in comment #20, the cdrom is empty now. Try to update it with new iso file by run:

Step 8:
# cat cdrom.xml
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/temp2.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>

# virsh update-device http_test cdrom.xml --force
error: Failed to update device from cdrom.xml
error: internal error unable to execute QEMU command 'change': Device
'drive-ide0-1-0' is locked

So, i think this bug is not fixed yet.

If there is a bug, then it's a separate bug since this bz is asking for force eject and this apparently works now. So moving this BZ back to MODIFIED.

Did you unmount the cdrom in your guest between step 7 and 8? It doesn't really make much sense to try to stick another image in while the guest still thinks the old one is there.

Rechecked it on the following test environment according to comment 20,21,22,23. "force eject" is fixed. so this bug is passed.

bug 676528 has been raised.

Test environment:
libvirt-0.8.7-5.el6
qemu-kvm-0.12.1.2-2.144.el6
kernel-2.6.32-94.el6

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html