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:
What was the actual status when you refreshed? How much time did you wait?
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.
(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).
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?
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.
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 ?
is this after spice connected to the vm? with latest spice-xpi which fixed a similar bug?
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
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.
I'm fine with option A. not sure why we block it. do is it shutdown or a stop?
Guest menu refers to the guest OS menu (windows). Client OS was RHEL 6.2 (CSB).
In user portal we always enable both "Stop" and also "Shutdown" in the "POWERING DOWN" state.
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?
Sure, I can recheck in 3.1.
thanks paul. setting to on_qa
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.