Hello, we are currently face with an issue with a small subset of our VM's These are full clones, Windows 7 desktops. We are connecting via Wyse P25 Zero clients with firmware 4.1.2. From time to time (not always, not consistently) the VM will give a black screen after the user returns from a time away from their desk. When this happens, we see data such as the following in the PCoIP server log.
10/15/2013, 13:26:19.827> LVL:0 RC: 0 SERVER :==> WindowProc: Detected WM_DISPLAYCHANGE event (1920 x 1200)
10/15/2013, 13:26:21.576> LVL:1 RC:-500 IMG_FRONTEND :set_display_topology: VMwareResolutionSet_SetDisplayTopology failed (topology result = 0).
10/15/2013, 13:26:21.578> LVL:2 RC: 0 IMG_FRONTEND :Display device[0]: \\.\DISPLAY1 (VMware SVGA 3D)
10/15/2013, 13:26:21.578> LVL:2 RC: 0 IMG_FRONTEND :Display device[0]: states - DISPLAY_DEVICE_ATTACHED_TO_DESKTOP DISPLAY_DEVICE_ACTIVE DISPLAY_DEVICE_PRIMARY_DEVICE
10/15/2013, 13:26:21.580> LVL:2 RC: 0 IMG_FRONTEND :Display device[1]: \\.\DISPLAY2 (VMware SVGA 3D)
10/15/2013, 13:26:21.580> LVL:2 RC: 0 IMG_FRONTEND :Display device[1]: states - DISPLAY_DEVICE_ATTACHED_TO_DESKTOP DISPLAY_DEVICE_ACTIVE
10/15/2013, 13:26:21.582> LVL:2 RC: 0 IMG_FRONTEND :Display device[2]: \\.\DISPLAYV1 (RDPDD Chained DD)
10/15/2013, 13:26:21.582> LVL:2 RC: 0 IMG_FRONTEND :Display device[2]: states - DISPLAY_DEVICE_MIRRORING_DRIVER
10/15/2013, 13:26:21.584> LVL:2 RC: 0 IMG_FRONTEND :Display device[3]: \\.\DISPLAYV2 (RDP Encoder Mirror Driver)
10/15/2013, 13:26:21.585> LVL:2 RC: 0 IMG_FRONTEND :Display device[3]: states - DISPLAY_DEVICE_MIRRORING_DRIVER
10/15/2013, 13:26:21.586> LVL:2 RC: 0 IMG_FRONTEND :Display device[4]: \\.\DISPLAYV3 (RDP Reflector Display Driver)
10/15/2013, 13:26:21.586> LVL:2 RC: 0 IMG_FRONTEND :Display device[4]: states - DISPLAY_DEVICE_MIRRORING_DRIVER
10/15/2013, 13:26:21.591> LVL:2 RC:-500 IMG_FRONTEND :process_display_topology: Failed - 2 displays requested, 4 tries remaining.
10/15/2013, 13:26:21.591> LVL:0 RC: 3 IMG_FRONTEND :open_displays(): Processed display topology request: failed.
10/15/2013, 13:26:21.946> LVL:0 RC: 0 IMG_FRONTEND :resync_windows_topology: new api called successfully
10/15/2013, 13:26:21.946> LVL:0 RC: 0 IMG_FRONTEND :configure_displays: 4 display(s) initially reported!
10/15/2013, 13:26:21.946> LVL:0 RC:-500 IMG_FRONTEND :configure_displays: Warning - displays overlap: [LRTB]: [1920,3839, 0,1199] X [1920,3839, 0,1199]
10/15/2013, 13:26:21.948> LVL:0 RC: 0 SERVER :==> WindowProc: Detected WM_DISPLAYCHANGE event (1920 x 1200)
10/15/2013, 13:26:21.954> LVL:0 RC: 0 IMG_FRONTEND :resync_windows_topology: new api called successfully
10/15/2013, 13:26:21.954> LVL:0 RC:-500 IMG_FRONTEND :open_displays(): Failed to configure displays, resetting devtap.
10/15/2013, 13:26:21.963> LVL:0 RC: 0 IMG_FRONTEND :resync_windows_topology: new api called successfully
10/15/2013, 13:26:21.963> LVL:3 RC: 0 IMG_FRONTEND :reset_devtap: Successfully reset SVGADevTap
10/15/2013, 13:26:21.963> LVL:0 RC:-500 MGMT_IMG :cSW_HOST_IPC::enable_frontend failed. 10 retries remaining. Trying again...
10/15/2013, 13:26:21.963> LVL:0 RC: 0 SERVER :==> WindowProc: Detected WM_DISPLAYCHANGE event (1920 x 1200)
10/15/2013, 13:26:21.976> LVL:0 RC: 0 IMG_FRONTEND :resync_windows_topology: new api called successfully
10/15/2013, 13:26:21.981> LVL:2 RC: 0 SERVER :Desktop switched: EVENT_SYSTEM_DESKTOPSWITCH
10/15/2013, 13:26:22.963> LVL:0 RC: 0 IMG_FRONTEND :Calling open display in Tera2 mode.
10/15/2013, 13:26:23.562> LVL:0 RC: 0 SERVER :==> WindowProc: Detected WM_DISPLAYCHANGE event (1920 x 1200)
10/15/2013, 13:26:23.881> LVL:1 RC: 0 IMG_FRONTEND :set_display_topology: VMwareResolutionSet_SetDisplayTopology succeeded (topology result = 1).
10/15/2013, 13:26:23.881> LVL:0 RC: 1 IMG_FRONTEND :open_displays(): Processed display topology request: successfully.
10/15/2013, 13:26:23.884> LVL:0 RC: 0 IMG_FRONTEND :resync_windows_topology: new api called successfully
10/15/2013, 13:26:23.884> LVL:0 RC: 0 IMG_FRONTEND :configure_displays: 4 display(s) initially reported!
10/15/2013, 13:26:23.884> LVL:0 RC:-500 IMG_FRONTEND :configure_displays: Warning - displays overlap: [LRTB]: [1920,3839, 0,1199] X [1920,3839, 0,1199]
10/15/2013, 13:26:23.885> LVL:0 RC: 0 SERVER :==> WindowProc: Detected WM_DISPLAYCHANGE event (1920 x 1200)
10/15/2013, 13:26:23.887> LVL:0 RC: 0 IMG_FRONTEND :resync_windows_topology: new api called successfully
10/15/2013, 13:26:23.887> LVL:0 RC:-500 IMG_FRONTEND :open_displays(): Failed to configure displays, resetting devtap.
10/15/2013, 13:26:23.891> LVL:0 RC: 0 IMG_FRONTEND :resync_windows_topology: new api called successfully
10/15/2013, 13:26:23.891> LVL:3 RC: 0 IMG_FRONTEND :reset_devtap: Successfully reset SVGADevTap
10/15/2013, 13:26:23.891> LVL:0 RC:-500 MGMT_IMG :cSW_HOST_IPC::enable_frontend failed. 9 retries remaining. Trying again...
10/15/2013, 13:26:24.891> LVL:0 RC: 0 IMG_FRONTEND :Calling open display in Tera2 mode.
10/15/2013, 13:26:24.954> LVL:0 RC: 0 IMG_FRONTEND :configure_displays: 4 display(s) initially reported!
10/15/2013, 13:26:24.954> LVL:0 RC:-500 IMG_FRONTEND :configure_displays: Warning - displays overlap: [LRTB]: [1920,3839, 0,1199] X [1920,3839, 0,1199]
and so on...
The behaviour on the user end is that they get a black screen, followed by a disconnect. The view connection manager console reports them as "connected". We are forced to reset their VM or reboot from vSphere in order to get them reconnected. We found a VMware KB here which indicated this was a result of the computer putting the displays to sleep (in the power policy), so we implemented a group policy to set this to "never" (it also says the issue was resolved after View 5.0, while we are running 5.2). Issue still occuring. Recently, Teradici support (we have a case open with them as well as with VMware) suggested we disable the Shoretel Desktop Sharing Accelerator, so we tried this. Issue still occurred today.
So, has anyone in the community ever come across this, and were you able to fix it? Our users are getting extremely frustrated.
We believe we have solved this. It was related to the connections on the P25 zero clients and which monitor they were plugged into. So, if a user has his left monitor set to primary (as per normal) but the number one display port on the zero client goes to the right monitor, then the 'primary switchup' has to happen in software somewhere along the way. This leads to the display overlap message and sometimes, not every time, the VM would fail to fix it and would end up in a state where we had to reset it from the vSphere client. Since we have swapped all cables to ensure that zero client monitor port one is connected to users primary monitor, this issue has not occurred (two weeks and counting, crossing fingers...). We have a couple users who prefer the right monitor to be their primary so we have set the cables opposite for them.
Couple other things, to be clearer:
- If we check the console of the VM using vSphere, the desktop is running and in the same state as the user left it
- These desktops have 512MB of Video RAM assigned with vSGA, the server underlying has an Nvidia GRID K1
Check display power management (Control Panel/Power Options/Turn off the display). We had to go to "Never" to prevent this problem. Pretty sure Teradici has a KB article about this problem.
Geoff
Hello
We have exactly the same problem. We have also wyse p20 zero client and hp notebooks with software client.
We have now a support case open with vmware. Have you found a solution for the problem?
How many vcpu have you configured for the vm's?
I think the problem has beginn once we have changed from 1vcpu to 2.
Best regards
Simon
We believe we have solved this. It was related to the connections on the P25 zero clients and which monitor they were plugged into. So, if a user has his left monitor set to primary (as per normal) but the number one display port on the zero client goes to the right monitor, then the 'primary switchup' has to happen in software somewhere along the way. This leads to the display overlap message and sometimes, not every time, the VM would fail to fix it and would end up in a state where we had to reset it from the vSphere client. Since we have swapped all cables to ensure that zero client monitor port one is connected to users primary monitor, this issue has not occurred (two weeks and counting, crossing fingers...). We have a couple users who prefer the right monitor to be their primary so we have set the cables opposite for them.
