Think you can say that now. Just drop the VM part 
.
1 Like
@ricklinux I know what you mean. With or without spice-vdagetn QEMU does have an issue when it comes to input in any windowed mode. I really was unable to figure out why. I think it might have issues locking the mouse according to the host’s resolution.
But I use my VM’s in full-screen VB or Virt they work much better that way. I think virt targeted more toward running without a UI like a type 1 hypervisor so that might be the case it’s having this issue.
But I digress I’m willing to put up with the non window issue due to the better performance I get from QEMU/virt. Because I do run windows VM’s, VB and VMware performance is 
when it comes to what virt can provide.
I just want to throw in my 2 cents regarding performance of vmware and virtualbox. I am using virtualbox since many years. This thread here triggered me to try vmware workstation pro. I was mainly interested to see if the vmware guest performance is really that much better than virtualbox as some of the posts here suggest.
So I did my darktable benchmark on an EndeavourOS guest in vmware and in Virtualbox and compared it with the results I receive from the host.
I did 30 runs each. This is pure CPU performance because opencl is not available in either virtual environment. The results are:
average values from 30 runs:
----------------------------
vmware: 4.91 s = 110 %
virtualbox: 5.07 s = 113 %
native on host: 4.47 s = 100 %
The 3 % points difference between vmware and virtualbx are neglectable. Even the 13 % difference between virtualbox and the native host is hardly noticeable in real life. I did not check KVM/QEMU. The very good virtualbox performnce makes me believe that KVM/QEMU will not bring a significant performance advantage.
Other than that I found that vmware uses more memory than virtualbox. When I run more than one vm it also complains that my swap is below recommended values (it is 12 GB swap for 64 GB RAM and vmware recommends 16 GB swap).
I also notice that I can easily run several virtualboxes in parallel (incl. Windows 11, debian, Mint, etc.) while vmware seems to struggle with that. I experienced some stutering when moving windows in 3 vms (debian, mx-linux and EndeavourOS).This does not happen with virtualbox.
I also find that virtualbox is easier to handle. E.g. 3D acceleration. In vmware it was not sufficient to select “Accelerated 3D graphics” in the DISPLAY section of the vm. I had to add mks.gl.allowUnsupportedDrivers="TRUE" in the config file resp. the *.vmx file to get it working. In virtualbox the GUI setting is sufficient.
My conclusion:
virtualbox is still the best possible vritualization solution for me. It is very easy to setup and the resource consumption is less than with vmware. The vmware performace advantage of 3 % points is not worth it for me.
3 Likes
Is it true that a virtual machine simulates the hardware of a host machine and so you can test how a particular operating system would run on that physical machine?
No. the virtual machines gives access to the CPU and eventually the GPU if that is configured (GPU passthrough). But other than that the simulated hardware for USB, network, sound etc. is not your host hardware. E.g. in virtualbox you can select which network adapter or audio controller shall be emulated. It offers you 2 or three choices.
I messed it up a bit with the hardware simulation.
Nice testing!
Thanks for sharing the result!
I fail to see how that conclusion would follow logically.
However in practice it very well might be the case
The difference is harder to see in our normal usage. It comes to light when used at SME level or higher. It must be doing something right to earn the trust of a lot of industrial-level users.
I also setup a virt-manager to handly my low need for virtual machines and everything seems to work very well, so thanks for the quide.
One thing I noticed, and there was talk about this in the other thread somewhere, that virt-manager wouldn’t scale the virtual machine resolution to fill the whole windows (in windowed mode). I also had this problem but only when I tested Budgie. On my KDE (endeavourOS) virtual machine scaling works automatically.
So I guess there is some kind of bug in Budgie and it seems same kind of bug is affecting XFCE (as far as I understoon from some arcticles).
Install spice-vdagent on your guest os. and then got to View → Preferences and turn resize guest with the window on.
Ah, so at the end the suggestion of @lunainvictum to install spice-vdagent to get the guest window properly resized works.
Thanks for confirming!
yeah noticed that i need to install that splice to the guest. But still it doesn’t work with xfce/budgie for some reason
1 Like
The logic for my statement is simple.
*) KVM/QEMU can not be faster than the native host, it will certainly be slower by some percent points.
*) Let me guess that KVM/QEME is only 5 % slower than the native host, which would be an excellent result.
*) virtualbox is only 13 % slower than native host.
*) In that case KVM/QEMU is 8 % points faster than virtualbox. This is not a “significant performance advantage” from my point of view.
2 Likes
Yep, it’s kind of similar to gust additions from VB. I forgot to add this as a step in my tutorial which I’ve corrected now.
1 Like
I understand all that.
However based on
and
still “logically” it doesn’t follow from the good performance of virtualbox that Qemu/KVM will not perform better. If it’s better performance is not significant to your use case, that’s incumbent to only you to subjectively decide.
What I suggest is to just use whatever hypervisor solution that works for you and for what you use it for. If VB works for you use that, if QEMU is your daily cup of tea or coffee then use that. Or if it’s VMWare that wet’s your beak then it’s your champ. No need to go into this is better than that it’s all in perspective like beauty. Just stick to what you like.
2 Likes
Sure.
QEMU has certainly a better performance than virtualbox. I have no doubt. But anything below 10 % performance difference is not significant for me. If you increase the CPU/Memory clock speed by 10 % your users will hardly notice any difference.
Many years ago I have read an article about GUI programming where they even said that you need a 20+ % performance increase before the users start saying “yes, that feels faster”. Anything below 20 % in that study was hardly noticed. But that is off topic.
3 Likes
Thanks for taking your time to clarify!
And also for having tested and shared your findings with the forum.
I know it is to much to ask but for the sake of thoroughness/completeness it would have been nice to have had some test results for Qemu/KVM as well.
The thing about this is that it is a single test. It might not be representative of all performance scenarios.
This is a fairly meaningless notification that you can disable.
This is not my experience. It isn’t uncommon for me to have 8-12 VMs open in vmware.
You don’t need to do that in each VM. You can just add mks.gl.allowBlacklistedDrivers = "TRUE" to your preferences.
In general, you have experience on how to use virtualbox but don’t have the same experience with vmware so you might not be seeing optimal performance from vmware.
That being said, I do agree that the learning curve with virtualbox is less than with vmware.
Nothing wrong with that conclusion. It is all about use case. What is good for one person’s needs might not be good for another.
I can only say that for my needs, moving from virtualbox to vmware was like a revelation. It is night and day better.
That being said, vmware isn’t a panacea. There are certainly challenges with vmware too. In my opinion, none of the virtualization solutions are perfect.
Yes, this is true. That’s why I started this thread to learn about the community’s experiences and then decide for myself. I also wanted to start a discussion and I’m happy learn that a few of you like @pebcak tried out VMs because of this thread.
That’s what I love about this community, people like to share, teach and are willing to learn about new things.
2 Likes