Bug 2027410
Summary: | Clarify that cold-reboot is required when failing to "steal" a console | ||||||
---|---|---|---|---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Lev Veyde <lveyde> | ||||
Component: | BLL.Virt | Assignee: | Arik <ahadas> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Tamir <tamir> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 4.4.8.6 | CC: | ahadas, bugs | ||||
Target Milestone: | ovirt-4.5.0 | Flags: | pm-rhel:
ovirt-4.5?
|
||||
Target Release: | 4.5.0 | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | ovirt-engine-4.5.0 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-04-20 06:33:59 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Was it a cold-reboot (QEMU process was shut down in the process) or a warm-reboot? (In reply to Arik from comment #1) > Was it a cold-reboot (QEMU process was shut down in the process) or a > warm-reboot? It was a normal reboot, what you probably mean by warm-reboot (not a full VM shutdown, followed by a VM start), just as the message suggests. If the meaning of the "reboot" in this place is a full shutdown, I think that we need to be more clear on that. Just like we do in other places, i.e. on VM configuration change, where we specifically say that the new configuration will take place only after the VM will be shutdown. Sure, I just wanted to see if that's a real bug or an improper message - that message was introduced long before introducing reboot-vm in ovirt (https://gerrit.ovirt.org/c/ovirt-engine/+/7496) so it refers to the process of restarting the QEMU process. We can rephrase that part. Verified on RHV 4.5.0-4. Env: - Engine instance with RHV 4.5.0-4 (ovirt-engine-4.5.0-0.237.el8ev) and RHEL 8.6 installed. - 3 hosts with RHV 4.5.0-4 and RHEL 8.6 and with vdsm-4.50.0.10-1.el8ev. Steps: In Admin Portal: 1. Log in as an admin user. 2. Create a 4.7 data center and a 4.7 cluster. 3. Install the hosts and create a new NFS storage domain. 4. Create an RHEL 8.6 VM with Video Type: VGA and Graphics protocol: VNC. 5. Run the VM. 6. Open the VM's console. 7. Log in as another user with administration permissions that isn't a Super User. 8. Open the same VM's console and check that the action is canceled and the appropriate error message is displayed. 9. Power off the VM and run it. 10. As the last user, open a console to the VM. Results (As Expected): 1. Logged in as an admin user. 2. The 4.7 data center and the 4.7 cluster were created. 3. The host was installed and the NFS storage domain was created. 4. The VM was created. 5. The VM was running. 6. The console has opened. 7. Logged in as another admin user. 8. The following error message was displayed: " Console connection denied. Another user has already accessed the console of this VM. The VM should either be rebooted (cold/hard reboot) to allow another user to access it, or changed by an admin to not enforce a reboot between users accessing its console. " 9. The VM was running again. 10. The VM has opened. This bugzilla is included in oVirt 4.5.0 release, published on April 20th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |
Created attachment 1844028 [details] Console connection denied popup Description of problem: The access to VM is not allowed to another user, even after the reboot was performed, despite the message that suggests otherwise. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Start a VM 2. Open a console to the VM 3. Try to open the console to the same VM using a different user account 4. The message appears, that says that the VM was accessed by another user, and it has to be either rebooted, or the configuration must be changed by the admin to not enforce reboot between console accesses by different users. 5. Reboot the VM 6. Try to access the console again Actual results: The message that says that the access is denied still appears (see the attached screenshot) Expected results: The console should open normally, since the reboot was performed Additional info: The message says "admin", but it's better to add a clarification, that it's only RHVM admin that can change this.