Whether or not you virtualize a given workload, you need to manage its resource usage. In the trivial case, you can see your CPU used up by some other program unless you provide your program a guarantee of enough CPU for the actual number of users who will be employing it.
Ditto memory, disk and networ I/O, bus bandwidth, etc, etc.
A more surprising case is putting two workloads together that formerly worked properly on an older, slower machine. If you increase the amount of a critical resource, both programs under load will start using more of every resource. For example, a batch job that got 30% more CPU increased the amount of disk I/O it did by several times. An interactive program on the same machine was rendered almost completely unusable because it couldn't do the I/O it needed. The customer in that case thought the vendor was lying about the speed of the machine, and demanded his old one back.
Linux is a hotbed of resource management experimentation, so you can statically size and configure a program (workload) to be able to withstand a given load. Commercial Unixes have good enough controls to do most common cases. I can't speak about Windows and BSD, as I've not researched them (yet). Mainframes, not surprisingly, have the best controls for what in their days were exceedingly precious resources.
If your OS doesn't have good resource controls, or if you don't know how to use them well, you'll end up splitting up the virtual machines onto a undesirably large number of physical machines, just in order to do the management the hard way.
The difficulty, by the way, varies as something like the square of the number of machines and the resources used, so virtualization and consolidation is easy for well-behaved, small and unimportant programs, and can be evil for anything that turns out to be big, resource-intensive or important. Think of that as a lemma used to derive Murphy's law (:-)).
--dave