>It sounds like the SQL server is remaining the same, so you don't have to worry about its raw performance - just potentially more overhead in accessing it (?)
>
>I suggest doing some monitoring of your existing IIS server and environment, before it is switched to virtual e.g.
>
>- average RAM and CPU utilization
>- average network bandwidth utilization
>- disk subsystem performance e.g. average disk queue length
>
>Then, you will have some solid figures and will be able to tell the client that to achieve X hits/sec with Y milliseconds response, I need Z CPU/RAM/disk/network
>
>The obvious dangers with virtualizing are not provisioning enough CPU and RAM. The results of your monitoring, and knowing the relative performance of current vs. new CPUs/cores can let you provision appropriately.
>
>Less obvious are potential bottlenecks with network and disk. A single gigabit link can be plenty for a single server but if several virtual servers are sharing it, that may not be enough. Also, the disk subsystem can get hammered if too many VMs are running on it.
>
>Slowdown in accessing the SQL server depends on how you're going to do it. Assuming everything is still local ( LAN, not WAN ), if they open a firewall port for you it might slow you down by only a few milliseconds. If you go in through something like a VPN it might be a little slower, and it could take some extra CPU at your end to support the VPN.
>
>Every environment is different - so monitor & test first.

Thanks for this very detailed message.