Bandwidth requirement of the Teradici HW Zeros

I was planning a View infrastructure based on HW Teradici clients, over WAN.

I found this document about the HW Tera clients, which is for PCoIP host cards and zeros, but it applies for zeros and View 4.6 too. The facts:

• The minimum bandwidth for a Teradici based Zero (see previous post and list of devices) is about 1 Mbps. This is the "bandwidth floor" in the firmware settings. Using a Cisco 6500 we limited the effective bandwidth in Layer 2 for the device (Samsung NC190 and NC240, tested separately). We found out, that the client becomes "sluggish" at about 512 Kbps, and the whole session is unusable/unstable below 256 Kbps. This is not a limitation of PCoIP, because it is known to work at about 150 Kbps. It's probably a limitation of the TERA1x00 chip.
• The maximum bandwidth usage as stated in the document above, is 220 Mbps. I can hardly believe that the device can use this much, but who knows. Watching HD video/audio on a dual 24" screen setup, while scanning and copying files over USB probably peaks way above 100 Mbps. The 220 Mpbs theoretical maximum is probably counted with 4 24" monitors daisy chained over 1 Tera chip, with HD audio and video streams and heavy USB usage.
• The average usage that we observed while clicking MS word and such on the 24" (resolution counts bandwidth of course) was about 6-7 Mbps with a minimum usage just above 1 Mbps and maximum peaks at about 13.

Conclusion? The HW Tera devices are not fitted for low bandwidth situations, while they are probably the best technology if You happen to have enough bandwidth/device.

I will try out PCoIP software clients (Windows & HP's Linux one :)) in the near future with the same bandwidths.

The dark truth

Today we learned that Quickprep does not generate a new machine SID (Yes, it IS in the manual), so quickprep'ing 25 VM's won't activate a KMS server. Nice, I had to create a Sysprep'd pool just to trigger KMS...
The worse thing, that sometimes recomposing simply fails because of some kind of AD error etc.
If this happens, You've to manually clean out the failed VM. This is tricky, see http://kb.vmware.com/kb/1008658. You have to run a SviConfig -operation=removesviclone command on the view composer (vCenter) machine, and manually remove the ADAM CN from the View manager. This is done in ADSI edit, as stated in the KB above.
The trick is, sometimes this is not enough. Looks like the clone vanished, in AD Users and Computers mmc snap-in You don't see the incriminated computer's name, but View manager fails to create the VM again, because it still sees it in AD ("A computer with the name xxx already exists in Active Directory.") . Now, this happens when AD does not really delete the computer's account. To circumvent this, You manually recreate a computer account name with the same name as the VM, and delete it again...
Sorry, late night post.

The Linux PCoIP client from HP

There was some hassle about VMware's support for View client on Linux.
The official way to access View from linux is using view open client from http://code.google.com/p/vmware-view-open-client/. Now, this client does NOT support PCoIP, which is a major drawback.
You can access View using PCoIP from your Windows, iPad, or Teradici based device (I prefer Samsung's NC series, but the Wyse P20, the Dell FX100 etc are all the same. A complete list of devices using Teradici's HW is available here).
Android or iOS on the phone are not supported (yet). There is the Wyse PocketCloud, which is a great thing, but for RDP only.
So HP developed it's own version of View client for Linux, the code is probably heavily based on the open client (it uses the same interface, same config files/options...).
This software is for HP's thin clients with a kind of debian based firmware, but luckily it is a simple i386 .deb package.
One can easily download it from HP's site, and use it for his own dark purposes, as stated in this forum thread.
Currently, there is a View 4.5 based client in it, which works as charm with 4.6.
To download the archive, go to HP t5545 Thin Client support (search for the device on HP.com, then choose support), and download the link HP ThinPro Add-On (VMware View Broker) / 4.5.0-293049-1 Rev. A - 12 nov. 2010 - 5.2 Megs. The file is called sp50874.exe. Okay, for lazy people, it is here :) ftp://ftp.hp.com/pub/softpaq/sp50501-51000/sp50874.exe. It will extract a few files to C:\Program Files\Hewlett-Packard\HP ThinPro\3.2\Add-On\View45 by default. We will only need vmware-view-client_4.5.0-293049-1_i386.deb.
If you don't have dpkg (slackware ftw), then simply rename the .deb to whatever.ar, and ar x it. Then in the data.tar.gz you will find the required directory structure.
For 64biters: this will require 32 bit versions of libxml2.so.2 and libpixman-1.so.0, in /usr/lib.
To use USB redirection, there is postinst script in control.tar.gz, that will do the trick.

PCoIP Secure GW - this sh*t works

After some hassle, the new View 4.6 Secure Gateway finally works with PCoIP connections too.
The symptom was simple: PCoIP connections disconnected immediately, while RDP connections did work. I didn't find any log in C:\ProgramData\VMware\VDM\Logs that would hold any information about the disconnects, alll log entries were the same for the PCoIP and the RDP sessions.
I read markbenson's doc at the communities site, and found out that I forgot to check the checkbox on the view connection server administration site to enable the PCoIP on proxied (gateway'd) connections.
This one:

Now I only have 2 concerns.


In the Debug log there is a Java socket error, about some Tunnel IO problem. At first I thought it was some routing/firewall issue, because the SecGW is in a DMZ of course. I think this happens every time, when a client disconnects:

 DEBUG [ab] (4B412F31EACA3A955A8CDB2CBCC06EF6) Tunnel IO problem: java.io.IOException: Bad length com.vmware.vdi.ob.tunnelservice.ab.run(SourceFile:892)

java.io.IOException: Bad length

at simple.http.ChunkedInputStream.doLength(ChunkedInputStream.java:334)

at simple.http.ChunkedInputStream.nextChunk(ChunkedInputStream.java:266)

at simple.http.ChunkedInputStream.parseRead(ChunkedInputStream.java:250)

at simple.http.ChunkedInputStream.readBytes(ChunkedInputStream.java:181)

at simple.http.MonitoredInputStream.read(MonitoredInputStream.java:115)

at java.io.DataInputStream.read(DataInputStream.java:132)

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at java.io.BufferedInputStream.read(BufferedInputStream.java:237)

at com.vmware.vdi.ob.tunnelservice.df.b(SourceFile:1022)

at com.vmware.vdi.ob.tunnelservice.ab.run(SourceFile:763)

at java.lang.Thread.run(Thread.java:619)

This could be anything from a bug in some java code to "working as intended" speeches.

My other thingie is interesting too. Even with 8GBs of RAM, the Security Gateway installation cries for more memory on Win2008R2 SecGW VM:

Of course I did not find any infomation in the View administration Guide regarding the sizing of security servers. Will look it through again sometime.

7.1.3 -> 7.1.4

Workstation 7.1.3 still requires the -I (Ignore scripting errors) to uninstall before installing 7.1.4. And 7.1.4 still requires to rm -rf /etc/vmware* before installing itself. Lame.
I don't think there is much slackware64 QA at VMware's.