Hide Forgot
Description of problem: I got different results of executing "change-media --eject" when guest was paused. what I did : define,start guest with cdrom --> suspend --> change-media --eject, (fail,give error message) --> resume --> check media exists --> suspend --> change-media --eject, (successful)--> resume --> check the media was ejected. Version-Release number of selected component (if applicable): libvirt-1.3.2-1.el7.x86_64 qemu-kvm-rhev-2.3.0-31.el7_2.8.x86_64 How reproducible: 100% Steps to Reproduce: 1.define and start a guest with cdrom, # virsh domblklist r72 Target Source ------------------------------------------------ hdc /mnt/at-dt/change-media/a.iso vda /mnt/r73_test/r72rls.qcow2 2. suspend the guest, then eject the cdrom. # virsh suspend r72 Domain r72 suspended # virsh list Id Name State ---------------------------------------------------- 3 r72 paused # virsh domblklist r72 Target Source ------------------------------------------------ hdc /mnt/at-dt/change-media/a.iso vda /mnt/r73_test/r72rls.qcow2 3. when guest is paused, eject would fail. # virsh change-media r72 hdc --eject error: Failed to complete action eject on media error: internal error: unable to execute QEMU command 'eject': Device 'drive-ide0-1-0' is locked multi times, it always fails to eject. # virsh change-media r72 hdc --eject error: Failed to complete action eject on media error: internal error: unable to execute QEMU command 'eject': Device 'drive-ide0-1-0' is locked 4. resume guest, check the cdrom device. # virsh resume r72 Domain r72 resumed # virsh domblklist r72 Target Source ------------------------------------------------ hdc /mnt/at-dt/change-media/a.iso vda /mnt/r73_test/r72rls.qcow2 4.1 check domain xml and guest, the cdrom still exists. # virsh dumpxml r72 | grep disk -A 9 <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/at-dt/change-media/a.iso' startupPolicy='optional'> <seclabel model='selinux' labelskip='yes'/> </source> <backingStore/> <target dev='hdc' bus='ide'/> <readonly/> <alias name='ide0-1-0'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> 5. suspend guest again # virsh suspend r72 Domain r72 suspended 5.1 eject cdrom again. eject successfully. # virsh change-media r72 hdc --eject Successfully ejected media. # virsh domblklist r72 Target Source ------------------------------------------------ hdc - vda /mnt/r73_test/r72rls.qcow2 5.2 check domain xml, the cdrom file was ejected. # virsh dumpxml r72 | grep disk -A 9 <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <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> 5.3 resume guest, check again # virsh resume r72 Domain r72 resumed the cdrom was eject. # virsh dumpxml r72 | grep disk -A 9 <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <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> login guest to check, no media in the guest. Actual results: As step5, at the second time suspend guest, it could eject the cdrom. Expected results: It should keep the same result when I eject cdrom if guest is paused. Additional info: I use a host machine to test same scenarios. #virsh nodesuspend --target mem --duration 600 ...... I cannot eject the cdrom after suspending the host machine.
Everything works as expected. A paused guest cannot act on requests from the host to unlock the tray, but it will process it once guest CPUs are running again.
(In reply to Jiri Denemark from comment #2) > Everything works as expected. A paused guest cannot act on requests from the > host to unlock the tray, but it will process it once guest CPUs are running > again. Thanks a lot for your info. It's very helpful. but I still like to know I mean, now I couldn't eject media in the first paused status, but I could eject it in the second paused status. That's what makes me feel confused. Is this also expected result? In this bug,I'm wondering if I can understand it like following: I eject media after I suspend guest at the first time, it would fail because guest has no response for it. After I resume guest, CPUs will execute --eject command, and in my scenario, it looks like it will add "tray=open" into the xml, which makes media could be ejected in the next paused status. Thanks!
Yes, that's correct.