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 1243451 - ISO cannot be unmounted from hypervisor due to CD-ROM lock
Summary: ISO cannot be unmounted from hypervisor due to CD-ROM lock
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 74systemd
TreeView+ depends on / blocked
 
Reported: 2015-07-15 13:16 UTC by William Kokolis
Modified: 2022-03-31 02:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-11 06:44:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Screenshot showing hypervisor question in VirtualBox (90.30 KB, image/png)
2015-07-15 13:16 UTC, William Kokolis 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 6860091 0 None None None 2022-03-31 02:11:00 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.