Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1359071 - the result of change-media --eject is different from the result in guest
Summary: the result of change-media --eject is different from the result in guest
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Pavel Hrdina
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-22 08:51 UTC by Pei Zhang
Modified: 2016-11-03 18:50 UTC (History)
6 users (show)

Fixed In Version: libvirt-2.0.0-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 18:50:58 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2577 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2016-11-03 12:07:06 UTC

Description Pei Zhang 2016-07-22 08:51:11 UTC
Description of problem:
Using change-media --eject with or without --force, the result from command is different with the result in guest.

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

How reproducible:
100%

Steps to Reproduce:
It is better preparing a guest with GUI.

1. Define and start a guest like following
# virsh dumpxml r72 | grep disk -A 9
    ......
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/iso/RHEL-7.2-20151030.0-Server-x86_64-boot.iso'>
        <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>
......

# virsh domblklist r72
Target     Source
------------------------------------------------
vda        /tmp/zp/r7q2.img
hda        /mnt/iso/RHEL-7.2-20151030.0-Server-x86_64-boot.iso

Login guest to check, the cdrom is moutned automatically, we can check files in the mount point.

2. Using change-media to eject the media.
2.1 change-media eject media without --force

# virsh change-media r72 --eject hda
error: Failed to complete action eject on media
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 domblklist r72
Target     Source
------------------------------------------------
vda        /tmp/zp/r7q2.img
hda        /mnt/iso/RHEL-7.2-20151030.0-Server-x86_64-boot.iso

As above, we can see that the change-media return error and domblklist can list the media. But actually, in the guest, the media is already missing. We cannot see it.

eject media again.
# virsh change-media r72 --eject hda
Successfully ejected media.
# virsh domblklist r72
Target     Source
------------------------------------------------
vda        /tmp/zp/r7q2.img
hda        -

2.2 change-media eject media with --force.
As I said before, the media is mounted automatically. We can use "df -h" / "mount" to check. We can access the media.

# virsh domblklist r72
Target     Source
------------------------------------------------
vda        /tmp/zp/r7q2.img
hda        /mnt/iso/RHEL-7.2-20151030.0-Server-x86_64-boot.iso

change-media with --force, it can be ejected at first time.

# virsh change-media r72 --eject hda --force
Successfully ejected media.

# virsh domblklist r72
Target     Source
------------------------------------------------
vda        /tmp/zp/r7q2.img
hda        -

However, the media is still in the guest, we can access this media, read the file in the media.


Actual results:
As step 2.1 --eject report fail to eject, but the media is ejected from the guest.
As step 2.2 --eject --force report eject successfully, but the media is still in the guest.

Expected results:
1. The result of change-media should give the correct result of the guest.
2. From bug https://bugzilla.redhat.com/show_bug.cgi?id=1318569, we know change-media can eject successfully at first time and it has no need to use --force.

Additional info:

Comment 2 Pavel Hrdina 2016-07-22 11:31:56 UTC
(In reply to Pei Zhang from comment #0)
> 2. Using change-media to eject the media.
> 2.1 change-media eject media without --force
> 
> # virsh change-media r72 --eject hda
> error: Failed to complete action eject on media
> 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

This is a bug and I'll backport it shortly, there is a fix already in upstream
libvirt.  We should wait until it gets unlocked and properly eject and remove
the media from the guest.  After the patch is backported you only need to run
the command without --force once and libvirt will handle it for user.

> # virsh domblklist r72
> Target     Source
> ------------------------------------------------
> vda        /tmp/zp/r7q2.img
> hda        /mnt/iso/RHEL-7.2-20151030.0-Server-x86_64-boot.iso
> 
> As above, we can see that the change-media return error and domblklist can
> list the media. But actually, in the guest, the media is already missing. We
> cannot see it.

This is because the first eject sends a request to the guest OS to unlock the tray
so the media could be safely removed.  When the OS gets the request it should unmount
the media and unlock the tray to allow remove the media from tray.  After the media
is unlocked the second command will actually remove the media from the device.  But
like I said, this all should be done automatically by libvirt and it will be fixed.

> eject media again.
> # virsh change-media r72 --eject hda
> Successfully ejected media.
> # virsh domblklist r72
> Target     Source
> ------------------------------------------------
> vda        /tmp/zp/r7q2.img
> hda        -
> 
> 2.2 change-media eject media with --force.
> As I said before, the media is mounted automatically. We can use "df -h" /
> "mount" to check. We can access the media.
> 
> # virsh domblklist r72
> Target     Source
> ------------------------------------------------
> vda        /tmp/zp/r7q2.img
> hda        /mnt/iso/RHEL-7.2-20151030.0-Server-x86_64-boot.iso
> 
> change-media with --force, it can be ejected at first time.
> 
> # virsh change-media r72 --eject hda --force
> Successfully ejected media.
> 
> # virsh domblklist r72
> Target     Source
> ------------------------------------------------
> vda        /tmp/zp/r7q2.img
> hda        -
> 
> However, the media is still in the guest, we can access this media, read the
> file in the media.

If you use --force there will be no event send to the guest OS and therefore
the guest OS still thinks that the media are present.  You are probably able
to read from it some files that are already cached by the guest OS but if you
try for example copy the whole media to disk there will be an IO error, because
the media are not in the CDROM device anymore.  This is expected behavior and
it's the same behavior as with the real HW.

> Actual results:
> As step 2.1 --eject report fail to eject, but the media is ejected from the
> guest.
> As step 2.2 --eject --force report eject successfully, but the media is
> still in the guest.
> 
> Expected results:
> 1. The result of change-media should give the correct result of the guest.
> 2. From bug https://bugzilla.redhat.com/show_bug.cgi?id=1318569, we know
> change-media can eject successfully at first time and it has no need to use
> --force.

So to summarize all the information:

Using "virsh change-media r72 --eject hda" is required only once and if the guest OS
is able to unlock and unmount the media it will be also removed from the device, however
the guest OS can decide to ignore the eject request and still keep the media mounted,
in this case the command will fail but also the media will remain mounted in the guest OS.

The second part with --force is expected behavior and it's not a bug.

Comment 3 Pavel Hrdina 2016-07-22 11:52:05 UTC
Upstream commit:

commit 6574a01a439cb86a2e53c72346ada8bc9033d140
Author: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Date:   Fri Jul 8 12:30:26 2016 +0200

    qemu: hotplug: fix changeable media ejection

Comment 6 lijuan men 2016-08-04 09:11:34 UTC
verify the bug

version:
libvirt-2.0.0-4.el7.x86_64
qemu-kvm-rhev-2.6.0-18.el7.x86_64

steps:
1. Define and start a guest like following
...
 <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/admin.qcow2'/>
      <target dev='sda' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/RHEL-7.2-20151030.0-Server-x86_64-dvd1.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
...

[root@localhost ~]# virsh domblklist bios
Target     Source
------------------------------------------------
sda        /var/lib/libvirt/images/admin.qcow2
hda        /var/lib/libvirt/images/RHEL-7.2-20151030.0-Server-x86_64-dvd1.iso

Login guest to check, the cdrom is moutned automatically, we can check files in the mount point.



2. use change-media to eject media without --force
[root@localhost ~]# virsh change-media bios  --eject hda
Successfully ejected media.

[root@localhost ~]# virsh domblklist bios
Target     Source
------------------------------------------------
sda        /var/lib/libvirt/images/admin.qcow2
hda        -

In the guest,the media is ejected

Comment 8 errata-xmlrpc 2016-11-03 18:50:58 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://rhn.redhat.com/errata/RHSA-2016-2577.html


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