Talk:VMware

GUI doesn't show after upgrade

Is it necessary to copy the missing libraries to /usr/lib/vmware/lib/? I think it will be better to use soft links.

ThomasWFan (talk) 00:58, 18 July 2017 (UTC)

I just wanted to record that the workaround listed here (export LD_LIBRARY_PATH...) does actually resolve the problem for Workstation 11.1.3 (I'm running on a 4.4.1 Kernel)

I agree that the solution is not easily confirmed (I've read /usr/bin/vmware and there's nothing obvious why LD_LIBRARY_PATH is required) - but that's probably an issue to be taken to VMware, rather than reported in depth here.

This workaround is not easily found on the rest of the internet and I have been struggling to get this working for a while (on & off..), so it is definitely a good idea to keep this section here.

RuneArch (talk) 09:15, 18 February 2016 (UTC)

Hi, I have this same issue with vmware where the GUI won't show, but If I try the trick in this section of the wiki, it tells me modules have to rebuild, but nothing happens after https://wiki.archlinux.org/index.php/VMware#GUI_doesn.27t_show_after_upgrade. I still get this output: http://slexy.org/view/s2lgjglqrN

Professorkaos64 (talk) 20:56, 5 July 2016 (UTC)

I'm using version WS 12.5 with kernel 4.8, searching all pages in many days, then just need add one line: "export VMWARE_USE_SHIPPED_LIBS=force" in /usr/bin/vmware. The solution comes from https://bugzilla.redhat.com/show_bug.cgi?id=1278896#c3. It works for me. Hope this help.

User:pacman Oct 23 15:24:53 UTC 2016

Tools Download Link

If anyone facing an issue with vmware tools, like could not install component, you can manually download tools from vmware.

http://softwareupdate.vmware.com/cds/vmw-desktop/ws/

Just shared so someone can find it usefull ;-)

—This unsigned comment is by ABHIRAMSHIBU (talk) 04:00, 28 November 2016‎ (UTC). Please sign your posts with ~~~~!

Kernel Modules Not Compiling (Again)

It seems that with the 4.9 kernel vmware is again refusing to compile modules. Just an advisory for anyone currently running testing. I'm sure that there should be another patch / workaround available soon for it. It seems like VMWare is having this issue more often with recent kernels. I think this is the third time in the past six months with only 4.8 not having any new problems. Is this a problem with the kernel changing more stuff lately than normal or is this VMWare's problem? --TheChickenMan (talk) 08:20, 30 December 2016 (UTC)

Any out-of-tree (non-mainline) driver should get out of sync with each major release of the kernel due to the huge churns and thousands of symbol changes (there's no such thing as a stable ABI for the kernel, because you couldn't then change anything).

VMCI and VSOCK have been mainlined since 3.9 (April 2013) and get automatic updates/syncs, but VMMON and VMnet remain bundled/maintained in the app (see this for vagueish expalantions on each).

4.9 should be fixed by this: http://rglinuxtech.com/?p=1863 (RGLinuxTech is always a good go-to-first resource for Nvidia/VMware breakage)

--Det^talk 07:43, 31 December 2016 (UTC)

Thanks the modules were an easy fix with this and verified working now. I think this should be held off though. No reason to add it to the main wiki until 4.9 leaves testing. I'll bookmark that site for future reference. --TheChickenMan (talk) 18:47, 1 January 2017 (UTC)

Well no, you can add it. There's not even an official package called "vmware-workstation", it's something you install manually, and vmware-patch^AUR is also in AUR. As soon as a new patch is released, it can be added here, so people who use linux-mainline^AUR also get the benefit.

--Det^talk 18:52, 1 January 2017 (UTC)

VMware Remote Console

(After successfully installing the bundle, and vmware-patch) vmrc does not ouptut anything (quiting silently).

Chinggis6 (talk) 11:37, 20 April 2017 (UTC)

The problem is: Unable to load libgdk_pixbuf-2.0.so.0 from /usr/lib/vmware/lib/libgdk_pixbuf-2.0.so.0/libgdk_pixbuf-2.0.so.0: /usr/lib/librsvg-2.so.2: undefined symbol: cairo_tag_begin

As workaround, you can tell vmrc to load libraries only from /usr/lib/vmware/lib/ adding to /etc/vmware/bootstrap:

for f in /usr/lib/vmware/lib/*; do
  [ -d "$f" ] && ldpaths="$ldpaths:$f"
done
export LD_LIBRARY_PATH="$ldpaths:/usr/lib"

BaSh (talk) 13:54, 16 May 2018 (UTC)

Cleanup

The 'Troubleshooting' section is ever expanding. I'd like to suggest pruning issues which definitely apply to old (minor) versions of VMware only (12.5.3 through 12.5.5 seem no longer relevant to me). Any opinions? --Thralas (talk) 15:10, 25 May 2017 (UTC)

I agree that it could use some cleanup. On a related note, I was thinking there should be a note somewhere on linux-lts, since vmware has tendency to break with every new minor version of linux. --StrayArch (talk) 15:42, 10 June 2017 (UTC)

To further expand on my previous comment --- the troubleshooting subsections for old minor versions should stay. After updating and rebooting, I am still unable to get 12.5.6 to work with linux and awesome. For now, I am using 12.5.4 with linux-lts. tl;dr the subsections regarding old minor versions should be kept since they are relevant to lts. --StrayArch (talk) 16:56, 10 June 2017 (UTC)

Ehm... NO! Yes, it has a tendency to break and that's why this section is so important. Why do you want to take away from users the only real useful information in this article: Easy to follow and definitely working ways to fix their problems and get VMware working again. Besides that, v12.x is not a legacy version. It is still supported and most people can't switch to VMware 14 as it removed support for a whole bunch of CPUs. It can be fixed to run on these CPUs, but not performantly. Furthermore, why did you flag the section for removal I just added yesterday? It does not apply to old minor versions of 12.x, but the latest one. If you really can't stand a wiki page providing valuable information collected by people for a long time to help others, may I suggest to create a subpage just for VMware troubleshooting? --Bachsau (talk) 02:40, 10 February 2018 (UTC)

This section has a link to the vmware-host-modules repo from which the patch in "your new section" is downloaded and a link to the vmware-patch^AUR package which applies the very same patch. So we don't really need one specific section for each new kernel/vmware version. -- Lahwaacz (talk) 12:42, 10 February 2018 (UTC)

And I don't see a problem in having thousands of these sections as long as they are of any use and look organized. Keeping information is always better than removing it. Of course there are other methods, but for me it is much easier to follow some simple instructions instead of installing another package or autopatcher from a git repository with lots of code, where I first have to inspect what exactly it will do to my system before installing it. Furthermore, the aur package has been abandoned for a long time. --Bachsau (talk) 14:14, 10 February 2018 (UTC)

Even 5 of these sections don't look organized in any way - what's organized is the vmware-host-modules repo which is the source of all of these patches. It's perfectly fine for it to be linked just once and there is no problem with removing superfluous information. I also don't see why you're so concerned with inspecting every piece of code in the repo and not the patch you'd have downloaded otherwise. Besides, all of it is to make some proprietary shitcode working... -- Lahwaacz (talk) 23:56, 10 February 2018 (UTC)

Of course it is proprietary shitcode. Even though I think that changing the name of kernel functions for no reason in a minor release is also a bad idea. Unfortunately, on the desktop, we are in lack of alternatives, with the only one being VirtualBox, which also has a lot of bugs, lags many features and is not nearly as fast as VMware Workstation. --Bachsau (talk) 00:43, 12 February 2018 (UTC)

Cannot load Module vmmon: I can load the kernel module just fine with secure boot enabled.

This part links to a post where it is said that secure boot has to be disabled to load the kernel module. I can do just fine with secure boot enabled. Although I did not set up the kernel to only load signed modules. Ideas?

-- IPlayZed (talk) 10:42, 26 October 2022 (UTC)