You are planning for a WANScaler implementation in your datacenter. For redundancy, you have multiple physical WAN Links and are planning to use the WANScalers in the simple "in-line" deployment in each one of the links.
While the WANScaler supports this configuration natively with the "group mode" feature set, network architects may wish to use an external link load balancing method instead. Depending on your network architecture, group mode can lead to additional traffic on the LAN side as network architects may not have the luxury of a separate network to handle the group mode related traffic .

This is where Citrix NetScaler can come to the rescue in a powerful way. NetScaler supports link load balancing capabilities that are well described in the product documentation. However, when designing for link load balancing with WANScaler in the picture, it is critical to ensure that the WANScaler appliances see all TCP segments associated with a connection in both directions. Therefore, special considerations need to be taken when designing link load balancing for WANScaler implementations:

(a) For connections initiated in the datacenter, it is critical that all TCP segments of the connections keep flowing over the same WAN link in both directions. This can be achieved by ensuring certain settings are applied (such as destination IP based persistency and the RNAT switch).

(b) For connections initiated from a branch office or a mobile user, the link load balancing decision must be made prior to the connection being actually established. This can be done by leveraging the DNS-based selection of NetScaler's Global Server Load Balancing capability (although we're not load balancing data centers in this example). Furthermore, once a selection is made by GSLB, the return packets must not be link load balanced, but must stick to the path selected in the GSLB step.

Sounds complicated? It's not too bad and to make it easier for you, you can read all about it in the Consulting Solutions design considerations article published here.

Dan Feller on my team contributed at least two posts on the topic of virtualizing XenApp servers on XenServer. Dan makes some excellent points and gives you plenty of business reasons why XA on XS is a good idea.

I am not going to re-iterate Dan's points here, but rather focus on another burning question in this context: How much of a scalability overhead can I really expect with my specific application? The typical consulting answer would be "it depends" and "we'll have to do a scalability / performance assessment to determine the specifics and best practices". So, we have done just that and used two popular enterprise class Applications: Siebel 8.0 and PeopleSoft 9.0. The Solution Center is one of the teams under the umbrella of Worldwide Consulting Solutions (Dan Feller's Integrated Solutions team is another) and focuses on these types of projects, which often involve third party applications and/or hardware platforms from our technology partners.
Recently, we looked at running the front-end of Oracle's PeopleSoft and Siebel applications on XenApp (both 32-bit and 64-bit platforms) and focused on comparing the user densities we could achieve on "bare metal" servers compared to running them on XenServer.
The results are published in two separate whitepapers (PeopleSoft, Siebel), which describe the test bed, test methodology, detailed results and interpretation. As Dan stated in his May 15th posting, the virtualization overhead can be as low as 6% for XenApp virtualization on XenServer, and our tests confirm this number. Of course, the numbers vary between the applications and platforms, and we describe all the details in the whitepapers.
Generally speaking, kernel memory limitations constitute the first bottleneck on 32-bit platforms, and our tests verified that behavior. Even with the popular /PAE switch, the kernel memory limitation remains at 2 GB. Therefore, you can expect a higher user density per physical server if you're running multiple 32-bit XenApp servers on a XenServer. You'd have to be cautious not to consume too many CPU cycles, which often become the next bottleneck once memory is no longer a major concern. Prices of multi-core, multi socket servers with plenty of RAM have come down significantly, so chances are that your latest servers have plenty of resources to run reliably in that configuration at a reasonable price:

According to this 1988 article, prices of 1 MB memory chips were as high as $60 (or $105 in today's money), while you can buy a barebones server with 64 GB of RAM for roughly $5,000 today. While I am on the topic of computer nostalgia: a 150 MB hard drive set you back over $8k in today's dollars way back when... 1988 was also the year Dan Feller was looking forward to seeing his favorite TV show getting its own slot in the line up and he is still enjoying it to this day, as you can see from the quotes in his postings on this site. But I am digressing...

The Solution Center also conducted detailed validation tests with Oracle to obtain validation status for running virtual images of the Web-, Application-, and Database servers of Siebel 8.0 , PeopleSoft 9.0, and Oracle E-Business Suite 12 on XenServer 4.1, so you can now be confident that the entire environment can be successfully virtualized on XenServer, allowing you to take advantage of XenMotion in case of hardware failure and other benefits.