View Composer or View Manager need most CPU and network?

[ikt]

Hi,

I plan to start experimenting with 6-8 View clients to get to know the vView concept...

I have installed View Manager at a VM: (x64) Win2008 svr connected to the same subnet as all the View thin clients are connected.  My VCenter Server where I installed View Composer runs at an old dedicated (physical) (x64) Win2008 svr connected to the View Manager / thinclient subnet via a 100Mbps firewall.

Would most of the View CPU and network traffic to the thin clients be from Composer or from Manager?  I just wonder if the 100Mbps 'bottleneck' and old Composer server hardware will be a problem.  Or doesn't it matter with such a low client count...?

Secondly the View Composer installer requested a database connection.  Would it be ok to use the same (SQL Express??) as the VCenter installer installed?  If yes, where can I find info on how to create a Composer database under SQL Express...?

Thanks for comments on these issues

best regards

Tor

[kgsivan]

Traffic should be from client to Broker/AgentVM only, and defenitely not to the composer.

Only Connection server and vCenter server has communication with View Composer, and used whenever there is a provisioning or maintenance activity on linked clones.

But 100mbps uplink to vCenter server is not advisible specially if the VMnetwork in ESX also has uplink to the same 100mbps network. Because from view client traffic goes to VirtualMachine hosted in ESX servers through these uplinks, and can make network overhead in large number of Desktops are launched

It is OK to use same SQL Express instance to create composer database, if it suffice to your deployment size. But need to create separate database for composer. Other thing to notice here is View Composer does not support Windows Integrated authentication so create a user in SQL. Create a DSN to the new database using the SQL username for installing view composer

[ikt]

Thanks a lot for your comments.

I have 6 gigabit interfaces on each host.  Subnet21 for the ESX management (is that what you call VMNetwork?) where my VCenter server (and View Composer) are connected, Subnet98 and Subnet99 for my dual controller iSCSI SAN and Subnet22 is a virtual machine available net, connected to the domain controllers, my View Connection Server and its thin clients.  The Connection Server IP (Subnet22) has access to the VCenter IP (Subnet21) through a firewall rule.  In this scenario I thought that all traffic to/from the thinclients would be at Subnet22...  But maybe I'm wrong...

As of the SQL Express stuff, do you think that it will be adequate up to a 40-50 View clients?

What is the default username / password of the SQL Express which is automatically installed by the VCenter Server installer...?

I have been reluctant to install the VCenter Server in a virtual machine, I thought it was best to have its services available even in the rare case that all our vmware virtual machine environment went down.  What is common practise of of the VCenter Server?  Physical or vritual..?

Thanks again for comments

best regards

Tor

[kgsivan · Accepted solution]

40-50 View clients could be possible in SQL express without much issues. Going through your reply it is clear that the subnet22 is the network which will have higest network utilization than others w.r.t View Desktops.(and your assumption is right).

The network configuration in the ESX for connecting VMs to the Subnet22 is what called VMNetwork

Default Username and passoword for the SQLExpress will be the account used to login and install vCenter server in windows machine (this is a windows authentication). You can connect to it as below.

• Download and install SQL Management Studio from microsoft website in the virtual center host os
• Open SQL studio, then click on connect , at the server name give 'localhost\SQLEXP_VIM' and select windows authentication
• This way you can manage the SQL express, and create new database.
• You can also refer to the DSN for vcenter server which created automatically during installation

Most of the VirtualCener servers are VMs I beleive, but as per my understanding both are popular.

Defenitly keeping vCenter in VM have lot of advantages and felxibilities.

Thanks

Siva

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful"