Arch Linux User Repository

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

@gorgiaxx

If you look at the sources, this is already the case https://aur.archlinux.org/cgit/aur.git/tree/config?h=vmware-workstation

I think you have old configuration in /etc/vmware/config and/or maybe a configuration update waiting in /etc/vmware/config.pacnew (not sure if AUR packages are generating .pacnew files, but but these files are good to watch every now and then as they may contain important updates)

@jihem Ty for sharing this idea with others, cool from you ;)

But I haven't used your implementation yet, I doubt that PathExistsGlob= is necessary over PathModified=. The *Glob variable has its own variable name because it make uses of regular expressions, and they have a performance cost over regular methods.

If it was up to me I would have not used PathExistsGlob if there is no specific reasons to use over the regular method.

But that's just different way of thinking anyway, not a big deal, I see you prefer to let the user to handle all the servicing stuff, while for me this is to the package responsability to install and remove the necessary files, I would hate to uninstall a systemd package that would leave behind a whole bunch of installed service, same rule for vmware, Arch Way :s

VMware workstation 16 start failed after install.

2021-06-24T14:28:00.148+08:00| appLoader| I005: Log for appLoader pid=10417 version=16.1.2 build=build-17966106 option=Release
2021-06-24T14:28:00.148+08:00| appLoader| I005: The host is 64-bit.
2021-06-24T14:28:00.148+08:00| appLoader| I005: Host codepage=UTF-8 encoding=UTF-8
2021-06-24T14:28:00.148+08:00| appLoader| I005: Host is Linux 5.12.12-arch1-1 Arch Linux
2021-06-24T14:28:00.177+08:00| appLoader| I005: Invocation: "/usr/lib/vmware/bin/vmware
2021-06-24T14:28:00.177+08:00| appLoader| I005: "
2021-06-24T14:28:00.177+08:00| appLoader| I005: Calling: "/usr/lib/vmware/bin/vmware
2021-06-24T14:28:00.177+08:00| appLoader| I005: "
2021-06-24T14:28:00.177+08:00| appLoader| I005: VMDEVEL not set.
2021-06-24T14:28:00.177+08:00| appLoader| I005: Using configuration file: /etc/vmware/config
2021-06-24T14:28:00.178+08:00| appLoader| E002: The "libdir" entry was not present in configuration file.
2021-06-24T14:28:00.178+08:00| appLoader| I005: Use library directory: (null)

Append this line to the vmware configuration file.

echo 'libdir = "/usr/lib/vmware"' >> /etc/vmware/config

Thank you jihem.

You simply need to do systemctl disable --now vmware-networks.service && systemctl enable --now vmware-networks.path. After that the service will be launched only when a VM is started. Unfortunately it is not a perfect solution because the service won't be stopped when the VM is shutdown.

would someone care to explain how do i implement this new .path units solution? when i first installed vmware,i ran systemctl enable vmware-networks.service and now i can see i have vmnet processes running even though Vmware is closed. so how can i have them start only when a vm is launched?

@idanyadgar I've tested with the official VMware installer on Fedora 34, same problem (with similar logs). Probably a new library version that break something. I won't investigate more time because it's not a packaging problem, but if you find a workaround I can try to implement it.

@class101 Thanks, it's implemented, juste a little bit differently.

I still let the possibility to launch services at boot time (and of course, to keep them completely disabled, because I totally agree with crdx).

@class101, Great response.

Power management endpoints in the REST API don't work.

vmrest -d

curl 'http://127.0.0.1:8697/api/vms/C3Q6N31L9CCLTL82I1VJ0DAL9PVL89L6/power' -X GET --header 'Accept: application/vnd.vmware.vmw.rest-v1+json' --header 'Authorization: Basic ENTER_TOKEN_HERE'

And I get: { "power_state": "poweredOff" }

(And the machine is powered on)

Changing the VM power state (to on or suspended) also does not work (I believe it is because the VM is considered off although it isn't).

This API works under other distros.

Thread in VMWare's forums: https://communities.vmware.com/t5/VMware-Workstation-Pro/REST-API-power-management-machines-are-always-off/m-p/2852406

@crdx

Not every changes in my patch are to consider, I guess you mean about the changes I have added into the .install file, they are much for me here because I prefer to have the thing setup the way I want without much tinkering needed after installing the package, when installing a package from Arch Linux, I exxpect the package to do all the necessary things for the package to work properly, if the package tell me, do X to enable X, do Y to enable Y, I don't think it is either the Arch Way.

The improvment proposal is much about replacing the procedure that is to ask the user to enable .service, you could instead ask the user to enable .path files, that way, the service will only start on-demand when they are needed, instead of providing the only solution which is actually to startup the service permanently and forget about it.