Infos: Admin Guide

see attach!

if the info is helpful, please do not forget to provide points

regards

Jose

Thank you for the response. 1000 is clearly the correct answer. I don't know how many times I overlooked the answser in the admin guide.

Additional to the info above you should also consider building your Connection Brokers (View Manager Server) on 64-Bit and ensure you have 3GB+ memory to handle the higher numbers. The actual numbers tested were 1,500 direct connections. You'll lose about 30% if you use tunnel connections (so closer to 1,000-1,250). This is for each connection broker and/or security server associated to a connection broker.

Want make a difference in the future of VMware Products? Feature request your ideas ( )!

...and to add a little bit to what everyone has said. If you go over the 1000 mark, I would consider adding another vCenter instance.

We have 2800 vPC's with 4 brokers and 3 vCenter instances.

also, don't forget to award points by marking answers as "correct" or "helpful". It's another way of saying Thank you!

For View 3.0 and 3.1, we're recommending the following sizing guidelines:

• Tunneled connections, standalone single broker: 700 concurrent connections

• Tunneled connections, single broker with separate security server: 700 concurrent connections

• Tunneled connections, three-broker cluster: 2000 concurrent connections

• Direct connections, single broker: 2000 concurrent connections

• Direct connections, three-broker cluster: 5000 concurrent connections

• Pool size, View Composer: 500 VMs

Ok I know what the admin guide says, but what is the max # of users in practice? Are you all running your Connection Server in a VM? How much ram is allotted for the VM and how much for the physical server? Thanks.

The above sizing guidelines are the recommended number of users in practice.

The Connection Server can be run on a physical PC or inside a VM. Dual CPUs and 3 to 4 GB of memory are recommended as you scale to higher numbers.

For more information, see page 15 of the View 3.1 Administration guide.

Geoff,

I read pg 15 in the Admin manual but there seems to be a contradiction in the OS that can be used for the View Connection server. It states that "View Connection Server runs on a 32‐bit or 64‐bit dedicated physical or virtual server with the following specifications..." However, the next couple of paragraphs down it is stated that "The View Connection Server can be installed on the following 32‐bit operating systems..." It does not document any 64-bit OS's that can the Connection server can be installed on. Do you know where it is documented that the connection server can be run on a 64-bit system, and in application what 64-bit OS's have been recommended to work without issues? Thanks.

The View Connection Server can run on both 32-bit and 64-bit hardware, however only 32-bit operating systems are supported.

Geoff,

Sorry to trouble you again, but I think I need a bit of understanding. There are 2 main components involved: Connection Server and the ESX server that contains the VMs. Is it the "Connection Server" that can handle the 1000 connections? Also, how many VMs can the ESX server contain? Thanks.

Yes, thats right. The View Manager can handle about 1000 connections.

How many VM:s a single host can facilitate is depending on the VM:s and the host.

A rough number is 6-8 desktops per core, you may get less or more.

A cluster can consist of max 8 hosts (using linked clones) and a vCenter can handle 2000 VM:s.

I would recommend to have a look at our reference architechture:

http://www.vmware.com/resources/techresources/1084

Best regards,

Linjo

If you find this information useful, please award points for "correct" or "helpful".

Hi Imemo,

My August 25th post references the number of concurrent users that can get a virtual desktop. The number of VMs on an ESX server is dependent on your physical hardware. A good rule of thumb is 8 VMs/core.

Hope this helps.

Geoff

Linjo,

View Manager can handle more than 1000 concurrent connections, see my August 25th post for more details.

Geoff