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 890012 - tray-open should be 1 after ejects the CD-ROM for virtio-scsi device
Summary: tray-open should be 1 after ejects the CD-ROM for virtio-scsi device
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Hanna Czenczek
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1025178
TreeView+ depends on / blocked
 
Reported: 2012-12-24 10:44 UTC by Sibiao Luo
Modified: 2015-02-12 20:21 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-12 20:17:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sibiao Luo 2012-12-24 10:44:37 UTC 
Description of problem:
tray-open should be 1 after ejects the CD-ROM for virtio-scsi device, there is a existing bug 771610(bug 871321) for IDE device, I think the virtio-scsi also should fix this issue.

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-348.el6.x86_64
qemu-kvm-0.12.1.2-2.348.el6.x86_64
guest info:
# uname -r
2.6.32-348.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1.boot a guest with a virtio-scsi cdrom device.
eg:...-drive file=/mnt/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso,if=none,id=drive-cd-disk,media=cdrom,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,bus=pci.0,addr=0x6,id=scsi0 -device scsi-cd,drive=drive-cd-disk,bus=scsi0.0,id=scsi_cd
2.check the block info:
(qemu) info block
drive-virtio-disk: removable=0 io-status=ok file=/mnt/RHEL6.4-20121212.1-Server-x86_64.raw ro=0 drv=raw encrypted=0
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/mnt/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso ro=1 drv=raw encrypted=0
3.eject the cdrom.
-in monitor:
(qemu) eject drive-cd-disk
-in guest:
] eject -r /dev/sr1
4.check the block info:
  
Actual results:
after step 4,
-in monitor:
(qemu) info block
drive-virtio-disk: removable=0 io-status=ok file=/mnt/RHEL6.4-20121212.1-Server-x86_64.raw ro=0 drv=raw encrypted=0
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
-in guest:
(qemu) info block
drive-virtio-disk: removable=0 io-status=ok file=/mnt/RHEL6.4-20121212.1-Server-x86_64.raw ro=0 drv=raw encrypted=0
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/mnt/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso ro=1 drv=raw encrypted=0

Expected results:
The tray-open value should be 1 after eject it.(Should have same behaviour with host).

Additional info:
Comment 2 Sibiao Luo 2012-12-24 11:09:56 UTC 
BTW, both the pass-through SCSI CD-ROM and emulated SCSI CD-ROM can hit it.

I also tried the qemu-kvm-0.12.1.2-2.295.el6.x86_64, it have no such issue.
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-348.el6.x86_64
qemu-kvm-0.12.1.2-2.295.el6.x86_64

Results:
(qemu) info block
drive-virtio-disk: removable=0 io-status=ok file=/mnt/RHEL6.4-20121212.1-Server-x86_64.raw ro=0 drv=raw encrypted=0
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/mnt/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso ro=1 drv=raw encrypted=0 <------tray-open=0
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
floppy0: removable=1 locked=0 tray-open=0 [not inserted]
sd0: removable=1 locked=0 tray-open=0 [not inserted]
(qemu) eject drive-cd-disk
(qemu) info block
drive-virtio-disk: removable=0 io-status=ok file=/mnt/RHEL6.4-20121212.1-Server-x86_64.raw ro=0 drv=raw encrypted=0
drive-cd-disk: removable=1 locked=0 tray-open=1 io-status=ok [not inserted] <------tray-open=1
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
floppy0: removable=1 locked=0 tray-open=0 [not inserted]
sd0: removable=1 locked=0 tray-open=0 [not inserted]

So, this issue is regression bug, I will make 'Regression' keywords.

Best Regards.
sluo
Comment 4 Sibiao Luo 2012-12-24 11:23:21 UTC 
(In reply to comment #2)

> (qemu) info block
> drive-virtio-disk: removable=0 io-status=ok
> file=/mnt/RHEL6.4-20121212.1-Server-x86_64.raw ro=0 drv=raw encrypted=0
> drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok
> file=/mnt/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso ro=1 drv=raw
> encrypted=0 <------tray-open=0
> ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
> floppy0: removable=1 locked=0 tray-open=0 [not inserted]
> sd0: removable=1 locked=0 tray-open=0 [not inserted]
> (qemu) eject drive-cd-disk
> (qemu) info block
> drive-virtio-disk: removable=0 io-status=ok
> file=/mnt/RHEL6.4-20121212.1-Server-x86_64.raw ro=0 drv=raw encrypted=0
> drive-cd-disk: removable=1 locked=0 tray-open=1 io-status=ok [not inserted]
> <------tray-open=1
> ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
> floppy0: removable=1 locked=0 tray-open=0 [not inserted]
> sd0: removable=1 locked=0 tray-open=0 [not inserted]
> 
> So, this issue is regression bug, I will make 'Regression' keywords.
> 
ignore this comment.
Comment 7 Markus Armbruster 2013-02-21 20:13:14 UTC 
The patch has an unwanted side effect: QMP event DEVICE_TRAY_MOVED gets emitted on shutdown.  Reproducer:

$ qemu-kvm -nodefaults -S -vnc :0 -qmp stdio -drive if=none,id=ide2,media=cdrom -device ide-drive,drive=ide2,bus=ide.1
{"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0}, "package": "(qemu-kvm-devel)"}, "capabilities": []}}
{ "execute": "qmp_capabilities" }
{"return": {}}
{ "execute": "quit" }
{"return": {}}
{"timestamp": {"seconds": 1361477527, "microseconds": 365334}, "event": "SHUTDOWN"}
{"timestamp": {"seconds": 1361477527, "microseconds": 365807}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "ide2", "tray-open": true}}
Comment 20 Hanna Czenczek 2015-01-30 19:04:40 UTC 
Hi Sluo,

Could you please try reproducing the issue? For me it looks like it might have been fixed in the meantime (although I don't know how):

Part of the command line:
  -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x6 \
  -drive id=cd,if=none,aio=native,media=cdrom \
  -device scsi-cd,drive=drive_image1,bus=scsi0.0

QMP:
{'execute':'query-block'}
... {"io-status": "ok", "device": "cd", "locked": true, "removable": true, "tray-open": false, "type": "unknown"} ...

{'execute':'eject','arguments':{'device':'cd'}}
{"error": {"class": "DeviceLocked", "desc": "Device 'cd' is locked", "data": {"device": "cd"}}}
{"timestamp": {"seconds": 1422644074, "microseconds": 791451}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": true}}

{'execute':'query-block'}
... {"io-status": "ok", "device": "cd", "locked": false, "removable": true, "tray-open": true, "type": "unknown"} ...

/* eject -t /dev/sr0 in guest */
{"timestamp": {"seconds": 1422644123, "microseconds": 137187}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": false}}

{'execute':'query-block'}
... {"io-status": "ok", "device": "cd", "locked": false, "removable": true, "tray-open": false, "type": "unknown"} ...

/* eject /dev/sr0 in guest */
{"timestamp": {"seconds": 1422644169, "microseconds": 310648}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": true}}

{'execute':'query-block'}
... {"io-status": "ok", "device": "cd", "locked": false, "removable": true, "tray-open": true, "type": "unknown"} ...

{'execute':'change','arguments':{'device':'cd','target':'fedora.iso','arg':'raw'}}
{"timestamp": {"seconds": 1422644344, "microseconds": 736092}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": false}}
{"return": {}}

{'execute':'query-block'}
... {"io-status": "ok", "device": "cd", "locked": true, "removable": true, "inserted": {"iops_rd": 0, "iops_wr": 0, "ro": false, "drv": "raw", "iops": 0, "bps_wr": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "file": "fedora.iso"}, "tray-open": false, "type": "unknown"} ...

{'execute':'eject','arguments':{'device':'cd'}}
{"error": {"class": "DeviceLocked", "desc": "Device 'cd' is locked", "data": {"device": "cd"}}}
{"timestamp": {"seconds": 1422644387, "microseconds": 117228}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": true}}

{'execute':'query-block'}
... {"io-status": "ok", "device": "cd", "locked": true, "removable": true, "inserted": {"iops_rd": 0, "iops_wr": 0, "ro": false, "drv": "raw", "iops": 0, "bps_wr": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "file": "fedora.iso"}, "tray-open": true, "type": "unknown"} ...


Everything seems fine to me now, but maybe I'm missing something (or just testing the wrong thing...).

Max
Comment 21 Sibiao Luo 2015-02-02 05:04:44 UTC 
(In reply to Max Reitz from comment #20)
> Hi Sluo,
> 
> Could you please try reproducing the issue? For me it looks like it might
> have been fixed in the meantime (although I don't know how):
> 
> Part of the command line:
>   -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x6 \
>   -drive id=cd,if=none,aio=native,media=cdrom \
>   -device scsi-cd,drive=drive_image1,bus=scsi0.0
> 
> QMP:
> {'execute':'query-block'}
> ... {"io-status": "ok", "device": "cd", "locked": true, "removable": true,
> "tray-open": false, "type": "unknown"} ...
> 
> {'execute':'eject','arguments':{'device':'cd'}}
> {"error": {"class": "DeviceLocked", "desc": "Device 'cd' is locked", "data":
> {"device": "cd"}}}
> {"timestamp": {"seconds": 1422644074, "microseconds": 791451}, "event":
> "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": true}}
> 
> {'execute':'query-block'}
> ... {"io-status": "ok", "device": "cd", "locked": false, "removable": true,
> "tray-open": true, "type": "unknown"} ...
> 
> /* eject -t /dev/sr0 in guest */
> {"timestamp": {"seconds": 1422644123, "microseconds": 137187}, "event":
> "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": false}}
> 
> {'execute':'query-block'}
> ... {"io-status": "ok", "device": "cd", "locked": false, "removable": true,
> "tray-open": false, "type": "unknown"} ...
> 
> /* eject /dev/sr0 in guest */
> {"timestamp": {"seconds": 1422644169, "microseconds": 310648}, "event":
> "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": true}}
> 
> {'execute':'query-block'}
> ... {"io-status": "ok", "device": "cd", "locked": false, "removable": true,
> "tray-open": true, "type": "unknown"} ...
> 
> {'execute':'change','arguments':{'device':'cd','target':'fedora.iso','arg':
> 'raw'}}
> {"timestamp": {"seconds": 1422644344, "microseconds": 736092}, "event":
> "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": false}}
> {"return": {}}
> 
> {'execute':'query-block'}
> ... {"io-status": "ok", "device": "cd", "locked": true, "removable": true,
> "inserted": {"iops_rd": 0, "iops_wr": 0, "ro": false, "drv": "raw", "iops":
> 0, "bps_wr": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "file":
> "fedora.iso"}, "tray-open": false, "type": "unknown"} ...
> 
> {'execute':'eject','arguments':{'device':'cd'}}
> {"error": {"class": "DeviceLocked", "desc": "Device 'cd' is locked", "data":
> {"device": "cd"}}}
> {"timestamp": {"seconds": 1422644387, "microseconds": 117228}, "event":
> "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": true}}
> 
> {'execute':'query-block'}
> ... {"io-status": "ok", "device": "cd", "locked": true, "removable": true,
> "inserted": {"iops_rd": 0, "iops_wr": 0, "ro": false, "drv": "raw", "iops":
> 0, "bps_wr": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "file":
> "fedora.iso"}, "tray-open": true, "type": "unknown"} ...
> 
> 
> Everything seems fine to me now, but maybe I'm missing something (or just
> testing the wrong thing...).
> 
Do you use the rhel7 or fedora guest ? As i saw your got the locked event when you do first eject.

It still hit for me with the eject from guest.

host info:
# uname -r && rpm -q qemu-kvm
2.6.32-504.el6.x86_64
qemu-kvm-0.12.1.2-2.451.el6.x86_64
guest info:
# uname -r
2.6.32-504.el6.x86_64

e.g1:...-drive file=my-cdrom.iso,if=none,id=drive-cd-disk,media=cdrom,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,bus=pci.0,addr=0x9,id=scsi1 -device scsi-cd,drive=drive-cd-disk,bus=scsi1.0,id=scsi_cd

/* eject from guest, 'eject /dev/sr1' */
{"timestamp": {"seconds": 1422852145, "microseconds": 602392}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "drive-cd-disk", "tray-open": true}}
{"timestamp": {"seconds": 1422852147, "microseconds": 455103}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "drive-cd-disk", "tray-open": false}}

{'execute':'query-block'}
{"return": [{"io-status": "ok", "device": "drive-system-disk", "locked": false, "removable": false, "inserted": {"ro": false, "drv": "qcow2", "encrypted": false, "file": "/home/RHEL-Server-6.5-64-virtio.qcow2"}, "type": "unknown"}, {"io-status": "ok", "device": "drive-cd-disk", "locked": false, "removable": true, "inserted": {"ro": true, "drv": "raw", "encrypted": false, "file": "my-cdrom.iso"}, "tray-open": false, "type": "unknown"}, {"io-status": "ok", "device": "ide1-cd0", "locked": false, "removable": true, "tray-open": false, "type": "unknown"}, {"device": "floppy0", "locked": false, "removable": true, "tray-open": false, "type": "unknown"}, {"device": "sd0", "locked": false, "removable": true, "tray-open": false, "type": "unknown"}]}

/* eject from guest, 'eject -t /dev/sr1' */
No any QMP event returns.

################Eject from guest, QMP will return tray open and tray close event, while no any QMP event returns when send tray close.

e.g2:...-drive file=my-cdrom.iso,if=none,id=drive-cd-disk,media=cdrom,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,bus=pci.0,addr=0x9,id=scsi1 -device scsi-cd,drive=drive-cd-disk,bus=scsi1.0,id=scsi_cd
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=my-cdrom.iso ro=1 drv=raw encrypted=0
...
{'execute':'query-block'}
{"return": [...{"io-status": "ok", "device": "drive-cd-disk", "locked": false, "removable": true, "inserted": {"ro": true, "drv": "raw", "encrypted": false, "file": "my-cdrom.iso"}, "tray-open": false, "type": "unknown"}...]}

/* eject from HMP, '(qemu) eject drive-cd-disk' */
(qemu) eject drive-cd-disk 
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=1 io-status=ok [not inserted]
...
{"timestamp": {"seconds": 1422852663, "microseconds": 517561}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "drive-cd-disk", "tray-open": true}}
{'execute':'query-block'}
{"return": [...{"io-status": "ok", "device": "ide1-cd0", "locked": false, "removable": true, "tray-open": false, "type": "unknown"}...]}

/* change the iso from HMP monitor */
(qemu) change drive-cd-disk /home/my-cdrom.iso
(qemu) info block
...
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/home/my-cdrom.iso ro=1 drv=raw encrypted=0

{"timestamp": {"seconds": 1422852819, "microseconds": 87741}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "drive-cd-disk", "tray-open": false}}

{'execute':'query-block'}
{"return": [...{"io-status": "ok", "device": "drive-cd-disk", "locked": false, "removable": true, "inserted": {"ro": true, "drv": "raw", "encrypted": false, "file": "/home/my-cdrom.iso"}, "tray-open": false, "type": "unknown"}, {"io-status": "ok", "device": "ide1-cd0", "locked": false, "removable": true, "tray-open": false, "type": "unknown"}...]}

################It works when do eject and change from HMP monitor.

Best Regards,
sluo
Comment 22 Hanna Czenczek 2015-02-02 23:38:17 UTC 
Hi Sluo,

Hm, I cannot reproduce the issue.

I'm testing qemu-kvm 0.12.1.2-2.451.el6 on a Fedora 21 host:

$ git log -1 --oneline | cat
fd8dcf2 Update to qemu-kvm-0.12.1.2-2.451.el6
$ uname -r
3.18.3-201.fc21.x86_64

My guest is CentOS 6.6 minimal (the issue does not appear with Arch Linux either).

$ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 512 -drive if=ide,file=centos66.qcow2,cache=none -drive file=CentOS-6.6-x86_64-minimal.iso,if=none,id=drive-cd-disk,media=cdrom,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,bus=pci.0,addr=0x9,id=scsi1 -device scsi-cd,drive=drive-cd-disk,bus=scsi1.0,id=scsi_cd -qmp stdio
{'execute':'qmp_capabilities'}
{"return": {}}

{'execute':'query-block'}
... {... "device": "drive-cd-disk", ... "inserted": {... "file": "CentOS-6.6-x86_64-minimal.iso"}, "tray-open": false ...} ...

/* eject /dev/sr1 in guest */
{"timestamp": {"seconds": 1422919630, "microseconds": 332001}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "drive-cd-disk", "tray-open": true}}

{'execute':'query-block'}
... {... "device": "drive-cd-disk", ... "inserted": {... "file": "CentOS-6.6-x86_64-minimal.iso"}, "tray-open": true ...} ...

/* eject -t /dev/sr1 in guest */
{"timestamp": {"seconds": 1422919729, "microseconds": 772069}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "drive-cd-disk", "tray-open": false}

{'execute':'query-block'}
... {... "device": "drive-cd-disk", ... "inserted": {... "file": "CentOS-6.6-x86_64-minimal.iso"}, "tray-open": false ...} ...

What looks interesting about your output to me is that first you receive two DEVICE_TRAY_MOVED events, one for the drive being opened and one for it being closed again. But those don't appear at the same time (which would indicate that qemu is misbehaving) but nearly two seconds after each other. Thus, it looks to me like the guest is deliberately closing the tray again after it has been opened.

I don't know an easy way of querying the tray status from inside the guest, though. Could you try to the following sequence?

$ eject /dev/sr1
$ sleep 5
$ eject -T /dev/sr1

If the second eject command does provoke a QMP event about the tray being opened, this would show that the guest is actually aware that the drive has been closed after the first eject command.

If that is the case, I can't think of anything but that it's actually the guest which deliberately closes the drive for some reason or another after it has been opened.

Thank you!

Max
Comment 28 Hanna Czenczek 2015-02-09 15:35:07 UTC 
Hi Sluo,

Using the following command line:

$ /usr/libexec/qemu-kvm -enable-kvm -m 4096 -hda /home/RHEL-Server-6.6-64bit.raw -vnc :42 -drive file=/home/my-cdrom.iso,format=raw,if=none,id=drive-cd-disk,media=cdrom,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,bus=pci.0,addr=0x9,id=scsi1 -device scsi-cd,drive=drive-cd-disk,bus=scsi1.0,id=scsi_cd -qmp stdio

I cannot reproduce the issue on the command line alone (without having logged in in the GUI). Having logged in in Gnome, however, I can reproduce the issue (both when ejecting from the GUI and from the command line). So I think Gnome is at fault here.

Can you confirm that?


Thanks again,

Max
Comment 29 Sibiao Luo 2015-02-12 03:04:28 UTC 
(In reply to Max Reitz from comment #28)
> Hi Sluo,
> 
> Using the following command line:
> 
> $ /usr/libexec/qemu-kvm -enable-kvm -m 4096 -hda
> /home/RHEL-Server-6.6-64bit.raw -vnc :42 -drive
> file=/home/my-cdrom.iso,format=raw,if=none,id=drive-cd-disk,media=cdrom,
> cache=none,werror=stop,rerror=stop -device
> virtio-scsi-pci,bus=pci.0,addr=0x9,id=scsi1 -device
> scsi-cd,drive=drive-cd-disk,bus=scsi1.0,id=scsi_cd -qmp stdio
> 
Correct.

> I cannot reproduce the issue on the command line alone (without having
> logged in in the GUI). 
Cool, good catch. I also can't hit it without logging in GUI.

> Having logged in in Gnome, however, I can reproduce
> the issue (both when ejecting from the GUI and from the command line). So I
> think Gnome is at fault here.
> 
Yes, hit it for me if logging in GUI.
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-504.el6.x86_64
qemu-kvm-0.12.1.2-2.452.el6.x86_64

guest info:
kernel-2.6.32-504.el6.x86_64
# rpm -qa | grep gnome
gnome-keyring-2.28.2-8.el6_3.x86_64
gnome-icon-theme-2.28.0-2.el6.noarch
gnome-python2-gnomevfs-2.28.0-3.el6.x86_64
gnome-backgrounds-2.28.0-2.el6.noarch
libgnomecanvas-devel-2.26.0-4.el6.x86_64
gnome-python2-extras-2.25.3-20.el6.x86_64
gnome-bluetooth-2.28.6-8.el6.x86_64
gnome-themes-2.28.1-6.el6.noarch
gnome-desktop-2.28.2-11.el6.x86_64
gnome-vfs2-smb-2.24.2-6.el6.x86_64
gnome-power-manager-2.28.3-7.el6_4.x86_64
gnome-python2-libwnck-2.28.0-5.el6.x86_64
gnome-menus-2.28.0-4.el6.x86_64
gnome-screensaver-2.28.3-28.el6.x86_64
gnome-python2-2.28.0-3.el6.x86_64
libgnome-2.28.0-11.el6.x86_64
gnome-python2-libegg-2.25.3-20.el6.x86_64
gnome-user-docs-2.28.0-4.el6.noarch
gnome-python2-desktop-2.28.0-5.el6.x86_64
gnome-keyring-pam-2.28.2-8.el6_3.x86_64
system-gnome-theme-60.0.2-1.el6.noarch
libgnomeui-2.24.1-4.el6.x86_64
gnome-python2-applet-2.28.0-5.el6.x86_64
libgnomeui-devel-2.24.1-4.el6.x86_64
gnome-disk-utility-2.30.1-2.el6.x86_64
gnome-utils-2.28.1-10.el6.x86_64
libgnomecanvas-2.26.0-4.el6.x86_64
gnome-bluetooth-libs-2.28.6-8.el6.x86_64
libgnomekbd-2.28.2-2.el6.x86_64
gnome-media-libs-2.29.91-6.el6.x86_64
gnome-mag-0.15.9-2.el6.x86_64
gnome-panel-libs-2.30.2-15.el6.x86_64
gnome-python2-bonobo-2.28.0-3.el6.x86_64
libgail-gnome-1.20.1-4.1.el6.x86_64
libopenraw-gnome-0.0.5-4.1.el6.x86_64
gnome-doc-utils-0.18.1-1.el6.noarch
gnome-disk-utility-libs-2.30.1-2.el6.x86_64
gnome-disk-utility-ui-libs-2.30.1-2.el6.x86_64
gnome-settings-daemon-2.28.2-30.el6.x86_64
gnome-session-xsession-2.28.0-22.el6.x86_64
libgnome-devel-2.28.0-11.el6.x86_64
gnome-desktop-devel-2.28.2-11.el6.x86_64
gnome-user-share-2.28.2-3.el6.x86_64
gnome-panel-2.30.2-15.el6.x86_64
gnome-python2-canvas-2.28.0-3.el6.x86_64
gnome-terminal-2.31.3-8.el6.x86_64
gnome-speech-0.4.25-3.1.el6.x86_64
gnome-keyring-devel-2.28.2-8.el6_3.x86_64
gnome-media-2.29.91-6.el6.x86_64
gnome-applets-2.28.0-7.el6.x86_64
gnome-doc-utils-stylesheets-0.18.1-1.el6.noarch
rhn-setup-gnome-1.0.0.1-18.el6.noarch
gnome-session-2.28.0-22.el6.x86_64
gnome-python2-gconf-2.28.0-3.el6.x86_64
polkit-gnome-0.96-4.el6.x86_64
gnome-vfs2-devel-2.24.2-6.el6.x86_64
gnome-vfs2-2.24.2-6.el6.x86_64
gnome-python2-gnome-2.28.0-3.el6.x86_64
NetworkManager-gnome-0.8.1-75.el6.x86_64
gnome-utils-libs-2.28.1-10.el6.x86_64
compiz-gnome-0.8.2-24.el6.x86_64
gnome-packagekit-2.28.3-9.el6.x86_64
gnome-system-monitor-2.28.0-11.el6.x86_64

Best Regards,
sluo
Comment 30 Hanna Czenczek 2015-02-12 20:17:08 UTC 
Hi,

I think in conclusion we can say that the issue does not appear with all guests, and at least with one of the two guests where I could reproduce it (but maybe this applies to both after all) the issue appears only after having used the GUI login.

Therefore, it appears to me that qemu is not causing the issue but the guest itself is deliberately closing the tray for some reason.

Thus, closing as NOTABUG. If there are objections, feel free to comment and/or reopen the bug.


Once again, thank you Sluo for providing me with the means to investigate the issue.

Max
Comment 31 Hanna Czenczek 2015-02-12 20:21:15 UTC 
On second thought, this is not NOTABUG. Instead, it was just difficult to verify because the guest kept closing the tray pretty much immediately after it had been opened. Changing resolution from NOTABUG to WORKSFORME.

Max
Note You need to log in before you can comment on or make changes to this bug.