Have you ever received some complaints from either the user community or the help desk indicating the performance on the servers running in your XenServer environment is a bit lacking? I’m sure your first thought is “what ever” I know I built the XenServer Resource Pool with enough horsepower to handle way more than the current workload and then some (N+1 you know). But then shortly after that thought it starts to eat at you and curiosity gets the best of you. So you fire up XenCenter and start looking at the various performance counters on the hosts and subsequently each of the VMs but this is taking up too much time and you think there has to be a better way. Well today is your lucky day because there is and first off it is free and secondly it is a pretty easy utility to use. The command is called xentop which can be accessed either through XenCenter’s access to the host’s console or through the use of an SSH client like PuTTY. I prefer to use PuTTY since the ability to re-size the screen makes for an easier to read display of all of the VMs running than the console window in XenCenter even if you use the scale option or un-dock the window.
As with most commands there is a help option accessible through the use of the command “info xentop” without the quotes of course. You can fire up xentop with or without command line options depending on what you are trying to accomplish or needing to see. By default the statistics are being updated every three seconds but this can be changed by pressing the D key and enter your desired delay (delay between updates) and hit enter. There are a series keys listed across the bottom of the screen which will turn on and off those performance counters. So by pressing the N key it will add network counters and V will add the vCPU counters. If you want to remove those counters just by pressing the key again will turn them off.
Citrix support has a write-up on this utility which is worth referencing since it lays out in a basic sense what the column descriptions are and provides a screenshot of the utility in action. This article can be found here http://support.citrix.com/article/CTX127896
I would recommend trying this utility out and becoming more familiar with this so your time spent trying to find the offending VM will not take you as long going forward.
There are times when configuring some Citrix products (Secure Gateway, Access Gateway, Web Interface) where you are presented with the option of using an IP address or FQDN for the Secure Ticket Authority. Most of us will pause for a moment and think about the ramifications, pros and cons, of using either of those options. Citrix’s view on this is straight forward and as a best practice recommend using the IP address. You can see why this would be the case if you spend a fair amount of your time troubleshooting issues on a daily basis regardless of whether or not you are working on a Citrix, Microsoft or an application issue. The key word is variable. When going through your normal troubleshooting process you try to remove as many variables as possible from the equation. When you use the IP address you eliminate the name resolution aspect from the process.
Now I know you FQDN evangelists are out there and I prefer to use names where ever possible myself, but if you properly document your network, systems and their interactions with each other, then you don’t have anything to worry about. When it comes time to make an IP address change, with the proper documentation you will be able to make a detailed work plan which will incorporate all of the systems and the changes needing to be completed.
As a side note I am a consultant and what I find out in the field is a mixture of both IP addresses and FQDNs being used for the STAs. Either way there are a number of times I find where previous admins/engineers/consultants are not maintaining the STA lists, regardless if they used the IP address or FQDN. If you don’t maintain these lists they will cause issues relating to logins or erratic behavior when launching Published Apps.
I don’t know about you but it seems like Citrix has been accelerating the lifecycles for their products over the past couple of years. Maybe as I get older time is just going by that much faster which makes the product lifecycles seem shorter 🙂
At any rate if you have not been paying attention in a little less than a year from now Citrix will EOL all XenApp products running on Windows Server 2003. Then 3 1/2 months later they will EOL XenApp 6.0 and below on Windows Server 2008 leaving only XenApp 6.5 on WS 2008R2. This applies to XenApp Fundamentals as well. Citrix is maintaining a nice easy to read page covering their products here http://www.citrix.com/lang/English/lp/lp_2317305.asp
If you are not up to date with your XenApp product version, then I would start the planning phase in short order and make sure you are ahead of the curve. Especially if you have not even moved up to a Windows Server 2008R2 based OS because you might have your work cut out for you depending on the applications you are running in your environment.