Bug 1464396 - Pool VMs console disconnect action revert to "lock screen" instead of "shutdown virtual machine"
Pool VMs console disconnect action revert to "lock screen" instead of "shutdo...
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
4.1.2.2
x86_64 Linux
high Severity high (vote)
: ovirt-4.2.0
: ---
Assigned To: Tomas Jelinek
Vladimir
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-23 06:52 EDT by paul
Modified: 2018-02-22 04:58 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The "console disconnect action" was not stored in ovf Consequence: After restart, the "console disconnect action" always reverted to the default, which is lock screen Fix: Added it to the ovf Result: Now the "console disconnect action" is preserved during restarts.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-02-22 04:58:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 84632 master MERGED core: console disconnect action was not saved in OVF 2017-11-24 09:11 EST

  None (edit)
Description paul 2017-06-23 06:52:39 EDT
Description of problem:
The vms in a pool should shutdown after console disconnect (recommended configuration). But after creating and using the vms a few times the console disconnect action is changed to "lock screen".

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


How reproducible:
varies a bit. Sometimes the change is already after the first initial run. Sometimes the vm needs a few cycles of start-up, console connect, console disconnect, shutdown. But after a while all vms in the pool have "lock screen" as console disconnect action.

Steps to Reproduce:
1.create pool
2.do initial runs vms
3.do few cycles of start-up, connect, disconnect, shutdown

Actual results:
in all vms the console disconnect action reverts to "lock screen" (greyed out)

Expected results:
all vms console disconnect actions should stay "shutdown virtual machine" (greyed out)

Additional info:
The console disconnect action is set to "shutdown virtual machine" in:
- original vm > console options
- template based on the original vm > console options
- Pool based on template > console options

I does not matter if I choose in Pool set-up the template(x) or "latest template"
Comment 1 paul 2017-06-26 09:00:40 EDT
Found out this happens when the machine is started as "stateless". It does not matter if this is done as an pre-started machine or as a machine started by user in the UserPortal.

This has the unwanted implication these vms are not available anymore in the pool for other users (even if the user logged out) because of "strict user checking". According to [1] strict user checking is recommended ("Disable strict checking with caution, because you can expose the previous user's session to the new user.")

[1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/virtual_machine_management_guide/appe-reference_settings_in_administration_portal_and_user_portal_windows#sect-Explanation_of_Settings_in_the_New_Virtual_Machine_and_Edit_Virtual_Machine_Windows
Comment 2 Tomas Jelinek 2017-07-19 02:29:26 EDT
This actually happens also on normal stateless VMs (not only pooled ones).
Targeting 4.2
Comment 3 Vladimir 2018-02-13 08:47:01 EST
Verified on 4.2.1.6-0.1.el7

Scenarios:
1. Create stateless VM with every console action, reboot vm multiple times, check that action stays the same - PASS
2. Create pool with every console action, reboot vms multiple times, check that action stays the same - PASS
3. Create usual VM with every console action, reboot vm multiple times, check that action stays the same - PASS
Comment 4 Sandro Bonazzola 2018-02-22 04:58:39 EST
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

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