1. There are two ways to segregate databases from one set of DBAs or another. #1 Setup separate servers or instances and not give those DBAs rights to the server or instance. #2 Don’t give the DBAs sysadmin rights to the database. #2 is basically useless as the DBAs can’t do their job without sysadmin rights to the SQL Server. #1 is the method pretty much everyone uses.
2. Virtualizing SQL Servers is just fine, so long as the SQL Server’s can function with the resources they are given. If you hardware is a Quad Core, Quad Chip server with 64 Gigs of RAM, and your SQL Servers only need 2 CPUs and 2 Gigs of RAM, then virtualizing them will be just fine. If your SQL Servers need massive amounts of CPU power and RAM, then virtualizing them won’t work so well. This post may help.
3. Each virtual machine needs to be licenses just like it’s a physical machine. If you are using the CAL licensing method then each guest OS which has SQL Server installed needs to have a Server license. If you are using the CPU licensing then how ever many CPUs the guest OS has will each need a CPU license.
Do keep in mind that DBAs do need access to the OS. Unless of course the SAs want to be responsible for installing SQL hot fixes and service packs, keeping an eye on free space for the database server, handling DTC issues that come up (if you are using DTC), possibly debugging SSIS packages which work from the Developers desktop but not when scheduled on the SQL Server. Not to mention the installation of SQL Server. Odds are the sysadmin doesn’t know how the DBAs want everything laid out on the system (binary files, system databases, data files, log files, tempdb files, etc)
As a DBA is an SA told me that I wasn’t going to have access to the server (not physical access, but access via RDP) there would be a battle to say the least.