Virtual servers take advantage of the fact that most servers do not run at capacity for any length of time, and cpu cycles / memory can be shared. Therefore, it REALLY depends on how busy your virtual machines are.
It also depends on which virtual environment you are using, as to how well it can share memory. (I seem to recall that when I experimented with XEN there was no memory sharing at all - but I think that has now changed).
A development environment is a perfect place to get your feet wet with a virtual environment, and it's real handy to be able to "create a new server" in about 5 minutes if it is needed (even allowing you to over-allocate your resources temporarily in a pinch).
By way of example, we can host approximately 100 virtual machines using VMWare Infrastructure on 5 physical servers. Each of these physical machines has 4 dual core Xeon 2.6Ghz CPUs, 16Gb Ram, and 8 - Gigabit nics. (so an average of 20 VMs on each of these). We find our biggest limitation to be the amount of available memory.
I can say that having worked in a virtual environment for several years now, I wouldn't want to go back.
Hope this helps.
In addition to the info on Why do people tell me not to use VLANs for security? here are some more specific & general bits to consider:
General Thoughts on Security
The most secure system is one where each subnet's hosts are connected to a switch having exactly the number of ports that will be used by connected devices. In such a configuration you can't plug random machines into your secure networks, since doing so would require unplugging something (and theoretically your monitoring system would notice that).
VLANs give you something similar in terms of security, breaking your switch up into smaller virtual switches (virtual LANs: VLANs) that are isolated from each other logically, and with proper configuration can appear to all the systems connected to them as if they were physically isolated.
General Thoughts on relatively-secure VLAN Setups
My practice for VLAN-capable switches is that all traffic must be assigned to a VLAN, with the following basic configuration:
Assign all unused ports to an "unused" VLAN.
All ports connecting to a specific computer should be assigned natively to the VLAN that computer should be in. These ports should be in one and only one VLAN (barring certain exceptions that we'll ignore for now).
On these ports all incoming packets (to the switch) are tagged with the native VLAN, and outgoing packets (from the switch) will (a) only originate from the assigned vlan, and (b) be untagged and appear just like any regular ethernet packet.
The only ports that should be "VLAN trunks" (ports in more than one VLAN) are trunk ports -- those carrying traffic between switches, or connecting to a firewall that will split up the VLAN traffic on its own.
On the trunk ports the vlan tags coming in to the switch will be respected, and vlan tags will not be stripped from packets leaving the switch.
The configuration described above means that the only place you can easily inject "VLAN hopping" traffic is on a trunk port (barring a software problem in your switches' VLAN implementation), and much like in the "most secure" scenario this means unplugging something important and causing a monitoring alarm. Similarly if you unplug a host to connect to the VLAN it lives in your monitoring system should notice that host's mysterious disappearance and alert you.
In both of these cases we're talking about an attack involving physical access to the servers -- While it may not be completely impossible to break VLAN isolation it is at a minimum very difficult in an environment set up as described above.
Specific Thoughts on VMWare and VLAN Security
VMWare Virtual Switches can be assigned to a VLAN -- When these virtual switches are connected to a physical interface on the VMWare host any traffic emitted will have the appropriate VLAN Tag.
Your VMWare machine's physical interface would need to be connected to a VLAN trunk port (carrying the VLANs that it will need access to).
In cases like this it is doubly important to pay attention to VMWare Best Practices for separating the Management NIC from the Virtual Machine NIC: Your Management NIC should be connected to a native port in an appropriate VLAN, and your Virtual Machine NIC should connect to a trunk that has the VLANs the virtual machines need (which ideally shouldn't carry the VMWare Management VLAN).
In practice enforcing that separation, in concert with the items I mentioned and what I'm sure others will come up with, will yield a reasonably secure environment.
Best Answer
I can't find reference to any hypervisor which implements IPMI, but there is some talk about implementing this in libvirt and qemu.