I've been working with VMware VIEW since it was initially released and as you can imagine the system requirements have changed quite considerably over the years. I remember in version 1.0 when a 1vCPU VM with 2GB of memory was just fine. Upon review of the documentation associated with VIEW 5.0 it turns out the reconfigured requirements are much much higher. If sizing is not properly done it can actually cause application issues that require the re-installation of the application even if you correct the vCPU count and Memory count on the VM. The current broker recommendation in VIEW 5 is 4 vCPU's and 10GB of memory for any VIEW connection server servicing over 50 VM's. Now the big question I had was why the requirement is so high. I was recently alerted to the problem you can encounter while working with a customer on an upgrade.
It doesn't tell you in the documentation why the 10GB is the number they chose, but I think we may have stumbled across the reason later in the documentation around page 60 or 65 of the VIEW installation guide. It appears that if you start out very small with your memory at say 4GB when you install the VIEW connection server, some java components get installed and configured, and there is a glaring disadvantage. Something called the java heap size. It appears that this is the amount of memory that can be allocated to the JVM for processing transactions related to VIEW. If you use anything under 10GB of memory with a Connection Server your heap size is 512MB. If you size with 10GB or more memory the heap size is 2GB. There is a huge difference here. It appears the only supported way to fix this is to actually uninstall and re-install the VIEW connection server software. As long as you are not in a single connection server environment this shouldn't be an issue. I suspect we can uninstall VIEW and re-install to modify the Java heap size to the 2GB. All configuration data is stored in the ADAM database, so we shouldn't have much to change after re-install. The only thing I can think of is KIOSK mode, just making sure you re-enable it after re-installation. See the KB Article below for more information.
Monday, April 9, 2012
I ran into an issue, that I haven't seen before, with a customer. Big thanks to Karl for helping me out with the solution to this one. Basically the issue is that when you are using a Multi-Monitor system, and you want to drag a windowed application from one monitor to the other. The screen has "Lag" meaning the windows is jumpy or glitchy as you drag from screen 1 to screen 2. This issue can occur when you have;
- Windows 7 (32 or 64 bit)
- Virtual Machine hardware 8
- VIEW agent 5
- A multi-display client
The resolution to this is to simply add an entry into the *.vmx file of the VM. The entry is to be added to the end of the VMX file and below is the entry.
mks.poll.headlessRates="1000 100 2"
You can find more details in the VMware KB article located here