As the article alluded to, the trick to good worst-case performance with a virtual server is the same as the trick to good performance with a physical server: Share as little as possible.

Note that the average VM consultant often looks at the average case; this is identical to a pooled SAN consultant looking at the average case. This doesn't account for the best case... and, important to many but not all SQL Server installs, doesn't account for the worst case.

With VMs, SANs, NASs, and shared storage of all stripes, if you want to be able to quantify and control worst case performance, you need to control your spindles - dedicated spindles are a critical element in having predictable performance. If you share your spindles with another five apps (or VM's), and those five apps have a peak workload at the same time (perhaps during the end of year financial/auditing activity), your app is going to experience decreased performance in using those spindles.

The basic performance of the hardware doesn't change for VM's; heads can only move so fast, there's only so much bandwidth from spindle to controller, only so much from controller to storage network, only so much from, your latency is so high, etc. If you suddenly move from 88 dedicated, modern, 15k RPM spindles to 20 shared, modern, 15k RPM spindles, you're going to experience a reduction in peak performance. You're likely to experience a reduction in average performance (which may or may not matter to your app), and you'll likely experience a dramatic reduction in worst case performance (which more likely than not will matter to your app when it happens).

Beware "it's unlikely to happen" statements based on a normal distribution; end of the quarter/year reporting periods do not actually happen on an random independent trial basis from one app to the next.

With VM's, you not only have to control the spindles and other storage hierarchy, but also CPU, memory, memory ballooning, potential shared network ports, and so on. All VM's I'm aware of make controlling storage very easy. VMWare, at least, can set _minimums_ for CPU and RAM as well as shared amounts (and maximums, for that matter), so the VM administrators can prevent your SQL Server instance from being starved out by other apps.

In fact, you can achieve some cost and maintenance benefits of VMs and still give each SQL Server guest VM on a given host essentially dedicated CPU amounts, spindles, and RAM amounts; if the maximums for each add up to less than what the physical host actually has, there should be minimal contention (barring issues which what RAM belongs to what socket, which caches are shared with which cores, etc. etc.).

Essentially: Don't go from 50 cores, 300 spindles, and 512GB of RAM for 3 apps to 25 cores, 75 spindles, and 256GB of RAM for 8 apps and expect performance to remain identical all the time unless the peak workload before was less than the new environment's physical capabilities in the configuration it's in.