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

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.

Isn't it the arch way never to start services automatically on install, and leave it up to the user to decide if they want to start them or not?

Security vulnerability ? Doubt it, systemd is a robust core component of Linux and services are root started, not user started.

As you see here[1] there are 11 type of unit files and each can be used to implement on-demand starting of services, as well as parallelized starting of services.[2]

I think the correct type of unit for vmware workstation is .path[3], socket is not suitable in here because the application must be aware of the socket to connect to to trigger the on-demand load.

It does a few days I'm testing this and it works flawlessy, I made a patch so you can experiment the complete suite quickly, basically after applying the patch and rebuilding the package, the vmware-networks and vmware-usbarbitrator services will only start after hitting play on a virtual machine.

https://gist.github.com/class101/8ecb2c6dc8ebb7428a01eb56b2c5f9c5

I don't think it is necessary to implement the stop, it seems outside the scope of the unit files, maybe there is something possible to do with the PathChanged= statement as it seem to trigger on file closed, well I've not tested this yet, I'm just doing a bash alias as the following one in /etc/bash.bashrc, but if someone find a proper way to implement the stop, feel free to share :)

alias vmware-stop='systemctl stop vmware-usbarbitrator.service vmware-networks.service'

Let me know if you have any more questions, you are welcome :)

[1] https://www.freedesktop.org/software/systemd/man/systemd.html
[2] https://www.freedesktop.org/software/systemd/man/systemd.socket.html
[3] https://www.freedesktop.org/software/systemd/man/systemd.path.html