Is virtual machine slower than the underlying physical machine?

This question is quite general, but most specifically I'm interested in knowing if virtual machine running Ubuntu Enterprise Cloud will be any slower than the same physical machine without any virtualization. How much (1%, 5%, 10%)?

Did anyone measure performance difference of web server or db server (virtual VS physical)?

If it depends on configuration, let's imagine two quad core processors, 12 GB of memory and a bunch of SSD disks, running 64-bit ubuntu enterprise server. On top of that, just 1 virtual machine allowed to use all resources available.


Solution 1:

The typical experience for a general purpose server workload on a bare metal\Type 1 Hypervisor is around 1-5% of CPU overhead and 5-10% Memory overhead, with some additional overhead that varies depending on overall IO load. That is pretty much consistent in my experience for modern Guest OS's running under VMware ESX\ESXi, Microsoft Hyper-V and Xen where the underlying hardware has been appropriately designed. For 64 bit Server operating systems running on hardware that supports the most current cpu hardware virtualization extensions I would expect all Type 1 hypervisors to be heading for that 1% overhead number. KVM's maturity isn't quite up to Xen (or VMware) at this point but I see no reason to think that it would be noticeably worse than them for the example you describe.

For specific use cases though the overall\aggregate "performance" of a virtual environment can exceed bare metal \ discrete servers. Here's an example of a discussion on how a VMware Clustered implentation can be faster\better\cheaper than a bare metal Oracle RAC. VMware's memory management techniques (especially transparent page sharing) can eliminate the memory overhead almost entirely if you have enough VM's that are similar enough. The important thing in all these cases is that the performance\efficiency benefits that virtualization can deliver will only be realised if you are consolidating multiple VM's onto hosts, your example (1 VM on the host) will always be slower than bare metal to some degree.

While this is all useful the real issues in terms of Server virtualization tend to be centered around management, high availability techniques and scalability. A 2-5% CPU performance margin is not as important as being able to scale efficiently to 20, 40 or however many VM's you need on each host. You can deal with the performance hit by selecting a slightly faster CPU as your baseline, or by adding more nodes in your clusters but if the host can't scale out the number of VM's it can run, or the environment is hard to manage or unreliable then its worthless from a server virtualization perspective.

Solution 2:

"Performance" has many aspects. The n00bs measure the boot time of an OS, and say e.g. Windows 2012 is sooooooo great because it boots in 12 sec on real HD, maybe 1 sec on SSD.
But this sort of measure not very useful: performance is equal to OS boot time, but the OS boots once a month so optimizing that doesn't make much sense.

Because it's my daily business I might point out the 4 following parts which made up the "performance"

  1. CPU load
    This should be comparable, meaning a task taking 1000 ms on bare metal will execute in 1000 ms process time and probably 1050 ms of clock time in an idle VM environment on the same hardware (some details later). Google the MSDN for processtime and queryperformancecounter and yu can do a thing that can show how much the VM eats up yur CPU time.

  2. SQL performance
    SQL performance highly relies on IO to the datastore where the SQL data is stored. I've seen 300% difference between 1'st gen ISCSI which you may find on Buffalo home NAS, then ISCSI with DCE and a real old school FC environment, on all levels. The FC still wins nowadays, because the FC latency is the lowesst archievable which lead to a "copy" of the FC protocol for TCP/IP datacenter enhancements. Here IOps and latency is vital but also IO bandwidth from the server process to the media - depends if the app tends to No-SQL or to Datawarehousing or is in the middle of that like ERP sytems ... Sage KHK for small enterprises, SAP for the huge ones. Both have a CEO view on enterprise financial statistics and when the CEO hits the button he effectively grants vacations for some days when the IO subsystem of the database has weaknesses.

  3. Filesystem Access
    Some applications, like video streaming relies on a guaranteed minimum bandwidth, others rely on max IO throughput like just openeing large files in a hex editor, loading a video project into yur favorite movie making prog. Not a typical situation on a vm.... the IOps may also be important to developers. Developers often make use of VMs because developing environment s are very sensitive and so the temptation to do that in a VM is high. Compiling a large project often means reading tons of small files, do the compiler stuff and build an EXE and the accompaining components.

  4. Network latency to the client
    Here the usability of WYSIWIG progs like word 2010, Openoffice Writer, LaTEX, GSView and others highly rely on the speed - how fast a mouse action gets from the client to the server. Especially in CAD apps this is important.... but also not a LAN issue, it'S remote access over WAN where this is important.

But - and I speak from the perspective of years of consulting - there are users having the admin password (and they're often employees of a BIG company with a BIG budget and a BIG pocketbook) complaining this and that, but it must be clarified which performance compoent is important to them and which is important from the perspective of the application they use.
It's most likely not notepad, but a highly sophisticated application for engineering this and that, which was also very expenssive and should be moved on the VMware, HyperV or Xenapp and it doesn't perform as expected.

But they don't have in mind that it might run on 1.5 GHz Xeons on blades not made for pure CPU performance, they're built for an average, let's say "optimized for $ per CPU cycle" or "CPU cycles per Watt".

And when we talk about tradeoffs and economisations - that mostly leads to overcommitments. Overcommitments lead to lack of ressources where CPU can be handled pretty well, but lack of memory leads to paging, lack of IO in the core routers leads to increased answer times on everything , and transactional overload on any kind of storage might stop every useful app from responding too quickly. Here monitoring is required, but many software vendors are not able to provide such informations....on the other hand a host with ressources of 3 physical servers can most likely handle 8 virtual machines of the same layout like the physical ones...

The CPU tradeoffs on idle systems often leads to systems performing 50% slower than physical systems, on the other hand nobody is able to install the "real world" os and the "real world" app the customer's IT guys want to move into the VM box. And it takes days (maybe weeks but for sure 42 meetings) to make clear that VM technology can offer flexibility by trading pure CPU speed. This is just built into the CPUs on these blade systems hosting nowadays larger VM environments. Also the memory won't be comparable, also some tradeoffs apply. DDR3 1600 CL10 will have higher memory bandwidth than DDR2 800 ECC LLR - and everyone knows that Intel CPUs profit from this in a different way than AMD cpus. But they're rarely used on productive environments, more in whiteboxes or in datacaenters hosted in 3rd world countries who offer datacenter service for 10% of the price a datacenter in your own homeland may bill yu. Thanks to Citrx a datacenter can be everywhere if it's less than 150 ms of latency between the end user and the datacenter.

And the home users perspective....

Last but not least some people wanna throw away Win7 or XP and trade it for a Linux, and then the gaming question comes up because actually only few games are available for Linux and Windows. Gaming relies higly on 3D acceleration. VMWare 6.5 Workstation and the connected free player can handle DirectX 9, meaning a Doom3 in a VM can run on the host graphic card in full screen. Games are mostly 32 bit apps, so they won't eat up more than 3 GB and mostly not more than 3 CPUs (seen on Crysis). Newer VM players and WS can handle higher DirectX versions and probably OpenGL as well... I gamed UT and UT2004 on VMware 6.5, the host had a ATI Radeon 2600 mobile and a T5440 CPU. It was stable at 1280x800 and playable even on network games....

Solution 3:

I would point out that virtualisation can exceed physical performance in certain situations. Since the network layer is not limited to gigabit speed (even though the hardware emulation is of a specific lan card), VM's on the same server can communicate between each other at speeds beyond that of multiple phyiscal servers with average network equipment.