I would not think that a bunch of developers would need to have much access to VC. 

VC is not a replacement for things like Terminal Services.

Developers should only have access via terminal sessions and\or remote desktops. 

We have a large amount of developers and NONE of them have console access.  It would be like having all of your developers working the your data centre all at once, impractical and unreasonable.

Aim to remove as much VMware Console access as you can.  I believe that there is also an overhead associated with console access also, cant seem to find the reference at the moment.

I run VC from home via VPN using 256k ADSL.

no real issues... just slow.

It'd probably make more sense to keep your VC server with the ESX servers.  The fun your going to have dealing with bandwidth will be in your remote console sessions.  It doesnt matter wether your VC server is with the ESX server or Developers, your remote console session still hits the console OS's interface on the ESX server and thats where your WAN will see restriction. 

Whats your WAN speed?  If your going to have multiple people running multiple remote console sessions..  your not going to have much fun over anything less than a 10MB connection.

Yes we did,

This document might be interesting :

http://www.vmware.com/pdf/vc_technical.pdf

We have chosen the VC to be on a separate server including a MS-SQL database (residing on this same server). We have done this for DR purposes. If we would have installed VC on a ESX server, and this box should fail, we also would loose all our VC provided management tools.

An other thing to consider is the use of VMotion and the placement of template files.

Without VMotion or templates, Network usage is low. Especially when you supply your developers with VC-client. VC-client will use the VC-server to find VM’s. Remote control traffic is VC-client -> VM based (not VC-client -> VC-server -> VM)

The developers are allowed to view, use or administer VMs, depending on user rights (a big plus for VC)

When you want to use templates, you might run into trouble. You can choose (per VC-server) between VMFS based or VC-server based storage to store your templates. If you would choose the VC-server based storage method and place this server in site2, every deploy operation will be done over your wan.

Since all you ESX server are located on site1 and your developers located on site2 your best option would be to configure a VC server on site1 and give you developers VC-clients for remote KVM and server control. Placing VC server on site2 would only use more bandwidth (monitoring etc).

If  VC client are still using to much bandwidth you might want to consider using a terminal server on site1 with VC-client installed on it. This would use the least bandwidth and isolate all VMware Infrastructure communication to site1

Cheers

Bart

Just on bandwidth on VC over a 56k dial.. via VPN. 

This works and it bareable.  Remote console is fine.

Generally I am happt for one off type use.