However, after updating to latest kernal, it doens't start up even though installation goes thru fine. At this point, I am little disappointed with Solus. It's fast and light what it offers for OOTB. Anything else seems a bit struggle and lot of research. I am switching back to Windows train.
However, using software like VMware Workstation is always a little more complicated on Linux, but really not too difficult. My earlier posts outline a script you can run each time there is a kernel update to update the kernel modules so you can once again run the software. It's quite simple, and has been working for me and others for quite some time.
Part way through the command it will as you for the password for elevated privileges (using sudo), so just input your user password there (as long as your user is an administrator, which is the default for the primary user.)
I have always managed to get VMware Workstation working in the past but am having 1 issue with 15.5. I have to manually run the VMware service after booting (sudo systemctl start VMware.service) and when I try to enable the service the symlink creation fails. I've tried pretty much everything including SuperJC710e's script, but still no love. Ideas are appreciated. BTW, I'm using current - not LTS
mhbaustin I recall getting that same error. Doing some research I think my vmware service is starting because the vmware-usbarbitrator service was successfully enabled and it requires the vmware service. I'm not 100% clear on all the workings of systemd, but I think the enable command we are using sees the sysv style init script in /etc/init.d and is trying to run the built in sysv wrappers to enable that command directly. Solus, as a pure systemd OS has not implemented the systemd-sysv-install script. Here's the link to the skeleton for that script, which gives some explanation: -sysv-install.SKELETON
hello, I'm using VMWare workstation 16.1.0, following your guide and the GitHub link by mkubecek, I was able to get everything working! but for some reason I cant enable the vmware.service, even using the full path name to get around sysv. It seems like there isn't even a file vmware.service, but starting it of course works just fine, I'm using Solus 4.1.
Not sure if you created your own unit files or not? In the initial post there is reference to the Arch Linux wiki pages where you may need to copy the unit files and place them in /etc/systemd/system. (I've had VMware Workstation from much earlier versions, so I can't recall if it installed the unit file, or if I copied it.)
I clearly understand that the guide says the Hypervisor Supported are VMware ESXI. But I want to use it in my VMware workstation.
I have downloaded ovf template and installed it on the Workstation. the installation was completed quickly but in the CLI login, I'm getting stucked.
So my question is , If i can work on VMware workstation? or are there any workaround to get it resorted ? In vmware workstation, I have built PA labs using VM series Images before . I don't know if this trial image has any particular restrictions!
Might need to boot into maintenance mode and factory reset the configuration prior to it coming up fully. The trial specifically seems to be having an issue actually booting without that step. Workstation will support the VM just fine, even if it's not officially supported.
..Pro Apps are now Free for Personal Use and Licensed for Commercial Use
The most exciting part is that Fusion Pro and Workstation Pro will now have two license models. We now provide a Free Personal Use or a Paid Commercial Use subscription for our Pro apps. Users will decide based on their use case whether a commercial subscription is required.
This means that everyday users who want a virtual lab on their Mac, Windows or Linux computer can do so for free simply by registering and downloading the bits from the new download portal located at support.broadcom.com..
As an example, if you were a previous VMware customer that bought perpetual licenses for the previous versions of the products (say old versions of Workstation and Fusion), then you might find that, like me, that the keys for them have been lost from Broadcom if you login to the Broadcom support site using your migrated VMware customer account.
This Free-for-Personal-Use offer is only for VMware Workstation Pro 17.5.2 and VMware Fusion Pro 13.5.2. The installation binaries are specifically modified to allow for this use case. Binaries for the older versions have not been modified in the same way (nor do I expect Broadcom to), so to use the older versions you will still need your old license keys.
I been trying to download wmware workstation v 17 for the better part of the day today. I get to the part of the process where I am ready to download, but broadcom.com download page noted that my id has to be validated. It been in that state all day today
We are pleased to announce the release of the Vagrant VMware Desktop plugin. This plugin is a unification of the Vagrant VMware Fusion plugin for macOS and the Vagrant VMware Workstation plugin for Linux and Windows. Existing users of the Vagrant VMware Fusion or Workstation plugins can update to the new VMware Desktop plugin free of charge.
The new VMware Desktop plugin includes an updated implementation and installation process. This process addresses critical security issues that were found in prior versions. All users are recommended to install this update immediately. More details are available below.
The Vagrant VMware Desktop plugin now supports both VMware Workstation and VMware Fusion. The unification of these two plugins includes an implementation update which has resulted in a separation of duties within the plugin. In previous versions of the VMware Fusion and Workstation plugins, all setup was performed during the plugin installation process. Included within this installation process was the setup for privileged access required for VMware interaction. A number of issues resulted from this installation approach and to resolve the issue the Vagrant VMware Desktop plugin now consists of two parts:
This update fixes a number of critical security vulnerabilities in prior versions and is highly recommended. The update will work with all supported versions of VMware Fusion and Workstation.
The vulnerabilities fixed include mechanisms for root privilege escalation from a malicious Vagrantfile or previously installed malware outside of the Vagrantfile. We will edit this post and link directly to the CVEs here as they are published.
These vulnerabilities were reported to HashiCorp in late 2017 as part of a batch of critical findings by Mark Wadham. It has taken until now to restructure the plugin to resolve these vulnerabilities. We apologize for how long this has taken and thank Mark for working patiently with us as we worked toward this release.
The new unified Vagrant VMware plugin includes a new step (the VMware Utility) to separate the privileged operations required for the plugin to operate and relies on system installers to safely install these services. Beyond this, various fixes were also made to the plugin itself for safer operation.
The Vagrant VMware Utility is a system installer package and is required by the Vagrant VMware Desktop plugin for proper functionality. This system installer provides a small utility service that Vagrant utilizes for interacting with VMware on the system.
Isolating the features which require privileged access into a system installer package provides an easier and more secure installation. Isolating privileged activities to the Vagrant VMware Utility also means that only one privileged installation action must be taken on a system. After the package is installed, any user on the system can be allowed to interact with the utility without the need for privilege escalation.
The Vagrant VMware Desktop plugin is the Vagrant plugin which adds support for the vmware_desktop provider to Vagrant. The installation method for this plugin follows the same methodology as previous Vagrant VMware plugins. First install the plugin:
With the introduction of a unified VMware plugin, all future updates will be made to the Vagrant VMware Desktop plugin. All existing users of the Vagrant VMware Fusion and Workstation plugins are encouraged to upgrade. Aside from the plugin unification and installation updates, a common provider name can now be used for configuring a VMware guest from the Vagrantfile.
The Workstation and Fusion specific plugins required the explicit provider name (vmware_workstation or vmware_fusion) when configuring VMware. The Desktop plugin still supports the old provider names but also adds a common provider name that is not specific to Workstation or Fusion: vmware_desktop.
Also added in this plugin is support for the Vagrant package command. This allows a Vagrant guest to be configured locally and then packaged into a new Vagrant box which can be moved or shared for reuse.
In last week's article, we discussed virtualization and its role in reducing server sprawl. We included VMware server as one of the productsused to virtualize a data center. VMware also sells a workstationwith a well-established reputation. This week we take a look atVMware Workstation 5.0.
In the past, many analysts have given kudos to VMware workstation foraiding people who want to run different operating systems for developmentand testing. Some even have claimed that the product accelerates applicationdeployment. Similar suggestions abound about VMware workstation allowingWindows users to play around with Linux without having to format theirhard drives.
Journalists who rely on VMware to evaluate and write about Linux on theirWindows laptops, however, will never understand the power and sophistication ofLinux. VMware Workstation has many uses, but it is not a substitute fora native Linux installation on bare hardware. Reviewers who practiceusing VMware to evaluate Linux do themselves and the community a greatdisservice.
c80f0f1006