Bug 1243451

Summary: ISO cannot be unmounted from hypervisor due to CD-ROM lock
Product: Red Hat Enterprise Linux 7 Reporter: William Kokolis <william.kokolis>
Component: systemdAssignee: Jan Synacek <jsynacek>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: hannsj_uhl, jsynacek, systemd-maint-list, udev-maint-list, yzheng
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-11 06:44:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1383699    
Attachments:
Description Flags
Screenshot showing hypervisor question in VirtualBox none

Description William Kokolis 2015-07-15 13:16:50 UTC
Created attachment 1052355 [details]
Screenshot showing hypervisor question in VirtualBox

Description of problem:
Changes in udev's 60-cdrom_id.rules file have made it so that once an ISO image is attached to a guest's virtual CD-ROM drive, it cannot be unmounted from the hypervisor when running under VMware ESX 5.x and VirtualBox 5.  Instead, an 'eject' command must be issued within the guest OS.

When a user/admin attempts to unmount the ISO at the hypervisor layer, the lock causes a question to be raised in the hypervisor asking if you want to override the lock or not.  Until the question is answered, activity on the guest is suspended (that is, the console becomes unresponsive).  If an end user is capable of unmounting an ISO but does not have access directly to the hypervisor to answer the question, it will cause a service outage.

This behavior is, therefore, undesirable as it not only impacts end-users' ability to carry out self-service work, but it also inhibits automation.  This even makes a task as simple as installing the guest tools for the hypervisor in question more difficult than it needs to be.

Version-Release number of selected component (if applicable):


How reproducible:
100%


Steps to Reproduce:
1.  Create a guest running RHEL 7 (or CentOS 7) under either ESX or VirtualBox.
2.  Attach an ISO to the guest using whatever method is appropriate for the hypervisor (such as VMware's "Install VMware Tools" function".  NOTE:  You do *not* need to actually mount the ISO within the guest; simply 'putting it in the tray' is adequate.
3.  Attempt to unmount the ISO via the hypervisor commands (End VMware Tools install).
4.  The guest will become unresponsive after a short period (typically less than 1 minute).
5.  Switch to the hypervisor and select the guest you're using.  You will see a dialog stating that the guest has locked the CD-ROM tray and is preventing the host from ejecting the ISO.  You will be asked if you want to override the lock.

Actual results:
CD-ROM tray is locked and the guest hangs until the hypervisor question is answered.

Expected results:
The ISO should immediately be detached from the guest with no hypervisor-layer interaction.

Additional info:
This problem apparently does not manifest when running guests under KVM.  I do not know if this is because virt-manager is coded to expect and, therefore, work around the problem or something else.

It is possible to work around this behavior by doing the following:
1) Copy /usr/lib/udev/rules.d/60-cdrom_id.rules to /etc/udev/rules.d/
2) Editing the copy in /etc
3) Comment out the line 'IMPORT{program}="cdrom_id --lock-media $devnode"'.
4) Save & reboot / reload udev.

Comment 2 Harald Hoyer 2015-07-16 08:59:27 UTC
(In reply to William Kokolis from comment #0)

> Actual results:
> CD-ROM tray is locked and the guest hangs until the hypervisor question is
> answered.

Well, the "hang" is not udev's fault.

And the same thing is accomplished on real hardware by locking the tray, so it does not open, when the disk is in use by the OS.

(In reply to William Kokolis from comment #0)
> When a user/admin attempts to unmount the ISO at the hypervisor layer, the
> lock causes a question to be raised in the hypervisor asking if you want to
> override the lock or not.  Until the question is answered, activity on the
> guest is suspended (that is, the console becomes unresponsive).  If an end
> user is capable of unmounting an ISO but does not have access directly to
> the hypervisor to answer the question, it will cause a service outage.

Isn't that contradictory? 
"When a user/admin attempts to unmount the ISO at the hypervisor layer"
versus
"does not have access directly to the hypervisor"

Comment 3 William Kokolis 2015-07-16 13:50:32 UTC
(In reply to Harald Hoyer from comment #2)
> (In reply to William Kokolis from comment #0)
> 
> > Actual results:
> > CD-ROM tray is locked and the guest hangs until the hypervisor question is
> > answered.
> 
> Well, the "hang" is not udev's fault.

It's not, no, but there is a setting in the udev rules that overrides the locking, which in turn prevents the hypervisor from pausing the VM to ask a question.  So for most practical purposes udev (specifically the rules regarding the CD-ROM) is to blame.

> And the same thing is accomplished on real hardware by locking the tray, so
> it does not open, when the disk is in use by the OS.

I understand that, and in a physical world it makes sense, but I question whether it's a desirable behavior in a virtual environment.
 
> (In reply to William Kokolis from comment #0)
> > When a user/admin attempts to unmount the ISO at the hypervisor layer, the
> > lock causes a question to be raised in the hypervisor asking if you want to
> > override the lock or not.  Until the question is answered, activity on the
> > guest is suspended (that is, the console becomes unresponsive).  If an end
> > user is capable of unmounting an ISO but does not have access directly to
> > the hypervisor to answer the question, it will cause a service outage.
> 
> Isn't that contradictory? 
> "When a user/admin attempts to unmount the ISO at the hypervisor layer"
> versus
> "does not have access directly to the hypervisor"

No, not really.  I state unmounting at the hypervisor layer to differentiate it from unmounting within the guest OS.  We have an end-user, self-service interface that allows them the ability to perform certain hypervisor-level tasks, such as powering a VM on or off and mounting/unmounting ISOs.  They do not, however, have direct access to the hypervisor's native interface and so cannot answer questions that it asks.

Comment 4 Jan Synacek 2016-11-10 13:15:20 UTC
https://github.com/systemd/systemd/pull/4643

Comment 5 Jan Synacek 2016-11-11 06:44:29 UTC
See the upstream pull request.