Hi, can you try connecting after resetting those failed VMs through view admin UI.
Hi, to start with... thank you for helping me...
Indeed a reset resolves the issue on the Windows 7 VM's, but not for every Windows XP VM... and the problem comes back ofcourse.
Can you check if agent services are started in those failed VMs? What does admin UI show as desktop status for those VMs?
( Checking the View Agent installation and status http://kb.vmware.com/kb/1006780 )
Please would you include a bit more information, i.e. logs? The error message itself could be due to a few reasons, and the logs from the connection server (and agent on the relevant VM) will contain the answers, e.g. there are a few specific error codes passed back from the agent which will result in the same error text given to the user but more detailed information in the server logs.
The versions of the VMware View Agent and Connection server are the same = v184.108.40.2063049
The VMware View Agent is started.
If I have a look at the VM using the vCenter -> Virtual Machine Console, then everything is ok and the OS is waiting on an ctrl-alt-del.
Please find attached some of the log files which I have 'till now... the diagnostic folder I didn't include because the dump file is about 3,5 giga.
Thanks for the help.
vdm-sdct-20110228-1135.zip 15.0 MB
This is the bundle from the client which only has the simple result that the server returns to the user, the most recent failures are because the VM is still starting up (STARTUP_IN_PROGRESS) but there are a few errors that are PROTOCOL_ERR_BUSY (latest at 2011-02-28 11:26:47,743). You should look at the logs from the desktop VM to see why this response was returned.
Sorry to be such a rookie, but can someone tell me how I can find these logs or how I can generate them on the VM .... thank you very much for the help....
please follow the procedure given here http://kb.vmware.com/kb/1017939
To obtain diagnostic information from the View Agent:
- Log in to a virtual machine with View Agent installed.
- Open a command prompt and execute: "c:\Program Files\VMware\VMware View\Agent\DCT\support.bat"
- On the desktop, the folder vdm-sdct contains zipped log files.
- To enable advanced debug logging:
- Open a command prompt and execute: "c:\Program Files\VMware\VMware View\Agent\DCT\support.bat" loglevels
- When prompted, press 2 to enable advanced logging.
Sorry for not giving you a link to the support tool gathering process, sometimes I forget other people have no idea what this is. Anyway, down to the analysis...
In the agent logs you can see the session request come in:
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] DesktopManager got a StartSession message
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] commandhandler::startSession: Received windows credentials for SSO
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Starting protocol PCOIP...
2011-03-02 06:50:14,604 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Launch PCoIP server.
This in turn launches the pcoip_server process:
03/02/2011, 06:50:14.745> LVL:2 RC: 0 AGENT :Launching pcoip_server_win32
03/02/2011, 06:50:14.745> LVL:2 RC: 0 AGENT :Optional log file path specified as "D:\Documents and Settings\All Users\Application Data\VMware\VDM\logs\"
03/02/2011, 06:50:14.854> LVL:2 RC: 0 AGENT :VMWare's launcher code worked.
03/02/2011, 06:50:15.854> LVL:2 RC: 0 AGENT :Waiting for ready message.
03/02/2011, 06:51:14.933> LVL:2 RC: 0 AGENT :Server has timed out or server has quit in wait loop.
03/02/2011, 06:51:14.933> LVL:0 RC: 0 AGENT :Server has timed out or server has quit.
Note that we're waiting for a minute before timing out. This is blocking the retry requests also, which is where the busy error comes from:
2011-03-02 06:50:24,526 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] commandhandler::startSession: Received windows credentials for SSO
2011-03-02 06:50:24,526 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Starting protocol PCOIP...
2011-03-02 06:50:24,542 DEBUG <MessageFrameWorkDispatch> [wsnm_desktop] Requested protocol for session is not available, user XXX
2011-03-02 06:50:24,542 DEBUG <Thread-1403> [ComponentResponse] Reponse directed to:ID:/127.0.0.1/-6534047654062958589/429034/0
2011-03-02 06:50:24,542 DEBUG <Thread-1403> [ComponentResponse] Message is ...<ERROR-CODE>PROTOCOL_ERR_BUSY</ERROR-CODE>...
Here are the pcoip_server logs from the launch:
03/02/2011, 06:50:15.745> LVL:2 RC: 0 COMMON :-- pcoip_server begins.
03/02/2011, 06:50:16.042> LVL:1 RC: 0 SCNET :tera_cert_load_root_certificate (root): err=-500
03/02/2011, 06:50:16.042> LVL:0 RC:-500 ASSERT :init_managers at line number 118.
03/02/2011, 06:50:16.151> LVL:0 RC:-500 COMMON :Critical Exception/Reset Detected!! Saving a minidump file...
03/02/2011, 06:50:16.292> LVL:0 RC:-500 COMMON :Minidump File saved as D:\Documents and Settings\All Users\Application Data\VMware\VDM\logs\pcoip_server_2011_03_02_000010c0.dmp
So the pcoip_server process is crashing on an assert. There are a lot of these. I don't know why, I've not seen this before - you'll need to raise a support request and include this agent bundle (it has also collected the dump files for analysis).
A support request is on route.... hopefully this issue can be resolved very quickly... Many thanks for the help.
Hi, VMware support noticed a couple of things (logs) which resulted in disabling (test purpose) the Symantec Endpoint Protection agent (AV + FW) and Ta Daaaa everything worked. Now what they noticed was the status 'Disconnected' in the 'Inventory' tab of my desktop pool, eventhoug the VM is online. I already knew that SEP can and will give you a hard time, but this is a new one... and of course no log's within the SEP agent shows me something I can use... Has someone an idee on this one.....
Obviously it was Symantec Endpoint Protection which locked files and folders of the VMware View Agent...