Hide Forgot
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:
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.
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.
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>
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.
(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
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