Package Details: vmware-workstation 17.6.1-2

Git Clone URL: https://aur.archlinux.org/vmware-workstation.git (read-only, click to copy)
Package Base: vmware-workstation
Description: The industry standard for running multiple operating systems as virtual machines on a single Linux PC.
Upstream URL: https://www.vmware.com/products/workstation-for-linux.html
Keywords: dkms ovftool player vmplayer vmware workstation
Licenses: custom
Conflicts: vmware-modules-dkms, vmware-ovftool, vmware-patch, vmware-systemd-services
Provides: vmware-ovftool
Submitter: synthead
Maintainer: jihem
Last Packager: jihem
Votes: 202
Popularity: 2.79
First Submitted: 2017-02-10 19:04 (UTC)
Last Updated: 2024-10-11 05:17 (UTC)

Sources (22)

Pinned Comments

jihem commented on 2020-02-10 17:29 (UTC) (edited on 2021-06-19 13:19 (UTC) by jihem)

After the first installation, please:

1) install the appropriate headers package(s) for your installed kernel(s): linux-headers for default kernel, linux-lts-headers for LTS kernel...

2) reboot or load vmw_vmci and vmmon kernel modules (modprobe -a vmw_vmci vmmon)

3) Enable the services you need (using .service units to activate them during boot or .path units to activate them when a VM is started) :

  • vmware-networks: to have network access inside VMs

  • vmware-usbarbitrator: to connect USB devices inside VMs

Latest Comments

« First ‹ Previous 1 .. 53 54 55 56 57 58 59 60 61 62 63 .. 66 Next › Last »

ksqsf commented on 2017-10-01 10:32 (UTC)

@jihem: It seems to create three apploader log files. They look the same despite the timestamp. I've uploaded one with the least PID: https://slexy.org/view/s2ZxY7F4fT . (more undefined symbols than I expected!) $ pactree -r ibus ibus ├─ibus-anthy └─ibus-rime PS: Something interesting: sometimes the UI appears but quickly disappears because of the undefined symbol. However, the VM is still running in the background, and sometimes the UI is still accessible (through the tray icon). I have no idea why.

jihem commented on 2017-10-01 09:22 (UTC) (edited on 2017-10-01 09:29 (UTC) by jihem)

@ksqsf: thanks for the precision. And you are two, so it's not an isolated bug. Strange that I don't have this bug whereas I'm testing in the same conditions. Can you give me the content of the file /tmp/vmware-$USER/vmware-apploader-xxxx.log (where xxxx is a PID number) after starting vmware with the error? (If you have several files like that, just remove /tmp/vmware-$USER directory before restarting VMware.) Edit: can you also give me the output of "pactree -r ibus"? I'm interested to know which package depends on it.

ksqsf commented on 2017-10-01 08:58 (UTC)

@jihem: I can reproduce this problem on GNOME 3.24 with iBus installed. The problem occurs on both Xorg and Wayland sessions. "VMWARE_USE_SHIPPED_LIBS=yes vmware" works.

jihem commented on 2017-10-01 08:43 (UTC)

@lshbir: I am not able to reproduce your bug, I need more informations. Can you tell me which desktop environment do you use (Gnome, KDE, xfce...)? Does it work on Xorg or Wayland? Do you have the package ibus installed? Can you also tell me if these workarounds work: - start your session on Xorg instead of Wayland or the contrary (if your DE is compatible Wayland) - start VMware with the command "VMWARE_USE_SHIPPED_LIBS=yes vmware"

Ishbir commented on 2017-10-01 05:18 (UTC)

I just upgraded to the latest version and when I run vmware from the terminal, this is what I get: /usr/lib/vmware/bin/vmware: symbol lookup error: /usr/lib/gtk-3.0/3.0.0/immodules/im-ibus.so: undefined symbol: gdk_wayland_display_get_type

jihem commented on 2017-09-30 07:56 (UTC)

Hi guys, I've just updated the package for the new major release of VMware. It seems to me all works well, but as it is a big update, it's possible I forgot to include some functionalities or something works wrong. If it's the case, and the problem is related to the package and not the program (see VMware forum before), please tell me. Unfortunately for people who don't want to upgrade (because of license price or incompatible hardware), I won't maintain VMware 12 anymore. It's too complicated for me to maintain two versions at the same time. Nevertheless, you can easily install the last version of this package for VMware 12.5 (see below for the how-to). This version should work well for a long time: I patched it to work with Linux 4.14, the next LTS version and, if you encounter problems of incompatible libraries in the future (the program crash at startup without writing anything in the terminal), you can solve it by uncomment the line in the file /etc/profile.d/vmware.sh. Of course, if someone is motivated to maintain VMware 12, feel free to create a new package! To install the last version of VMware 12: git clone ssh://aur@aur.archlinux.org/vmware-workstation.git cd vmware-workstation git checkout 2965e8782be11ce0049f32fafa96b2d60c0282c8 makepkg -i

jihem commented on 2017-09-25 15:49 (UTC)

Thanks again! I thought that Exec lines work like systemd ExecStart lines but you are right, only the last line is executed (a more simple fix than yours would be to use modprobe with -a argument). Anyway, I removed the hook. That was finally a bad idea because it's not standard and it does not work with your example (I didn't thought this case). I also added the note in post_install as I did before adding this hook.

ngkaho1234 commented on 2017-09-25 11:29 (UTC) (edited on 2017-09-25 15:19 (UTC) by ngkaho1234)

@jihem: These changes look good. However, I found that in 90-vmware-load-modules.hook, only the vmmon module would be loaded due to the second occurrence of Exec= overriding the first one. Actually the fix is quite trivial: replacing all the occurrences of Exec= with a single Exec = /bin/sh -c '/usr/bin/modprobe a; /usr/bin/modprobe b' or whatever. Not only that, in case when users install vmware-workstation.pkg.tar.xz right after doing a pacman system upgrade, the hook will fail due to missing module (since in Arch Linux, upgrading a kernel will remove the modules directory of its previous version). That failure doesn't indicate anything fatal, it just indicates that the hook doesn't do anything in such case (and users still need to reboot). Thus, I suggest removing the hook in future, and printing some lines in post_install script to tell the users either reboot the machine or manually load the required kernel modules. By doing so, the procedures users need to take when dealing with vmware modules will be mostly the same as dealing with dkms/binary modules in official repo (nvidia/nvidia-lts/nvidia-dkms, wireguard-dkms, broadcom-wl-dkms, ...) EDITED: Sentenses rewording...

jihem commented on 2017-09-24 10:21 (UTC)

@ngkaho1234: Thank you very much for your review! I decided to switch to vmw_vmci, because it works well and should avoid future incompatibilities and reduce compilation time with DKMS. I also fixed vmci with your patch because I don't want to let an incorrect source code, even if probably nobody will use it.

ngkaho1234 commented on 2017-09-23 11:37 (UTC) (edited on 2017-09-24 05:06 (UTC) by ngkaho1234)

Hello, according to the implementation of pci_enable_msix_range(), since vmci_enable_msix() must return 0 on success, the changes that makes vmci/linux/driver.c able to compile is wrong. Here is the implementation of pcie_enable_msix() and pcie_enable_msix_range(): http://elixir.free-electrons.com/linux/v4.9.51/ident/__pci_enable_msix_range Currently, I workaround the issue by applying my own changes to vmci module. Here is the changes i made to the affected part of the vmci module: https://ptpb.pw/oKZB EDIT: We might also consider switching to vmw_vmci instead of vmci, which is similar to what we already did to vsock.

« First ‹ Previous 1 .. 53 54 55 56 57 58 59 60 61 62 63 .. 66 Next › Last »