VMware

Restricting User access to Workstation VMs

Hello,

I was wondering if you could help me with this. I’m using VMware Workstation Pro 15 for Windows. I want to create a VM for AD users to use, but not allow them to edit the vm configurations.

I first tried using the Shared VMs feature, with Roles to only allow users to play/stop the VM, but wasn’t able to set up shared folders for the VM (the option doesn’t show up).

I also tried the solution offered here (solution which is compatible with having shared folders): [https://pubs.vmware.com/ws6_ace2/ws/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ws&file=ws_special_restrict.html](https://pubs.vmware.com/ws6_ace2/ws/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ws&file=ws_special_restrict.html). It seems, though, that the guide is outdated and only works for old workstation versions? The option “gui.restricted” appears to be ignored, and for some reason VMware requires the vm configuration file .vmx to be writable by the user, to be able to launch the VM! (When launching the VM, an “insufficient permissions to access file” error shows up).

I also took a look at the option of encrypting the VM and “enabling restrictions”, but it’s not practical (it would require the users to know the encryption password) and only restricts some of the configurations.

What else can I try? What are the reasons to not have the option for shared folders on shared VMs? Why does the user need write permissions to the VM configuration file to be able to launch it?


View Reddit by eternal_tugaView Source

Related Articles

5 Comments

  1. Hi,
    I’m not sure that this is really a use case that VMWare Workstation is meant to cover. This seems more like a vSphere/ESX use case. Can you better define exactly what need you’re trying to fulfill by having each user use Workstation instead of accessing a VM on a hypervisor?

  2. You need ESXi standard + for this maybe even enterprise. I have devs that spin up tons of labs, we still let them access ESXi because we do this well via resource groups.

  3. Enabling restrictions is the solution.

    Note that there are 2 separate passwords.

    One password for the encryption, needed to boot the VM.

    Another password for enabling the restrictions.
    Not sure what you mean by “only restricts some of the configurations” as AFAIK you cannot make changes to the configuration after enabling restrictions without knowing the restrictions password.

  4. If you’re the one creating and managing access to the VMs, why not just give them SSH access to the VMs and deny their ability to interface with workstation? If they need console (GUI) access, then setup VNC. Take a snapshot of it when you have it configured and roll back as needed.

    If they need the ability to create their own VMs then create a docker host and give them the ability to spin up containers. If you use a windows host, they can spin up windows server core containers to do some .net crap as needed.

Leave a Reply

Your email address will not be published. Required fields are marked *

Close