RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1368368 - Fail to update source of cdrom after restore
Summary: Fail to update source of cdrom after restore
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: lijuan men
URL:
Whiteboard:
Depends On: 1373264
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-19 08:18 UTC by Pei Zhang
Modified: 2017-08-01 23:53 UTC (History)
6 users (show)

Fixed In Version: libvirt-2.5.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1373264 (view as bug list)
Environment:
Last Closed: 2017-08-01 17:11:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1846 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-08-01 18:02:50 UTC

Description Pei Zhang 2016-08-19 08:18:51 UTC 
Description of problem:
Fail to update source of cdrom after restore

Version-Release number of selected component (if applicable):
libvirt-2.0.0-5.el7.x86_64
qemu-kvm-rhev-2.6.0-21.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. start a guest like following, a cdrom has startupPolicy option.
# virsh dumpxml r73 | grep disk -A 9
......
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/at-dt/change-media/b.iso' startupPolicy='requisite'>
        <seclabel model='selinux' labelskip='yes'/>
      </source>
      <backingStore/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

2. mv the source of cdrom away
#cd /mnt/at-dt/change-media
# mv b.iso b.iso.bak

3. save then restore guest
# virsh save r73 r73.save

Domain r73 saved to r73.save

# virsh restore r73.save
Domain restored from r73.save

4. check the source ISO was dropped.
# virsh dumpxml r73 | grep disk -A 9
   ......
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source startupPolicy='requisite'/>
      <backingStore/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

5. Prepare a new source ISO to update into guest.
# cat cdrom.xml
<disk type='file' device='cdrom'>
        <driver name='qemu' type='raw'/>
        <source file='/mnt/at-dt/change-media/a.iso' startupPolicy='requisite'>
        </source>
        <backingStore/>
        <target dev='hda' bus='ide'/>
        <readonly/>
</disk>

# ls /mnt/at-dt/change-media/a.iso
/mnt/at-dt/change-media/a.iso

6. Fail to update with error.

# virsh update-device r73 cdrom.xml
error: Failed to update device from cdrom.xml
error: internal error: unable to execute QEMU command 'eject': Device 'drive-ide0-0-0' is locked and force was not specified, wait for tray to open and try again

# virsh update-device r73 cdrom.xml
error: Failed to update device from cdrom.xml
error: internal error: timed out waiting for disk tray status update

Actual results:
As step 6, after save restore guest, cannot update new cdrom anymore.It will report error.

Expected results:
Can update successfully.

Additional info:
Comment 2 Peter Krempa 2016-09-05 16:37:14 UTC 
The reason for this problem is that qemu does not deliver the DEVICE_TRAY_MOVED event in the particular case. I've filed a bug with qemu to track it.

The problem can be worked around by using --force right away (with the change-media command). I've also noticed that if the first attempt does not use --force then it's impossible to change the media in a later attempt. I'll post patches to fix that particular issue.
Comment 3 Peter Krempa 2016-09-12 10:27:42 UTC 
Upstream fix so that --force works always:

commit 85c826129b4b2098f9713b3fb8be3e93e1c61d1b
Author: Peter Krempa <pkrempa>
Date:   Mon Sep 5 18:12:00 2016 +0200

    qemu: hotplug: Don't wait if cdrom tray is opened forcibly
    
    Qemu always opens the tray if forced to. Skip the waiting step in such
    case.
    
    This also helps if qemu does not report the tray change event when
    opening the cdrom forcibly (the documentation says that the event will
    not be sent although qemu in fact does trigger it even if @force is
    selceted).
    
    This is a workaround for a qemu issue where qemu does not send the tray
    change event in some cases (after migration with empty closed locked
    drive) and thus renders the cdrom useless from libvirt's point of view.
Comment 5 lijuan men 2017-02-09 08:08:38 UTC 
try the scenario again:
in the step 4 below, there isn't "<source startupPolicy='requisite'/>" ,is it normal?

version:
libvirt-3.0.0-1.el7.x86_64
qemu-kvm-rhev-2.8.0-3.el7.x86_64

steps:
1. start a guest like following, a cdrom has startupPolicy option.
#virsh dumpxml qq | grep disk -A 9
...
 <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/opt/b.iso' startupPolicy='requisite'/>
      <backingStore/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
...

2. mv the source of cdrom away
# cd /opt
# mv b.iso b.iso.bak

3.save then restore guest
# virsh save qq qq.save
Domain qq saved to qq.save

# virsh restore qq.save
Domain restored from qq.save

4. check the source ISO was dropped.
#virsh dumpxml qq | grep disk -A 9
...
 <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>     --->there isn't "<source startupPolicy='requisite'/>" ,is it normal?
      <backingStore/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
...
5. Prepare a new source ISO to update into guest.
# cat cd.xml 
  <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/opt/a.iso' startupPolicy='requisite'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

# ls /opt/a.iso 
/opt/a.iso

6.Update device

# virsh update-device qq cd.xml     -->it is expected.
Device updated successfully

#virsh dumpxml qq | grep disk -A 9
...
 <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/opt/a.iso' startupPolicy='requisite'/>
      <backingStore/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
Comment 6 Peter Krempa 2017-02-24 14:33:29 UTC 
With an empty drive startup policy does not make much sense, since the drive is empty. Once you insert a media and the drive becomes full it starts making sense again so I think the semantics you've described are correct as-is.
Comment 7 lijuan men 2017-04-12 09:37:12 UTC 
(In reply to Peter Krempa from comment #6)
> With an empty drive startup policy does not make much sense, since the drive
> is empty. Once you insert a media and the drive becomes full it starts
> making sense again so I think the semantics you've described are correct
> as-is.

ok
thanks for your reply
mark the bug as verified
Comment 8 errata-xmlrpc 2017-08-01 17:11:42 UTC 
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, 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/RHEA-2017:1846
Comment 9 errata-xmlrpc 2017-08-01 23:53:19 UTC 
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, 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/RHEA-2017:1846
Note You need to log in before you can comment on or make changes to this bug.