[THIN] Re: VMware & CPS 4.5

  • From: "Jon Luchette" <jon.e.luchette@xxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Fri, 1 Feb 2008 12:16:01 -0500

Would you see equivalent results if you went from 8GB to 16GB in the same
environment?

On Fri, Feb 1, 2008 at 11:35 AM, Dobry, Wes <Wes.Dobry@xxxxxxxx> wrote:

>  We get about a 35% increase in users when tossing 8gb of RAM instead of
> 4gb in a CPS4.5 server using PAE.
>
>
>
> *-Wes Dobry *
>
> *(321) 843-5590*
>
>
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Jon Luchette
> *Sent:* Friday, February 01, 2008 11:28 AM
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: VMware & CPS 4.5
>
>
>
> In general I have seen that 4GB of RAM is the maximum amount of memory
> that Citrix boxes will efficiently use on a 32 bit Terminal Services Windows
> server operating system.  This has to do with the 2GB kernel memory
> limitation:
> http://www.brianmadden.com/content/article/The-4GB-Windows-Memory-Limit-What-does-it-really-mean
> -
>
>
>
> As a result, there are two options if you want to use more powerful boxes
> with much more RAM in a Citrix / TS environment, either run 64 bit windows
> terminal servers, or virtualize with ESX.  The customer did not have
> applications that would have taken advantage of a 64 bit architecture, so
> the only other option was to go with ESX and virtualize for them.
>
>
>
> They made the decision on their own to not look at VDI as an alternative
> solution...
>
> On Fri, Feb 1, 2008 at 10:00 AM, Malcolm Bruton <
> malcolm.bruton@xxxxxxxxxxxxxxxxxx> wrote:
>
> Jon
>
>
>
> Silly question but why would you just not run the apps natively on the box
> instead and isolate instead if you have app co-existence issues?  Seems like
> you could fit more users on again?
>
>
>
> We have taken the decision to use VMWare for small apps (where we can't
> isolate) of low user numbers but typically only dev as we don't believe it
> scales as well on VMware for heavily used prod servers.
>
>
>
> Malcolm
>
>
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Jon Luchette
> *Sent:* 01 February 2008 14:53
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: VMware & CPS 4.5
>
>
>
> I just set it up for a customer in a production environment:  2 HP DL380
> G5 boxes, with dual quad core CPU's and 16 GB RAM, backended with an HP EVA
> 4000 FC SAN.  We have 3 PS 4.5 virtual machines on each host getting 20
> users on each vm comfortably.  They have a pretty heavy application load too
> (Oracle, Lotus Notes, etc...)  and they are publishing full desktops to all
> users on WYSE SX10 thin clients.  We did bring DRS automation down to
> manual.  All in all, so far so good!
>
>
> HTH,
>
> -Jon
>
> On Fri, Feb 1, 2008 at 8:40 AM, Chris White <Chris.White@xxxxxxxxxxxxxx>
> wrote:
>
>
>
>
>
> Thanks for everyone's help/advice on this, most helpful.
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>  ------------------------------
>
> *From:* thin-bounce@xxxxxxxxxxxxx on behalf of TSguy92 Lan
> *Sent:* Thu 31/01/2008 18:34
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: VMware & CPS 4.5
>
> Our current production CTX environment = MPS 4.0, Win2k3 sp2 hosts on
> VMware ESX 3.5.
>
> Our standard VM build has 2 procs, 3gb ram and we average about 45+ user
> connections per host. Our environment is published app based, which lets us
> spread the load around a bit better, no full desktop. Physical boxes running
> VMware are HP blades, 16gb ram, 4 proc. Dependant on app load and usage, (we
> silo off the heavy use stuff) your mileage may vary.
>
> That link Greg sent has some good recommendations; from my own experience:
>
> - the vmware tools install by default adds a component into user profiles
> "hgfs.dat" which can be a pain to deal with. (greg's article covered
> this). Sort out how to handle this before allowing users to login.
> - Use manual DRS automation if you have a Citrix specific cluster setup in
> your ESX environment. Automated DRS vmotion during production hours with
> dozens of users connected can hang up a VM.
>
> We have virtual MPS 4.5 boxes in testing, but I can't say we've put any
> serious user load on them yet.
>
> HTH
>
> Lan
>
>  On Jan 31, 2008 7:07 AM, Kelsey, John <JCKelsey@xxxxxxxx> wrote:
>
> We tried it in an ESX 2.5 environment and the performace was horrible.
> Supposedly its been greatly improved in an ESX 3 environment but we haven't
> gotten back to try it yet.
>
>
>
>
>
> *******************************
> *John C. Kelsey
> *DuBois Regional Medical Center
> (:  814.375.3073
> *:   jckelsey@xxxxxxxx
> *******************************
>
> -----Original Message-----
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Chris White
> *Sent:* Thursday, January 31, 2008 08:58
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] VMware & CPS 4.5
>
>
>
>
>
> Hi,
>
>
>
> I've a customer who wants to run CPS 4.5 in a VMware ESX environment. This
> will be for production.
>
>
>
> Has anyone set this up in a live environment before? I've only ever set it
> up for a dev environment. Any tips or recommendations? Should I discourage
> them for doing this and use straight tin instead?
>
>
>
> Thanks for any help,
>
> Chris.
>
>
>
>
>
> *Basilica Computing Ltd *is registered in England, Registered Office
> Number 1, Avenue One, Letchworth Business Park, Letchworth Garden City,
> Hertfordshire, SG6 2HB, Company Number 2624451, VAT Number 245719348*
> Confidentiality:* This email, sent from Chris.White@xxxxxxxxxxxxxx to
> thin@xxxxxxxxxxxxx on Thu Jan 31 14:01:51 2008 , is confidential and may
> contain privileged or copyright information. You may not present this
> message to another party without consent from the sender. If you are not
> thin@xxxxxxxxxxxxx please notify Chris.White@xxxxxxxxxxxxxx and delete
> this email and you are notified that disclosing, copying, distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited. *2) Liability:* This email is not a binding agreement
> and does not conclude an agreement without the express confirmation by the
> sender's superior or a director of the Company. *3) Viruses: *The Company
> does not certify that this email is free of viruses or defects. *4)
> Requested:* The Company does not consent to its employees sending
> non-solicited emails which contravene the law. In the event that you feel
> this email is such, please notify the Company in order for the appropriate
> corrective action to be taken. *5) Advice: *Any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of the company. Any actions taken on the basis
> of this email are at the readers own risk. *6) Other: *The sender of this
> email is expressly required not make any defamatory statements. Any such
> communication is contrary to company policy and outside the scope of the
> employment of the individual concerned. The company will not accept any
> liability in respect of such communication, and the employee responsible
> will be personally liable for any damages or other liability arising.
>
>
>
>
>
> *Basilica Computing Ltd *is registered in England, Registered Office
> Number 1, Avenue One, Letchworth Business Park, Letchworth Garden City,
> Hertfordshire, SG6 2HB, Company Number 2624451, VAT Number 245719348
>
> * **
> Confidentiality:* This email, sent from Chris.White@xxxxxxxxxxxxxx to
> thin@xxxxxxxxxxxxx on Fri Feb 1 13:44:01 2008 , is confidential and may
> contain privileged or copyright information. You may not present this
> message to another party without consent from the sender. If you are not
> thin@xxxxxxxxxxxxx please notify Chris.White@xxxxxxxxxxxxxx and delete
> this email and you are notified that disclosing, copying, distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited. *2) Liability:* This email is not a binding agreement
> and does not conclude an agreement without the express confirmation by the
> sender's superior or a director of the Company. *3) Viruses: *The Company
> does not certify that this email is free of viruses or defects. *4)
> Requested:* The Company does not consent to its employees sending
> non-solicited emails which contravene the law. In the event that you feel
> this email is such, please notify the Company in order for the appropriate
> corrective action to be taken. *5) Advice: *Any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of the company. Any actions taken on the basis
> of this email are at the readers own risk. *6) Other: *The sender of this
> email is expressly required not make any defamatory statements. Any such
> communication is contrary to company policy and outside the scope of the
> employment of the individual concerned. The company will not accept any
> liability in respect of such communication, and the employee responsible
> will be personally liable for any damages or other liability arising.
>
>
>
>
>
> This e-mail message and any attached files are confidential and are
> intended solely for the use of the addressee(s) named above. If you are not
> the intended recipient, any review, use, or distribution of this e-mail
> message and any attached files is strictly prohibited.
>
> This communication may contain material protected by Federal privacy
> regulations, attorney-client work product, or other privileges. If you have
> received this confidential communication in error, please notify the sender
> immediately by reply e-mail message and permanently delete the original
> message. To reply to our email administrator directly, send an email to:
> postmaster@xxxxxxxxxxxxxxxxxxx .
>
> If this e-mail message concerns a contract matter, be advised that no
> employee or agent is authorized to conclude any binding agreement on behalf
> of Orlando Regional Healthcare by e-mail without express written
> confirmation by an officer of the corporation. Any views or opinions
> presented in this e-mail are solely those of the author and do not
> necessarily represent those of Orlando Regional Healthcare.
>

Other related posts: