The agent running on machine <VM> has shut down.

[morrisosu]

Has anyone ran across an issue in View 5 where randomly a VM (we run Win7 32bit) will be unavailable and if the user attempts to connect they will get a "all available desktop sources are busy"?

Upon further examination of the logs in the View admin console, the VM threw the error "The agent running on machine <VM> has shut down, this machine will be unavailable." before the user started having issues.

We never saw this in 4.x and so far its only a minor issue but I'd like to know if anyone else has had this issue, a restart of the VM usually corrects the issue.

Thanks for any ideas,

Shane

[netjim66]

Yes I've seen it. In some cases I updated the VMWare tools (after uninstalling vmware view agent). reboot. Reinstall view agent.

Othertimes just a reboot did the trick.

[gunnarb]

I'm seeing this today with a customer.  Have you made any progress in discovering the cause of this issue?

Gunnar

[etieseler]

I am seeing this on View 4.6 running on ESXi5.1.  It just started. Any ideas why this happens? I have reinstalled the Tools and the View Agent at least twice, but still every time the user logs off, the View Agent is shutdown and I have to inteveine in the morning before they can log back on.

-Ed

[Kablukoff]

i have the same problem...

reinstalling of agent didn't help

what should i do?

Michael

[etieseler]

I will not say the problem is gone, but I did ask the two users this is happening to lock their desktop at the end of the day rather than log off. I have not got a complaint for two work days so far. But in addition to that, I am not even sure they are locking their desktop instead of logging off.

I will come back to this when this issue happens again and perhaps post some of the logs from the View Desktop.

I am in the process of upgrading to the lastest versions of VMware's software, I got the ESXi Hosts and VCenter done, but View is next (And the Tools, View Agent, Virtual Hardware version).

Hopefully its an issue that will be resovled by installing the lastest and greatest versions.

-Ed

[etieseler]

I am still having this issue on two Desktops still. Since this all started I have upgraded to ESXi5.0 and View 5.1 (The CPU's are not supported in ESXi5.1).

I am looking through the debug log on the desktop that is having its agent shutdown but I'm not finding any smoking gun so far.

Is there anyone out there that has had this issue and found a fix? Again, re-installing VMTools and the View Agent has not helped. In the morning I have to power on the Desktop, otherwise the user will not be able to log in.

Here are snippits from the log:

DEBUG (0508-0DEC) <MessageChannel ReceiveThread> [MessageFrameWork] MessageFrameWork Worker Shutdown OnChannelDelete, Name=PCoIPVChan-CLIENT(3724)

DEBUG (0508-0DEC) <MessageChannel ReceiveThread> [ws_vhub] USB channel callback: remoteName: PCoIP Virtual Channels incoming: true  local: true  opened: false

DEBUG (0508-0DEC) <MessageChannel ReceiveThread> [MessageFrameWork] Closed incoming SharedMemory channel from machine desktop.domain.com, user DOMAIN\user

INFO  (0DC4-0A9C) <MainWndLoop> [wssm_desktop] Session manager has been asked to stop as session 1 is logging off,notifying the service to block reconnects while this completes.

DEBUG (0508-138C) <MessageFrameWorkDispatch> [wsnm_desktop] DesktopManager got a SessionEnd message

DEBUG (0508-138C) <MessageFrameWorkDispatch> [wsnm_desktop] commandhandler::OnEndSession sessionId = 1

DEBUG (0508-086C) <MessageChannel ReceiveThread> [MessageFrameWork] MessageFrameWork Worker Shutdown OnChannelDelete, Name=DesktopInstance1

DEBUG (0508-086C) <MessageChannel ReceiveThread> [MessageFrameWork] MessageFrameWork Worker Shutdown OnChannelDelete, Name=SessionManager1

DEBUG (0508-086C) <MessageChannel ReceiveThread> [MessageFrameWork] MessageFrameWork Worker Shutdown OnChannelDelete, Name=TransfersUI

DEBUG (0508-086C) <MessageChannel ReceiveThread> [MessageFrameWork] MessageFrameWork Worker Shutdown OnChannelDelete, Name=UIManager1

DEBUG (0508-0FF0) <MessageChannel ReceiveThread> [MessageFrameWork] MessageFrameWork Worker Shutdown OnChannelDelete, Name=PCoIPVChan-SERVER

DEBUG (0508-0FF0) <MessageChannel ReceiveThread> [ws_vhub] USB channel callback: remoteName: PCoIP Virtual Channels incoming: true  local: true  opened: false

DEBUG (0508-0FF0) <MessageChannel ReceiveThread> [MessageFrameWork] Closed incoming SharedMemory channel from machine desktop.domain.com, user DOMAIN\DESKTOP$

DEBUG (0508-0FE8) <4072> [wsnm_desktop] PCoIPCnx::OnConnectionClosed

DEBUG (0508-0FE8) <4072> [wsnm_desktop] Console session needs to be disconnected

DEBUG (0508-0FE8) <4072> [wsnm_desktop] session::disconnect skipped as session is logging off.

DEBUG (0508-0FE8) <4072> [wsnm_desktop] Started associated portalInfo timer on disconnect

DEBUG (0508-0FE8) <4072> [wsnm_desktop] enabling Display Settings in Control Panel

DEBUG (01A4-0B7C) <SwiftMQ-SessionPool-2> [msgid] Validating message with ID: '32562b25-7d63-XXXX-XXXX-11cb4063a248'.

DEBUG (0508-0D10) <MessageFrameWorkDispatch> [wsnm_desktop] DesktopManager got a DisconnectSession message {SESSION:a397-***-0712}

DEBUG (0508-0D10) <MessageFrameWorkDispatch> [wsnm_desktop] Disconnecting Session 1 (state = Connected) {SESSION:a397-***-0712}

DEBUG (0508-0D10) <MessageFrameWorkDispatch> [wsnm_desktop] session::disconnect skipped as session is logging off. {SESSION:a397-***-0712}

DEBUG (0508-050C) <Main Thread> [wsnm_desktop] WTS_SESSION_LOGOFF, session=1

DEBUG (0508-050C) <Main Thread> [wsnm_desktop] session::remove sessionId = 1

DEBUG (0508-050C) <Main Thread> [wsnm_desktop] Original dynamic timezone restored

INFO  (0508-050C) <Main Thread> [wsnm_desktop] Session ENDED: id=1, user DOMAIN\user, client=(null), connectionId=a39778e5_76fa_4ddd_XXXX_7b8153c30712, userDn=cn=s-1-5-21-2052111302-813497703-XXXXXXXXX-14163,cn=container,dc=vdi,dc=container,dc=xxx

DEBUG (01A4-0B0C) <theEventPublishingManager> [EventPublishingManager] Waiting for message to publish.

DEBUG (0508-050C) <Main Thread> [wsnm_desktop] session::DelayedLogoff user =

DEBUG (0508-050C) <Main Thread> [wsnm_desktop] Delay JMS ENDED notification until fully logged out for session 1 (timeout = 1800 seconds))

DEBUG (0508-050C) <Main Thread> [wsnm_desktop] sessionDelayedLogoff::Add sessionId = 1

DEBUG (0508-050C) <Main Thread> [wsnm_desktop] Check for need to stop PCOIP protocol...

DEBUG (0508-0BA4) <2980> [wsnm] Receive winlogon notification on logoff for vista+

DEBUG (0508-0BA4) <2980> [wsnm_desktop] Add session Id=1 to logoff vista+ session list

DEBUG (0508-0534) <TimerService> [wsnm_desktop] vista+ session delayed for logoff sessionDelayedLogoff::TimerCallback done. sessionId = 1

DEBUG (0508-05D8) <MessageFrameWorkDispatch> [ws_vmx] wsvmx::BroadcastMsg: reset offline SSO request event.

DEBUG (01A4-0598) <Thread-459> [ComponentResponse] Message is ENDED

DEBUG (0508-052C) <Service Main Thread> [wsnm] Start shutdown by sending shutdown to wsnm_jms

INFO  (01A4-0598) <MessageFrameWorkDispatch> [] java bridge exe stopped by shutdown command.

DEBUG (01A4-0598) <Thread-460> [ComponentResponse] Message is SHUTDOWN

DEBUG (01A4-0B08) <theTopicPublishingManager> [TopicPublishingManager] Waiting for message to publish.

DEBUG (01A4-0598) <Thread-461> [EventLoggerService] Info_Event:[AGENT_SHUTDOWN] "The agent running on machine DESKTOP has shut down, this machine will be unavailable": Source=com.vmware.vdi.events.client.EventLogger, Time=Wed Sep 26 15:30:57 GMT-08:00 2012, Severity=INFO, Node=desktop.domain.com, PoolId=pool-name, MachineName=DESKTOP, MachineId=XXXXXXX-18d9-413e-a4b9-69640227648e, Module=Agent, Acknowledged=true

DEBUG (01A4-0598) <Thread-462> [Main] Terminating JMS threads

DEBUG (01A4-0B10) <theMonitor> [Main] ConnectionMonitor interrupted

DEBUG (01A4-0B10) <theMonitor> [Main] JMS monitor thread stopping.

DEBUG (01A4-0598) <Thread-462> [Main] JMS threads terminated

DEBUG (01A4-0598) <Thread-462> [Main] Agent messaging is stopping

DEBUG (0508-059C) <MessageChannel ReceiveThread> [MessageFrameWork] MessageFrameWork Worker Shutdown OnChannelDelete, Name=EventLoggerService

DEBUG (0508-052C) <Service Main Thread> [MessageFrameWork] Closed incoming SharedMemory channel from machine Desktop.domain.com, user DOMAIN\DESKTOP$

INFO  (0508-052C) <Service Main Thread> [wsnm] The VMware View System Service is shutting down

DEBUG (0508-052C) <Service Main Thread> [wsnm] Stop new winlogon notification for vista+

DEBUG (0508-052C) <Service Main Thread> [ws_vmx] VMX Exit Handler

DEBUG (0508-052C) <Service Main Thread> [ws_klog] trace stopped ok

DEBUG (0508-052C) <Service Main Thread> [MessageFrameWork] MessageFrameWork Worker Shutdown, Name=UsbDriverTrace, Channel=00000000

DEBUG (0508-052C) <Service Main Thread> [ws_vhub] Virtual USB Hub Service stopping

DEBUG (0508-052C) <Service Main Thread> [MessageFrameWork] MessageFrameWork Worker Shutdown, Name=UsbRemoteManager, Channel=00000000

INFO  (0508-050C) <Main Thread> [wsnm] The VMware View System Service has stopped

DEBUG (0508-050C) <1292> [MessageFrameWork] runtime onexit called

-Ed

[mf2112]

I am seeing the exact same issue, just upgraded View 5.0.1 to 5.1.2 in the hopes it would be fixed but the same problem occurred again overnight. I have a case opened with VMWare now, they are going through the client logs but I am not hopeful for a fix since it seems to be more widespread than I thought and has gone on for longer than I realized with no fix from VMWare to this point.

[etieseler]

mf2112,

The issue that I had was stemming from two issues. First off, I didn't have the power policy set correctly in View Connection Manager. Please verify that you have the power policy set to 'Ensured Desktops are always powered on' for the power policy for the pool. I had to remove and then re-create the pool to set this policy in my particular situation.

The second issue was that, even though ensuring me that they were definitely NOT shutting down the VM at the end of the day, they in fact, WERE shutting down the VM at the end of the day. Since the power policy was not set to turn on the VM's, they would not boot up.

Please check first your power policy, then you can check through your Event Viewer logs to see if they in fact are doing a shutdown at the end of the day. I believe the View Logs on the VM also log when a user performs a shutdown. Never underestimate an end user in their endeavor to lead you in the wrong direction.

Good luck and let me know what you have found.

Ed

[mf2112]

Hi Ed,

Thanks for replying, most appreciated. I can definitely say that at least one of the problematic machines was not shutdown as it was mine and I logged off at the end of the day yesterday. After discussing with my colleagues, I am sure their machines were not shutdown either but you are correct about users not accurately describing what they were doing (or not doing).

The pool power setting is interesting, we were set to the default "Take no action", so when we logoff, the client machine should not be suspended, but I have changed it to "Ensure desktops are always powered on" to be sure. I am using the High Performance power settings and have disabled all power saving settings there for display, HD, and NIC.

The strange thing is that we haven't changed the View environment in the last several months before the problem started happening a couple weeks ago. We had been on 5.0.1 for months without issues, then about 2 weeks ago this started happening every single night. I upgraded to 5.1.2 in the hope it would be resolved and because I am sure VMWare would have said to do that when we opened the case, but no change at all this morning when I came in.

The only other things we did was to install Windows patches, to both our physical and VDI clients, and that was in the same time frame, so it is entirely possible that this is not a VMWare issue at all but if that is the case I would expect Google to find more results for me and it isn't. Maybe if we are lucky the VMWare support folks may be able to find a clue in the logs to point us in the right direction.

Mike