Bug 482126 - Login User is not refreshed after VDSM crash/restart
Login User is not refreshed after VDSM crash/restart
Product: Red Hat Enterprise Virtualization Hypervisor
Classification: Retired
Component: vdsm (Show other bugs)
All Windows
medium Severity medium
: rc
: ---
Assigned To: Dan Kenigsberg
Alexey Eromenko
Depends On:
  Show dependency treegraph
Reported: 2009-01-27 13:31 EST by Yaniv Kaul
Modified: 2016-04-26 13:30 EDT (History)
13 users (show)

See Also:
Fixed In Version: vdsm-4.5-9 sm20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-10-18 15:06:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
refresh guest username on recovery (886 bytes, patch)
2009-11-19 06:43 EST, Dan Kenigsberg
no flags Details | Diff

  None (edit)
Description Red Hat Bugzilla 2009-01-27 13:31:14 EST

---- Reported by ykaul@redhat.com 2008-07-06 20:13:35 EDT ----

if you have a server that is running VMs going into non responsive state and then return to function properly, the logged in user name is not refreshed again from the against and remain Unknown this means that any one can connect using spice to those desktops.

---- Additional Comments From bazulay@redhat.com 2008-07-13 01:17:18 EDT ----

Please elaborate on the process.
Though Iwonder how could you log in with no ticket ??
Please specify the exact stages to reproduce , and especially how did you connect to the VM the second time (through the VDC ???)

---- Additional Comments From bazulay@redhat.com 2008-07-16 12:40:16 EDT ----


This is in your domain,
In case a VDS turnes not responding and back to up, please make sure the info is refreshed.
In addition keep in mind that we(vdsm) is implementing the diconnect flag on set ticket which may solve the hijack  issue (but will not solve the refresh issue)


---- Additional Comments From iheim@redhat.com 2008-10-07 01:25:34 EDT ----

1. if guest has no tools, we can't lock, so not sure what behavior should be, wrt to deciding this user should be able to logon/when.
2. if guest has tools, VDC should not allow to connect unless got a response from hyperchannel that the lock action succeeded.
i.e., locking guest and setting ticket should be "transactive"

--- Bug imported by bugzilla@redhat.com 2009-01-27 13:32 EDT ---

This bug was previously known as _bug_ 4438 at http://mantis.tlv.redhat.com/show_bug.cgi?id=4438

Actual time not defined. Setting to 0.0

Comment 1 Perry Myers 2009-05-28 21:54:21 EDT
This bz is listed as ON_QA but no NVR is populated in the Fixed in Version field.  Please populate this field with the brew NVR that contains this fix.  Thanks!

Also, this is in ON_QA without qa_ack set.  Please request qa flag.
Comment 2 Leonid Natapov 2009-08-10 11:52:35 EDT
Still happens on sp183.
Steps to reproduce:
1.Connect to VDC Admin GUI.
2.You must have VM running and user logged in via SPICE.
In this case username in the GUI will look like Administrator@machine's name
3.Go to VDS and run service vdsmd stop (In the GUI you will see that host turns to non responsive,VMs state turns to Unknown and User turns to Unknown.
4.Now start vdsmd service (service vdsmd start).
5.Host will return to be Up,VM - Up. Logged-in User still Unknown.
Comment 3 Omer Frenkel 2009-10-14 04:26:13 EDT
I Checked this issue and seems that VDC get username = Unknown after vdsm restart
Comment 5 Barak 2009-11-10 07:38:38 EST
Please send refresh command via the vmchannel to each vm (guest agent)
It is relevant also after hibernation.
Comment 6 Dan Kenigsberg 2009-11-19 06:42:05 EST
(In reply to comment #5)
> Please send refresh command via the vmchannel to each vm (guest agent)
> It is relevant also after hibernation.  

I just did that. Note that we already send 'refresh' after waking from hibernation.
Comment 7 Dan Kenigsberg 2009-11-19 06:43:34 EST
Created attachment 370318 [details]
refresh guest username on recovery
Comment 8 Alexey Eromenko 2010-01-21 06:27:06 EST
sm30. Fixed, verified.

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