Don't mention "performance" in a conversation about virtualization. It is not trendy, it is archaic, it is part of the folkore. At least if you believe the gullible press and Analysts. Some of them seem to be all in a hurry to repeat the claims of the vendors.
We give you a small Anthology of  these "inspired" articles and discuss why they are naive.
HyperLove by ZDNet
 "We loved the near-native performance of Windows guests in Hyper-V", Jason Perlow ZDNet, Juli 1st 2008. Benchmark numbers to back this up? Not necessary.
Juicy detail: the same article claims:
"Back in February, we had a look at a late beta release, and we were quite impressed with the performance of the system".
Performance wise, Hyper-V was at that time pretty bad. When we tested back in April 2008 with RC-0, performance was in many cases not half of ESX 3.5 performance. But we could not publish this as this was RC-0 after all, and Microsoft admitted it had to improve this in the final version. Don't take our word for it, here is PCWorld:

"The most notable -- and the most significant -- change between the initial release candidate version (RC0) of Hyper-V and the RTM edition is better performance. Most of the performance work was done between RC0 and RC1, but not many people knew about it due to (a) not-so-wide a release and (b) a ban on performance testing by MS."
So although MS banned all performance testing on RC-0 and made large improvements on performance, some people still managed to be impressed by "the performance of Hyper-V" of a version older than RC-0?
Virtualization Tax myths and folklore
The Kusnetzky Group LLC feels that VMWare's benchmarking is a proof that hypervisor performance overhead is a myth: (July 22nd, 2008)
"Virtual machine overhead has been part of the folklore for quite some time. I’ve heard it described as the "virtualization tax” by those opposed to the use of this technology"
"In my view, successfully put it [Performance overhead] to bed".
The good old days that the press was supposed to make critical comments is over. You are either opposed to virtualization if you believe in virtualization overhead, or a folkloristic figure.
The Devil is in the details 
The performance figures of ESX 3.5 are without a doubt pretty impressive. We'll show you more in a few weeks. But simply assuming that (for example) "Applications having high I/O aren’t good virtualization candidates" is a performance myth because VMWare says so and shows performance numbers is just gullible.
The reality is that getting good performance out of of virtualized high I/O applications is possible, but it is pretty hard. If the "near native performance" claim was right and virtualization overhead was just a myth, why
  • Would AMD be touting their NPT/RVI technology? 
  • Would Intel be talking about a second generation of hardware accelerated virtualization (EPT in Nehalem)?
  • Would PCI SIG be hard at work at an I/O virtualization architecture?
Why do you think that we measured a performance increase ranging from 7 tot 30% with Nested Paging? The current virtualization solutions virtualize many applications with little performance overhead, but I/O intensive applications are still not among those.

Enter and exit VMM numbers (in ns) for the different Intel families.

Look at how much work Intel put into lowering in the hypervisor - Guest OS transitioning time with each CPU generation, and you'll understand that low virtualization performance overhead is only possible with the very latest CPUs. The moment your application needs large memory buffers which shrink and grow in time (like many big OLTP databases), does quite bit of network traffic or write a lot to your block devices, you will probably need an 
  • Intel Nehalem (not available yet) or AMD quadcore Opteron
  • Virtual I/O optimized NIC (such as Neterion's)
  • Other of the very latest hardware.
to get near native performance. And it doesn't end with having the latest hardware available. Is your database application 64 bit? Does the application and your OS support Async I/O? Is your database satisfied with 4 CPUs? Did you enable large pages? and so on. It is possible to get very good virtualization performance, but you problably sweat a bit and sometimes blood on it. That is the reason why many organisations are still keeping their OLTP databases on a native machine. It takes the right hardware, software and configuration combination to get the published VMWare numbers. And while in some cases very skilled people can make this happen, in a lot more cases you can not attain these ideal conditions.
The people at VMWare have the right to claim that I/O intensive applications can be virtualized at a relatively low performance cost (it is possible), but the task of analysts and press to find the snakes under the grass, and to talk about the "if"s and "but's". In my next post tomorrow I will show how some of the "near native performance" claims are simply very clever but completely useless and wrong in the real world. 
We love virtualization as it is lowering the cost of IT. But despite the fact that we are "not opposed to it", we'll do some independent testing before we believe VMWare, Xen and Microsoft. Part of the folklore here at Anandtech :-).
Comments Locked


View All Comments

  • Jeff7181 - Thursday, August 14, 2008 - link

    Seriously... do any vendors claim you should virtualize an I/O intensive database?

    Some things just should not be virtualized yet. A database server is one of them.
  • JohanAnandtech - Thursday, August 14, 2008 - link

    And now you are part of the folklore too. :-)

    Seriously, just google for "near native performance" and you'll find that Microsoft and Xen are making this claim often.

    VMWare latest ESX 3.5 can virtualize I/O intensive databases in the right circumstances with a relatively low performance impact, but markets it as if every database application is now easy to virtualize. Just click on the links I put in the blogpost above, and you'll see that indeed the vendors are claiming this.
  • abraxas1 - Thursday, August 14, 2008 - link

    I've been working in large VMware environments since the days of 1.5. There is a performance gap but it has been steadily shrinking with each release of ESX. One important thing that I've learned though is that the gap is very dependant on the knowledge and experience of the people deploying your ESX based infrastructure. The less experience your people have, the larger the gap will be. Most of my clients hire me to evaluate their existing infrastructure and advise them on the mistakes they made.

    I also have a rule of thumb to avoid I/O intensive apps when virtualizing an infrastructure. ESX shines when you get MANY servers on one piece of hardware. If you create a VM that requires max memory and cpu, then your density is going to drop significantly. With the latest bulid of ESX (3.5) my estimate for clients is 90% virtualization. That 10% that can't be virtualized are servers with funky hardware, unsupported OS, or massive I/O.
  • JohanAnandtech - Thursday, August 14, 2008 - link

    Good Feedback, clearly based on realworld experience. That is indeed the message that we should sent to those evaluating Virtualization.

    ESX 3.5 brought "near native performance for all workloads" a little closer, but we are still not there. I have seen companies move their SQL servers back to native as virtualization created too much overhead. I fully agree however that 90% of the workloads do well on ESX 3.5. I still have to investigate fileservers. Although they are low CPU usage, the intensive use of the filesystem could wreak havoc on a hypervisor. It does so on Xen and other opensource hypervisors, I yet have to try ESX.
  • SammyJr - Thursday, August 14, 2008 - link

    We have two file server VMs that are replicating with DFS Replication. Performance is great, serving about 800 users. We've have no complaints about speed and files open quickly.
    Many of our users work with large image files.

    We're on a tight budget so our VMWare storage is direct attached using Adaptec SAS cards and SATA drives. Our servers are white box dual Clovertown and dual Harpertowns.

    We've found that ESX is quite good at scheduling I/O.
  • ChrisG - Thursday, August 14, 2008 - link

    Thank you.

Log in

Don't have an account? Sign up now