I wasn't addressing the value of virtualisation in my post, but of the role of I/O bottlenecks. However, since you raise it, the point you makes about virtualisation disrupting I/O patterns applies equally to any form of multi-application access to shared storage unless you maintain a system of rigid segmentation (which is usually undesirable from a storage utilisation point of view). Indeed even multiple apps under the same OS exhibit this phenomenon of disrupted I/O patterns, and this has got worse as disks have increased in capacity and fewer spindles are available. However, none of this is incompatible with the observation that I/O bottlenecks are increasingly the limiting factor on modern applications - indeed it reinforces it.
I'm well aware that virtualisation saves system boxes, power, software licensing (under some circumstances) and so on (although savings ). Indeed I go back far enough to have worked on virtualised systems in the very early 1980s. Also, virtualisation does make some other demands on fast I/O. There is a phenemomenon called I/O elongation (or it was at the time) whereby I/O latency time had the appearance of being extended (as far as the guest OS was concerned) as the I/O terminated whilst the guest machine was not scheduled to run. This means that guest OSs on I/O bound apps in contended environments tend to perform notably worse than when run native. Improvements to VM software guest scheduling has helped this, but owing to the common x64 OSs not being written with virtualisation in mind, there are limits to how effective this can be.
Virtualisation is fine, but it should be remembered there is one resource that can't be virtualised, and that is time. Any time an OS has to deal with the real world, the timing issue raises its head. If the guest OS is unaware of running under a hyperviser then there are many complex issues which can lead to unhelpful behaviour on contested platforms.
Register
Not addressing virtualisation
@Ammaross Danan
I wasn't addressing the value of virtualisation in my post, but of the role of I/O bottlenecks. However, since you raise it, the point you makes about virtualisation disrupting I/O patterns applies equally to any form of multi-application access to shared storage unless you maintain a system of rigid segmentation (which is usually undesirable from a storage utilisation point of view). Indeed even multiple apps under the same OS exhibit this phenomenon of disrupted I/O patterns, and this has got worse as disks have increased in capacity and fewer spindles are available. However, none of this is incompatible with the observation that I/O bottlenecks are increasingly the limiting factor on modern applications - indeed it reinforces it.
I'm well aware that virtualisation saves system boxes, power, software licensing (under some circumstances) and so on (although savings ). Indeed I go back far enough to have worked on virtualised systems in the very early 1980s. Also, virtualisation does make some other demands on fast I/O. There is a phenemomenon called I/O elongation (or it was at the time) whereby I/O latency time had the appearance of being extended (as far as the guest OS was concerned) as the I/O terminated whilst the guest machine was not scheduled to run. This means that guest OSs on I/O bound apps in contended environments tend to perform notably worse than when run native. Improvements to VM software guest scheduling has helped this, but owing to the common x64 OSs not being written with virtualisation in mind, there are limits to how effective this can be.
Virtualisation is fine, but it should be remembered there is one resource that can't be virtualised, and that is time. Any time an OS has to deal with the real world, the timing issue raises its head. If the guest OS is unaware of running under a hyperviser then there are many complex issues which can lead to unhelpful behaviour on contested platforms.