Bug 820968

Summary:	User Portal icons did not reflect actual status of a VM.
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Paul Vine <pvine>
Component:	ovirt-engine-userportal	Assignee:	Einav Cohen <ecohen>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Tomas Dosek <tdosek>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.0.2	CC:	bazulay, dyasny, ecohen, iheim, michal.skrivanek, oramraz, Rhev-m-bugs, tjelinek, ykaul
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-04 19:59:16 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:

Description Paul Vine 2012-05-11 13:06:06 UTC

Description of problem:
Status of a VM was not automatically updated to reflect the actual status. This prohibited me to perform any action on the VM from the available icons on the extended user portal until the manual refresh button was clicked. And I had waited past the set refresh time.


Version-Release number of selected component (if applicable):
spice-client-0.8.2-7.el6_2.2.x86_64


How reproducible:
Not sure exactly what caused it to happen but this is what I had done.

Steps to Reproduce:
1. Was connected to a W7 64 VM through Spice client and logged in.
2. Selected shut down from the start menu.
3. It started installing one update and then closed the Spice window.

  
Actual results:
Status of the VM on the extended UP showed it as still running but could not connect, shutdown, or stop. Pause was not available. Had to click refresh to show actual status.


Expected results:
Icons showing possible actions on VM should work without having to click refresh.

Additional info:

Comment 1 Yaniv Kaul 2012-05-13 14:12:19 UTC

What was the actual status when you refreshed? How much time did you wait?

Comment 2 Paul Vine 2012-05-14 12:14:50 UTC

I had waited 3-4 minutes before I refreshed and when I did refresh the system was shut down so that only the run icon was available.

Comment 3 Yaniv Kaul 2012-05-14 12:21:38 UTC

(In reply to comment #2)
> I had waited 3-4 minutes before I refreshed and when I did refresh the system
> was shut down so that only the run icon was available.

I think it's actually not a bug. IIRC, we do not allow to connect without the agent running. I presume the agent was stopped while the VM was going down and installing updates. The same thing would probably happen in a BSOD VM (again - via the user portal - you should be able to connect in any state via the admin portal).

Comment 4 Itamar Heim 2012-06-10 16:10:27 UTC

i guess we don't allow connecting on powering down actually (we don't check agent is running, only that it is installed, with maybe the exception of guest moving to non-responsive state on missing heartbeats from a previously running guest-agent).
paul - was the VM in powering down mode in admin when this happened?

Comment 5 Paul Vine 2012-06-12 15:26:01 UTC

I don't know what triggered it but I can say I wanted 10-15 minutes and the icon status did not update by itself so they were unusable as presented until I did a refresh within user portal.

Comment 6 Barak 2012-07-04 11:47:33 UTC

Sounds to me like the problem is that the spice client disconnected prematurely.
I'm not aware (after asking Einav) of any situation we initiate a spice disconnect due to a STATUS change.

BTW was it userportal or power-userportal ?

Comment 7 Itamar Heim 2012-07-04 19:29:29 UTC

is this after spice connected to the vm? with latest spice-xpi which fixed a similar bug?

Comment 8 Paul Vine 2012-07-09 13:17:13 UTC

This was with pup. Spice was connected, selected shut down from the guest menu, an update was installed as it was coming down, spice windows closed. 
spice-xpi-2.4-4.el6.x86_64

Comment 9 Barak 2012-07-12 08:34:19 UTC

more questions:

1 - when you say 'guest menu' - what do you refer to? (internal guest OS ? or ...)
2 - what client OS was it? fedora 17 ? or ?

Anyway this looks like a spice issue - we never close spice window due to status change.

The only question remaining is should we enable the user to shutdown in this case there are 2 options:

a. always enable stopping the VM always on "POWERING DOWN"
b. do a client side hack - enable shutting down only when spice exited with error (assuming that the spice client teminated with error code)


Einav - prefers option a above.

Comment 10 Itamar Heim 2012-07-12 08:48:36 UTC

I'm fine with option A. not sure why we block it.
do is it shutdown or a stop?

Comment 11 Paul Vine 2012-07-12 11:44:02 UTC

Guest menu refers to the guest OS menu (windows).
Client OS was RHEL 6.2 (CSB).

Comment 12 Tomas Jelinek 2012-08-01 14:26:10 UTC

In user portal we always enable both "Stop" and also "Shutdown" in the "POWERING DOWN" state.

Comment 13 Michal Skrivanek 2012-08-10 07:32:01 UTC

ok, so the only issue is not refreshing the window with correct status(powering down and/or down). this should have nothing to do with the actual ability to stop the vm as this is always allowed in 3.1
unable to reproduce this in 3.1, so if noone objects I'd close it. Paul?

Comment 14 Paul Vine 2012-08-10 12:12:10 UTC

Sure, I can recheck in 3.1.

Comment 15 Itamar Heim 2012-08-15 09:22:26 UTC

thanks paul.
setting to on_qa

Comment 16 Tomas Dosek 2012-08-20 11:18:44 UTC

Verified - si14 - right after the VM was shut down (internally from the VM's start menu) the state of vm in UserPortal (both basic and extended) was refreshed automatically to down.