VMware Workstation

 View Only
  • 1.  RHEL 9.4 and VMware Workstation 17.5.2

    Posted Jun 16, 2024 10:38 AM

    Observations:   The latest kernel of RHEL 9.4 has some challenges for the installation of VMware Workstation Pro 17.5.1 & 17.5.2  on a personal workstation.

    1.   Minor challenge - Fresh install of RHEL 9.4 had missing kernel-headers and kernel-devel via official RHEL repos. These had to be downloaded & applied via a RHEL security advisory. https://access.redhat.com/errata/RHSA-2024:2394

    View of OS prior to installation of kernel-headers and kernel-devel libraries.

    $ rpm -qa kernel*

    $ uname -a
    Linux hostname.here 5.14.0-427.13.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 10 10:29:16 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

    2a.   VMware workstation pro 17.5.1 & 17.5.2 both reported an error with the "vmware-modconfig" section during installation.

    # ./VMware-Workstation-Full-17.5.2-23775571.x86_64.bundle

    [Makefile:117: vmmon.ko] Error 2
    [Makefile:1934: /tmp/modconfig-cwzWEe/vmnet-only] Error 2\nmake: ***
    [Makefile:117: vmnet.ko] Error 2\nUnable to install all modules.  See log for details.\n\n'

    Upon review within the installation log, it appears that two (2) modules need to be modified.
    vmmon  & vmnet

    2b.   To confirm the issue, tested with the vmware-modconfig  process.

    $ sudo vmware-modconfig --console --install-all

    [AppLoader] GLib does not have GSettings support.
    (process:95861): GLib-CRITICAL **: 12:43:01.941: g_file_test: assertion 'filename != NULL' failed

    - Upon additional research, I was able to find a working process via a dedicated git to the two (2) vmware host modules.


    Specifically, the steps introduced in this ticket resolved my challenge with RHEL 9.4 with the same kernel version.


    ####  Enclosing steps below to address installation challenges of personal edition of VMware workstation pro 17.5.2 on RHEL 9.4 ####

    A. Address missing OS libraries [download and install two (2) RHEL libraries that match the current kernel version, including dependencies]

    dnf list kernel-devel-$(uname -r)

    dnf list kernel-headers-$(uname -r)

    sudo rpm -ivh /os-patches/kernel-headers-5.14.0-427.13.1.el9_4.x86_64.rpm

    sudo dnf -y install elfutils-libelf-devel

    sudo dnf -y install openssl-devel

    sudo rpm -ivh /os-patches/kernel-devel-5.14.0-427.13.1.el9_4.x86_64.rpm


    B.  Download the mkubecek/vmware-host-modules git repo and checkout the git that matches current VMware workstation release.

     [Note:  git version 17.5.1 worked for vmware workstation pro 17.5.2 as well]

    mkdir vmware-module-git ; cd vmware-module-git

    git clone https://github.com/mkubecek/vmware-host-modules.git

    cd vmware-host-modules/

    vmware --version

    git checkout workstation-17.5.1

    C.   STOP and edit two (2) files:

     Ref:  https://github.com/mkubecek/vmware-host-modules/issues/244


    cd vmmon-only/include/

    cp -r -p pgtbl.h pgtbl.h.prior.20240613


    vi pgtbl.h and change this line:






    cd vmnet-only/

    cp -r -p bridge.c bridge.c.prior.20240613


    vi bridge.c and change this line:







    D.  Continue with make process for the two modules


    sudo make clean


    sudo make install

    sudo systemctl restart vmware.service

    sudo systemctl status vmware.service

    E.   Validate vmware workstation is working and able to access networking features.

     Able to enter license in to UI and continue with access.


    F.   Output examples of validation of working installation.

    $ systemctl status vmware.service
    ● vmware.service - VMware host virtualization and network services for Workstation
    Loaded: loaded (/usr/lib/systemd/system/vmware.service; enabled; preset: disabled)
    Active: active (running) since Thu 2024-06-13 17:40:34 CDT; 16min ago
    Process: 151074 ExecStart=/usr/lib/vmware/scripts/init/vmware start (code=exited, status=0/SUCCESS)
    Tasks: 6 (limit: 3296082)
    Memory: 3.4M
    CPU: 152ms
    CGroup: /system.slice/vmware.service
    ├─151134 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet1.pid /dev/vmnet1 vmnet1
    ├─151140 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet1/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet1/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhcpd-vmnet1.pid vm>
    ├─151144 /usr/bin/vmnet-natd -s 6 -m /etc/vmware/vmnet8/nat.mac -c /etc/vmware/vmnet8/nat/nat.conf
    ├─151146 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet8.pid /dev/vmnet8 vmnet8
    ├─151149 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet8/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet8/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhcpd-vmnet8.pid vm>
    └─151166 /usr/sbin/vmware-authdlauncher

    $ vmware --version
    VMware Workstation 17.5.2 build-23775571

    $ uname -a
    Linux hostname.here 5.14.0-427.13.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 10 10:29:16 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

    $ sudo /usr/bin/vmware-networks --stop ; sudo /usr/bin/vmware-networks --verbose --start
    Stopped Bridged networking on vmnet0
    Stopped DHCP service on vmnet1
    Disabled hostonly virtual adapter on vmnet1
    Stopped DHCP service on vmnet8
    Stopped NAT service on vmnet8
    Disabled hostonly virtual adapter on vmnet8
    Stopped all configured services on all networks
    Commands specified: start
    Features configured on vmnet0 are: Bridge
    Started Bridge networking on vmnet0
    Features configured on vmnet1 are: subnet DHCP HostOnlyAdapter
    Creating thread #: 0 to ping subnet on vmnet1
    Checking availability of subnet configured for vmnet1
    Features configured on vmnet8 are: subnet DHCP NAT HostOnlyAdapter
    Creating thread #: 1 to ping subnet on vmnet8
    Checking availability of subnet configured for vmnet8
    Subnet configured for vmnet1 is available
    Subnet configured for vmnet8 is available
    Checking if services on vmnet1 can be started, thread #0
    Enabled hostonly virtual adapter on vmnet1
    Started DHCP service on vmnet1
    Finished processing thread #0 on vmnet1
    Checking if services on vmnet8 can be started, thread #1
    Started NAT service on vmnet8
    Enabled hostonly virtual adapter on vmnet8
    Started DHCP service on vmnet8
    Finished processing thread #1 on vmnet8
    Started all configured services on all networks

     Final / Side note:  Do not run the vmware-modconfig as it will still fail.   

     sudo vmware-modconfig --console --install-all

    Hopefully this note has some value to others.


    Alan Baugher

  • 2.  RE: RHEL 9.4 and VMware Workstation 17.5.2

    Posted 29 days ago
    Edited by Alan Baugher 29 days ago

    FYI - Two (2) follow-ups were needed to address minor issues.

    1. UI issue for non-root user.
      • Added env variable to .bashrc  for non-root user.
        • export VMWARE_USE_SHIPPED_LIBS='yes'    
      • log out and log back in as user, and launch vmware.

    2.   Unable to import an OVA file.   The screen would not advance to next screen after selecting the OVA file.
      • Observed no error messages within vmware logs nor journaclt
      • Attempt to load ova file with the CLI tool of 'ovftool'  and was able to capture error message of missing/deprecated library.
      • Use  'strace -e openat ovftool'  to confirm error message and missing library of 'libnsl'
      • yum provides libnsl    show this to be a deprecated library that is no longer shipped default with glibc for RHEL 9.4
      • deployed with   'dnf install -y libnsl'   and now able to use the Vmware UI to import OVA files.
      • Ref. https://access.redhat.com/solutions/4975641

    ### ###

    View of "export VMWARE_USE_SHIPPED_LIBS='yes'"  in  .bashrc of non-root user.

    .bashrc and env variable


    View of "strace -e openat ovftool" and error message due to missing/deprecated library of 'libnsl'

    strace -e openat ovftool

    Confirm that you can advance screens during the import of the OVA file.

    OVA Import in VMware UI

    Alan Baugher

  • 3.  RE: RHEL 9.4 and VMware Workstation 17.5.2

    Posted 29 days ago
    Edited by Alan Baugher 29 days ago

    We are using MITM methodology to isolate the certificate issues.

    Ref.  https://anapartner.com/2023/07/13/secure-application-introspection/

    On MS Windows, VMware Workstation uses MS Windows keystore (certlm.msc).
    On RHEL 9.x  VMware Workstation uses /etc/pki location  (see README file for steps to use 'update-ca-trust' process)

    rhel 9 update-ca-trust
    A view of the flow captured.   It appears the root CA cert was not in the OS keystore.   Once you update the cert in your OS, you should not have this issue again.   Alternatively, instead of waiting on the OS vendor, you may add the Broadcom CA root cert directly to the OS keystore.
    mitm - view of software update
    Finally, to confirm that there are no more issues, we are reviewing the logs under   /tmp/vmware-USERNAME    {where USERNAME is the non-root or root user, depending when VMware Workstation was executed on the RHEL OS}

    The primary logs of interest are the ones named  "vmware-ui-XXXXXXX.log"

    One remaining error/warning/status message we see is:

    "2024-06-19T20:48:54.000Z In(05) vmui SOCKET 836 (17) AsyncTCPSocketSetOption: Option layer/level [6], option/name [1]: could not set OS option for TCP socket; error [95: Operation not supported]."

    We suspect this could be a simple heart-beat check process that is confused by the underlying guest OS VMware image.   

    Based on review of    

    Alan Baugher