(In reply to Sibiao Luo from comment #0)
> Description of problem:
> flood with "VFS: busy inodes on changed media or resized disk sr1" message
> prompt after eject the scsi-cd cdrom via HMP/QMP monitor, and there still
> have mount relationship after eject it in guest. 
And if you reboot the guest, the mount relationship will disappear and also there is no "VFS" warning message any more.
> 
> Steps to Reproduce:
> 1.boot guest with a IDE cdrom.
    boot guest with a scsi-cd cdrom.
> e.g:...-drive
> file=/home/my-cdrom1.iso,media=cdrom,if=none,id=drive-disk1,format=raw,
> cache=none,aio=native -device virtio-scsi-pci,bus=pci.0,addr=0x8,id=scsi0
> -device scsi-cd,bus=scsi0.0,drive=drive-disk1,id=disk1
> (qemu) info block
> drive-virtio-disk: removable=0 io-status=ok
> file=/home/RHEL-6.5-Snapshot-4-Server-x86_64.qcow2 ro=0 drv=qcow2 encrypted=0
> drive-data-disk: removable=0 io-status=ok file=/home/my-data-disk.raw ro=0
> drv=raw encrypted=0
> drive-disk1: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
> 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]
> 2.login guest.
> # mount
> ...
> /dev/sr1 on /media/CDROM type iso9660
> (ro,nosuid,nodev,uhelper=udisks,uid=0,gid=0,iocharset=utf8,mode=0400,
> dmode=0500)
> # ls -lh /media/CDROM
> total 335M
> -r--------. 1 root root 254M Oct 21 21:45 kerne000.rpm
> -r--------. 1 root root  28M Oct 21 21:45 kernel_2.rpm
> -r--------. 1 root root  40M Oct 21 21:45 kernel_d.rpm
> -r--------. 1 root root  13M Oct 21 21:40 kernel_f.rpm
> 3.eject the ide cdrom via HMP/QMP monitor.
> {"execute":"eject","arguments":{"device":"drive-disk1","force":true}}
> 4.check the info in guest.
> # mount
> # ls -lh /media/CDROM
> # dmesg 
>

Sibiao, can you reproduce it with RHEL7 guest on RHEL6 host, and RHEL6 guest on RHEL7 host?

Also, is the guest running any graphical user interface?

(In reply to Paolo Bonzini from comment #2)
> Sibiao, can you reproduce it with RHEL7 guest on RHEL6 host, and RHEL6 guest
> on RHEL7 host?
Tried the scsi-cd cdrom with your instructions.

1.rhel6.5 host + rhel7 guest:
 not met the flood with "VFS" warning message, but met anther issue that still mount it in guest and there still has files in the mount point, this is rhel7 OS issue, i will separate a rhel7 bug for it.
2.rhel7 host + rhel6.5 guest:
 still hit it with the same results that still have mount relationship after eject the scsi-cd cdrom(nothing in the mount point) and flood with "VFS" warning message.

rhel7 info:
# uname -r && rpm -q qemu-kvm
3.10.0-37.el7.x86_64
qemu-kvm-1.5.3-10.el7.x86_64
rhel6.5 info:
2.6.32-425.el6.x86_64
qemu-kvm-0.12.1.2-2.415.el6.x86_64
 
> Also, is the guest running any graphical user interface?
not, i just login the guest to check the dmesg log and mount relationship.

(In reply to Sibiao Luo from comment #3)
> (In reply to Paolo Bonzini from comment #2)
> > Sibiao, can you reproduce it with RHEL7 guest on RHEL6 host, and RHEL6 guest
> > on RHEL7 host?
> Tried the scsi-cd cdrom with your instructions.
> 
> 1.rhel6.5 host + rhel7 guest:
>  not met the flood with "VFS" warning message, but met anther issue that
> still mount it in guest and there still has files in the mount point, this
> is rhel7 OS issue, i will separate a rhel7 bug for it.
please refer to bug 1025593 in rhel7, both ide and scsi-cd interface can hit it.
> 2.rhel7 host + rhel6.5 guest:
>  still hit it with the same results that still have mount relationship after
> eject the scsi-cd cdrom(nothing in the mount point) and flood with "VFS"
> warning message.
> 
> rhel7 info:
> # uname -r && rpm -q qemu-kvm
> 3.10.0-37.el7.x86_64
> qemu-kvm-1.5.3-10.el7.x86_64
> rhel6.5 info:
> 2.6.32-425.el6.x86_64
> qemu-kvm-0.12.1.2-2.415.el6.x86_64
>  
> > Also, is the guest running any graphical user interface?
> not, i just login the guest to check the dmesg log and mount relationship.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Reassigning to Paolo who's also looking at Bug 1025166.

QE, can this be reproduced on RHEL7 too?

(In reply to Paolo Bonzini from comment #10)
> QE, can this be reproduced on RHEL7 too?


--Can reproduced on rhel6 host +rhel 6 guest
kernel version: 2.6.32-595.el6.x86_64
qemu-kvm-0.12.1.2-2.482.el6.x86_64

Didn't reproduced on RHEL7 host + rhel7 guest
kernel version:3.10.0-327.5.1.el7.x86_64
qemu-kvm-rhev-2.3.0-31.el7_2.5.x86_64

found another issues and please help to confirm, we will tracking another bug if it's really issue:
1. we didn't find the /dev/sr0 messages through mount in guest after step3 and step 6
2. we should eject the disk successfully after executed eject cmd in qemu secondly (I think we should eject successfully at the first time)
the reproduced steps:
1. boot the guest with following cli：

/usr/libexec/qemu-kvm \
-M pc \
-cpu SandyBridge \
-no-user-config -nodefaults -rtc base=utc -no-hpet \
-m 4G \
-smp 4,sockets=2,cores=2,threads=1 \
-enable-kvm \
-name rhel7 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-monitor stdio \
-qmp tcp:0:6660,server,nowait \
-serial unix:/tmp/serial0,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-vga std \
-vnc :0 \
-netdev tap,id=hostnet0,vhost=on \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:00:B6:40:21 \
-drive file=/home/rhel.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,werror=stop,rerror=stop,aio=threads \
-device virtio-blk-pci,scsi=off,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0 \
-drive file=/usr/share/virtio-win/virtio-win-1.8.0.iso,media=cdrom,if=none,id=drive-disk1,format=raw,cache=none,aio=native \
-device virtio-scsi-pci,bus=pci.0,id=scsi0 \
-device scsi-cd,bus=scsi0.0,drive=drive-disk1,id=disk1 \

2.“info block” in qemu monitor 

drive-disk1: /usr/share/virtio-win/virtio-win-1.8.0.iso (raw, read-only)
    Removable device: locked, tray closed
    Cache mode:       writeback, direct
and in guest:
#mount
/dev/sr0 on /run/media/root/virtio-win-1.8.0 type iso9660 (ro,nosuid,nodev,relatime,uid=0,gid=0,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2)

3."eject drive-disk1" in qemu monitor

Device 'drive-disk1' is locked

# info block in qemu monitor
drive-disk1: /usr/share/virtio-win/virtio-win-1.8.0.iso (raw, read-only)
    Removable device: not locked, tray open
    Cache mode:       writeback, direct


4.in guest:
#mount
there no message about /dev/sr0

#dmesg
[   82.710283] VFS: busy inodes on changed media or resized disk sr0

4.in guest:
#mount
there no message about /dev/sr0

#dmesg
[   82.710283] VFS: busy inodes on changed media or resized disk sr0

[root@localhost ~]# ls -lh /dev/cdrom*
lrwxrwxrwx. 1 root root 3 1月  11 15:26 /dev/cdrom -> sr0


5."eject drive-disk1" in qemu monitor again
and "info block" in qemu monitor

drive-disk1: [not inserted]
    Removable device: locked, tray open

6."change drive-disk1 /usr/share/virtio-win/virtio-win-1.8.0.iso" in qemu monitor and in guest:
#mount
there have no message about /dev/sr0

but "info block" in monitor 

drive-disk1: /usr/share/virtio-win/virtio-win-1.8.0.iso (raw, read-only)
    Removable device: locked, tray closed
    Cache mode:       writethrough

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/