I/O and VMs
From the article: "More critically, shoehorning an I/O-intensive job such as a big database application into a VM can lead to problems if you haven’t done the sums first and made sure that the host’s I/O capabilities, along with all the downstream technologies, are up to the task."
I'd go as far as saying that shoehorning ANY I/O intensive job into a full VM (as opposed to a chroot type VM) is a recipe for disaster. Typical performance degradation on disk I/O intensive tasks ranges from 40% for something relatively CPU bound (e.g. Linux kernel compile) to an eyewatering 2,000% (yes, that's 20x) on something heavily disk bound (e.g. SQL databases). Anybody telling you otherwise is probably a virtualization salesperson.
Chroot type VMs, OTOH, come with overheads that amount to rounding errors of a percentage point. Examples of such are:
Linux: VServer, OpenVZ, LXC
Linux VServer even comes with a unique feature to dedupe files into copy-on-write hard-links across guests, which not only reduces disk usage but also memory usage by unifying the memory used by the merged shared libraries. Inodes for the same DLL in all the guests end up being the same, so they get mmap()-ed into the same block of memory. It's a bit like memory-deduping, only more efficient and more natural. By leveraging this you can achieve some truly insane resource overbooking ratios (hundreds:1 has been achieved) with negligible loss of performance.