Hi All, Im student and I have almost all my lectures in VMware workstation. As I'm using a MacBook pro with M1 chip I need to install the VMware Workstation in another VM which has Windows OS inside my mac. I really do not know the possibility of this and I would highly appreciate if anyone could assist me with this matter.
I bought workstation pro with the virtual printer feature listed and I was using it, and now they push 17.5 which has security fixes and a fix for the bridge networking among other things and they remove a feature they sold me as part of Workstation pro 17... That is not right, they can remove it in VMWare 18 which would be a different product, sold with a different feature set, but not in a dot release.
What is going on over there that an essential feature like the microphone cant be fix then with this latest update you disable a feature that allows you to print to the host device? I've been using vmware forever and its a great product but at a loss for the mic issue now this printer problem... pls add virtual printing back and also finally resolve this mic issue.
I noted in another thread 'VMware Workstation Pro 15.5.2 Freezes - Ubuntu 18.04 LTS Host and Any Guest OS' this has been happening for years, at least since 2019, and does not matter which distribution is being used, and still happens with current Workstation. From reading the bug reports on LKML/Red Hat bugzilla it appears Workstation is probably trying to allocate too large a memory block or something similar which causes the kcompactd kernel thread to stall using 100% cpu along with the vmware-vmx threads. It doesn't happen when not running Workstation, even with other VMs like VirtualBox.
The easiest way I have found to reproduce it consistently is to run 2-3 VMs along with disk i/o, that should trigger the problem pretty quickly even if you have plenty of free ram and extra cores. I have seen it happen with 20GB used ( /proc/meminfo MemTotal-MemAvailable) on a 64GB system, so it should have another 44GB available to use. My current system has a Ryzen 3900x (12/24) with only 4 threads configured total between VMs when it happens to me. Also when it happens vmware-vmx threads run at 100% and the kcompactd0 kernel thread is at 100%. The system becomes nearly completely unresponsive and you can't even type. Nothing else on the system is using noticeable amount of cpu. And once I manage to shutdown the VMs the system is fine.
After scraping through several other posts relating to the similar issues I am experience, I will keep this brief. I've implemented one of the solutions (powercfg /powerthrottling disable /path "C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe") which has fixed half of the issues such as booting/shutting down and application start up. However I still have 2 noteworthy issues: severe latency/input delay with using something basic as a terminal or typing this post and trying to drag & drop files from my host machine onto/into my VMs desktop and desktop directory with no results other than an odd "shadow" of the file that can be visually seen on the desktop GUI but not seen in the file directory or terminal (yet it can be dragged and dropped into any other directory I've tried so far and it is successful). Any information would be greatly appreciated.
Another option is "power on to firmware", try it, it goes to the BIOS. It's in the menu when right clicking a VM, or in the VM menu at the top. And in some versions of vmware workstation it's "power on to BIOS". In my version it's "power on to firmware" but it goes to the BIOS
I've got the same problem on a Fedora 34 system. All kernels starting with 5.12 show the problem, going back to 5.11.21-300 and the issue pretty much disappears. When this happens, kcompactd0 goes to 100% cpu use and the virtual is unresponsive (you can move the cursor but not get any other response). At the same time, the vmware process for the virtual goes to basicallly 100% * cpu cores (i.e. if you have 2 cpu cores in the virtual it will sit at 200% or so). When kcompactd0 goes back below 100%, which can sometime take minutes, the virtual comes back but it often happens again fairly quickly. Strangely, at times with the newer kernels you can run for quite a while without the issue.
Thanks, but I've tried it and it doesn't help with the latest kernels in Fedora 34 (I've tried it through all of them up to the current 5.15.4-101.fc34.x86_64). The 5.15.4-101.fc34.x86_64 is the last kernel vmware has worked reliably with on this system. I don't believe it is actual memory - the system has 6G of memory with 2G (and later 3G) allocated to the windows 10 virtual. I've also tried changing the vmware preference for reserved memory to 4096MB but that didn't help.
I'm going to try converting the virtual to a kvm virtual and see if it fixes it. This is an old system with a "Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz" CPU, which is currently one of the oldest supported by vmware. It is possible there is something with it that is causing the issue.
Jim
I have this problem too, and the problem seem to be hitting systems running Ubuntu as host somewhat reliably. I find it would be in the intrest of vmware to finda permanent solution with Ubuntu, alternative upstream with kernel developers. For every user that find the correct tweak there will be plenty that just give up.
I typed this into the run command and rebooted my laptop. i opened up the vmware.log again and it still says Monitor Mode: ULM.
Is the log file update every time VMWare is opened, because maybe I'm seeing the previous log before I did the bcdedit.
I updated yesterday and since the update I've been experiencing many issues with connections to remote VMs. The windows are getting cut off and the transition between them is slow. My vmware version is 17.5.1-1, kernel 6.8.4.arch1-1 and video card nvidia. Does anyone have the same issue?
However, it is asked to install debugedit because vmware-workstation is built with the option debug, which is irrelevant for packages that don't compile anything. So, I have updated the PKGBUILD to remove the debug option.
Hi, I recently adopted vmware-host-modules-dkms-git package and upgraded it to build the latest 17.5.0 branch commit on -host-modules. Right now it conflicts with vmware-workstation, both providing dkms host modules. I suggest removing dkms from this package and adding a dependency on vmware-host-modules-dkms-git (and I will remove conflict with vmware-workstation from vmware-host-modules-dkms-git). This way we can follow -host-modules newer kernel fixes more closely, without needing to rebuild this rather big package. I tested it locally, it works fine for me, this is my local patch:
When running firefox and vmware together, it sometimes get frozen, and it happens usually when I copy something and swith to the vmware it stuck, but clicks on the frozen screen still make sense. My vmware version is 17.5.0-2, archlinux with kernel 6.6.9-arch1-1, and wm is hyprland with nvidia video card, I am not sure if the N card is the culprit:(
So I am trying to setup Lubuntu on my vmware workstation 15 using an iso boot image using the 22.04.3 LTS download from the virtual machine works fine and I get to boot it from the iso file. The only problem is that I encounter this error when I try to run the dekstop Lubuntu installer in the virtual machine:
Installed R80.10 management only running on VM workstation, 6GIG (8GIG suggested), 4 Core, using RHEL 5 - 64bit, 60GIG HDD (100GIG suggested). Once you get the "LOGIN" prompt, another 3,4,5 minutes to get access to the WEBui is needed.
VMware Workstation helps organizations deploy many applications and operating system workloads on a single server. Thus, it helps in better resource management. The workstation is an efficient and advisable solution for local desktop virtualization as it lets you securely run an additional operating system as a VM on a single computer.
582128177f