Just in case you wondered, or need to configure options not available in the admin gui, the default.ica file can be found under the following path:
/home/kvm/kvm/install/servlet_container/webapps/dt/WEB-INF/etc/proto.ica
Update: 22/08/2012 For VDI in a Box 5.1
One of my dislikes for VDI in a Box is the SSL redirection that takes place as soon as you attempt to log in to the web access portal.
SSL redirection I can live with, but the self signed certificate in VDI in a box can’t even be trusted and added as a known host due to the spaces in the name.
So, if you are doing a proof of concept and like me, can’t be arsed fighting with certificate import on these devices, here’s a quick tip to flat out turn off the SSL redirection for desktop logins.
Fire up winscp, and log into the VDI in a box appliance.
Navigate to /home/kvm/kvm/install/servlet_container/webapps/dt/web-inf
take a copy of the web.xml (you’ll thank me if you balls this up)
edit the Web.xml file and remove the highlighted section below:
Save the file
Putty / SSH to the device and issue a “tc_start” to restart tomcat
Note: For VDI in a Box 5.1, I’ve found early copies of the appliance didnt contain this command. If tc_start is not available, reboot the virtual machine via the console or web gui.
Now browse to the http address, tada! No more silly ssl errors.
NOTE: the admin console will still redirect, if you wish to disable this too, remove the following if statement from /home/kvm/install/serlet_container/webapps/admin/index.jsp
Throughout this blog post, I’m going to be talking about Process Affinity and Process Priority. Understanding these definitions will help. I’m also only targetting server 2008 R2 and Windows 7 for this post.
An issue I see time and time again in Virtual Desktop Infrastructure and Server Based Computing environments is CPU spikes cause sessions to pause and stick. These CPU spikes can be caused by overcommitment or overzealous application usage and the vendors (Citrix, ThreadMaster, RES, Appsense, etc) have come to the rescue frequently with tools to reduce these events from occurring.
The problem with these solutions (Appsense excluded) is they are reactive, I.E. they take a number of seconds to identify a spike and respond by dropping the priority of the process or reducing the Users time on the processor.
These few seconds of high usage, reduce the amount of time the users applications and desktop session can spend on the processor, this reduction of resources cause the VDI desktop of the user to be completely unusable during the pause and ultimately resulting in complaining from the user community. Worse yet, if this is an SBC environment you now have all users on that server locked out!
And all this may sound a bit over the top, but its very easy to reproduce. For example, create a Microsoft Excel sheet and attempt to vlookup over a few thousand cells and watch the processor get chewed up. In this example, yes a vLookup across that many cells would be better served from a server based solution, but what’s stopping your users doing it?… Exactly.
Looking at SBC for a second:
With Server 2008 R2, the Fair Share CPU scheduling feature really is best (free) solution out there for CPU Utilisation management. The processor scheduling is far better than the Citrix equivalent and they also offer a feature (albeit, it feels unfinished) called Windows System Resource Manager to configure the processor affinity along with Process soft rules for performance management.
By setting these extremely intensive Multi-threaded applications to an affinity, we can “Lock” these processes to only run on certain processor cores, allowing the remaining cores to rebalance the rest of the workload. This ultimately, leaves the users session still responsive even if the application no longer responds. Allowing the user to continue working in other application until the intensive process is complete.
The problem with Windows System Resource Manager?
This was my dillema recently with both XenApp & Xendesktop. Ultimately not happy to Pay for a solution, embrace a depreciated tool, or wash my hands of the problem, I decided to write my own tool, complimenting fair share CPU scheduling but allowing affinity and priority locking.
Introducing Threadlocker:
ThreadLocker has been written to help you target known problematic processes and deal with them pro actively.
Threadlocker also has the added benefit of dropping the priority of known grunty processes to idle, meaning the process will use as much CPU as it can, but any other higher priority process can interupt without sluggishness or pauses.
With ThreadLocker you can target these processes and set their Affinity number of processors they can run on:
Or their Process Priority to drop them out of the normal running context:
Threadlocker has been successfully tested on the following platforms:
Download:
Here’s a weird one I came across recently. During a recent XenDesktop proof of concept I noticed the XenDesktop Desktop Delivery Controllers communication with the hypervisor was at best sluggish.
When the DDC’s attempted to communicate with the vSphere SDK the task would take at least 60 seconds. While it was hanging we’d be presented with the following bar looping repeatedly:
Commands sent to vSphere were also very slow, with an average of 30 – 90 seconds between sending a command to the command actually being processed.
While trying to troubleshoot this issue, I ran a “Netstat -ban” while attempting to perform a hypervisor related task and was greeted with the following information:
To my suprise, as you can see above the Citrix SDK management utility (running as the network service account) was sending all requests through a proxy server! Even more strangely, no proxy server issues were encountered anywhere in the environment to explain this delay.
Using “BitsAdmin /util /GetIEProxy NetworkService“, i was able to confirm the proxy configuration was affecting the network service account as below:
Upon further investigation, a default domain policy was applying the “Automatically detect sessions” flag in Windows proxy configuration as below:
This setting was vital to the customers setup, but conflicted badly with XenDesktop. As access to the proxy was not an option, I set about disabling this proxy option for the network service account.
To disable the proxy setting in server 2008 R2 for the network service account, i used the following command:
BitsAdmin /util /SetIEProxy NetworkService NO_PROXY
To double confirm the proxy was now configured, I tried “BitsAdmin /util /GetIEProxy NetworkService” and was presented with the following information:
Once this was in place, I performed a quick restart and XenDesktop began to blaze along as expected.
Weird eh?