The technical limitation with running VMware inside VMware is that VMware, Virtual PC, etc takes advantage of the Virtualization features present in modern CPUs. The hosted option seems attractive if it will work though since it's less machine maintenance for me to deal with. My guess is that a local desktop machine running VMware Workstation might just be the way to go. Does anyone have any experience with this?Įdit: I know this nesting certainly isn't the preferred option, but (1) we want the flexibility of being able to use VMware snapshots at will and (2) the network folks will not allow us to arbitrarily roll back to a previous point in time because of the potential for removing mandated security updates. My guess is that we can't just use the primary hosted VM for our testing because we'll want to roll back occasionally and otherwise have more control over it, and getting buy-in for that from the network folks is unlikely. We don't require extreme performance from this setup, since it's just used for SharePoint testing and the associated SQL Server is on a different box. I was curious about whether it's possible to run VMware inside VMware, and if so, whether there are severe performance implications. That machine is old and dying, and my employer's network czars are heavily pushing hosted VMs as a replacement for outdated physical servers.
#Vmware vs virtualbox performance 2015 full
Whichever is the cause, KVM is simply a full light-year behind in the cached tests.We have a physical machine that runs VMware and hosts a VM we use for SharePoint deployment testing. It can be the slow block subsystem? Yes, it can be, but the 1024 KB seems to suggest a slow host-to-guest memory copy performance also. What can be the culprit here? The cache was disabled? I think no, because the results are better than the non-cached version – they are only too little better. The most interesting thing however is the incredibly slow KVM shown: its results are only a little better that the non-cached version. VMware is the indisputable leader, with VirtualBox at the second place and Xen, greatly behind, at the third. In other words, these results really shown hypervisor's I/O overhead. Seriously speaking, these results are not really from the physical disk subsystems: they are a cache-to-cache copy or, if you prefer, a host-memory-to-guest-memory copy. Wow, if a real physical disk can really guarantee that sort of results, it should be a best buy ) This graph is yet another view of the same data: VirtualBox is the leader shortly followed by VMware, while KVM and especially Xen are significantly slower.ĭid you remember that I run that test invalidating host-side cache each time? What can be the I/O results if we did not that action and, instead, we want to use the host-side cache? If you are curious, these graphs are for you. As you can see, VirtualBox satisfies the greater number of IOPS for the three low sized benchmark, while it is only slight behind the leader (VMware) on the 1024 KB sized test.Īt last, we want to see the disks total access time (seek time + read latency) This time, we are not measuring performances on KB/s, but on IOPS (I/O operations per second) terms. Another point of view for the same that is the following: However we can isolate the virtualizer speed, and we can see that Xen and KVM are considerably slower that Vmware, which in turn is slight slower that VirtualBox across the board. This is the main reason while flash-based SSD are so fast ) Let see the results (please keep in mind that the HDTune benchmarks are read only tests):Ĭan you ever see the 512 byte and 4 KB results? This graph is typical for a server equipped with mechanical disks: the lowest-sized benchmarks are dominated by seek time (which is a constant time, not related to chunk size). Generally, the low-sized fragment benchmarks are access-time bound, while the 1024 KB sized benchmark is peak bandwidth bound. The second test is HD Tune Benchmark Pro, which let us examine the bandwidth and access time of the primary disk reading 512 byte, 4 KB, 64 KB and 1024 KB sized chunks.