search

mkubecek / vmware-host-modules

Patches needed to build VMware (Player and Workstation) host modules against recent kernels
GNU General Public License v2.0
2.26k stars 362 forks source link

Kernel 6.5-rc - vmmon fails.. #202

Closed ayles2014 closed 11 months ago

ayles2014 commented 1 year ago

Tested with kernel.org Kernel 6.5-rc1 to rc3.. reproduced on different systems, and with standard Fedora39 version of 6.5-rc2.. ............................. LD [M] /tmp/modconfig-Dj3fJq/vmmon-only/vmmon.o MODPOST /tmp/modconfig-Dj3fJq/vmmon-only/Module.symvers ERROR: modpost: "pte_offset_map" [/tmp/modconfig-Dj3fJq/vmmon-only/vmmon.ko] undefined! make[3]: [scripts/Makefile.modpost:144: /tmp/modconfig-Dj3fJq/vmmon-only/Module.symvers] Error 1 make[2]: [/usr/src/linux-6.5-rc3/Makefile:1984: modpost] Error 2 make[1]: *** [Makefile:234: sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-6.5-rc3' make: *** [Makefile:117: vmmon.ko] Error 2

xevilstar commented 1 year ago

confirmed

mkubecek commented 1 year ago

Yes, I'm aware of this. My research so far indicates the whole function using pte_offset_map() should be likely replaced by a call to get_user_pages() or pin_user_pages() or one of their variants (which is what kvm code seems to do for similar purpose). But there are two problems: (1) I'm not very familiar with this API and (2) without the source of the userspace part of the VMware hypervisor, it's unclear if and for what does the userspace code use these PFNs so it's hard to say which variant and which flags would be most appropriate.

xevilstar commented 1 year ago

there's a discussion I found http://rglinuxtech.com/?p=3157 but the proposed patch seems not complete ....

mkubecek commented 1 year ago

Well, pte_offset_kernel() might be a quick workaround, I didn't notice it is still available for modules. But I'll have to check what exactly is the difference and it would need at least a replacement of *pte in the following call to pte_present() the way upstream does in mainline commit c33c794828f2 ("mm: ptep_get() conversion").

xevilstar commented 1 year ago

What I am humbly proposing is ... can you prettypleasewithacherryontop temporarily patch the code the way that the discussion is suggesting while searching for a better way ?

Thank you for your time and effort :)

xevilstar commented 1 year ago

vmmon.patch.txt `— vmware/vmmon-only/include/pgtbl.h 2023-06-30 08:04:13.247729900 +0800 +++ vmware/vmmon-only/include/pgtbl.h 2023-06-30 08:05:41.717728599 +0800 @@ -91,7 +91,7 @@ } else { pte_t *pte;

– pte = pte_offset_map(pmd, addr);

ifdef CONFIG_NET_RADIO

include

`

xevilstar commented 1 year ago

vmmon.tar.zip vmnet.tar.zip Hello,

I have applied the patch manually and it works


root@ghost:~# uname -a
Linux ghost 6.5.0-rc5 #1 SMP PREEMPT_DYNAMIC Wed Aug  9 14:43:13 CEST 2023 x86_64 GNU/Linux
root@ghost:~# lsmod|grep vm
vmw_vsock_vmci_transport    45056  0
vsock                  61440  1 vmw_vsock_vmci_transport
vmnet                  77824  17
vmmon                 163840  1
iwlmvm                589824  0
videobuf2_vmalloc      20480  1 uvcvideo
mac80211             1396736  1 iwlmvm
videobuf2_memops       16384  1 videobuf2_vmalloc
iwlwifi               544768  1 iwlmvm
cfg80211             1339392  3 iwlmvm,iwlwifi,mac80211
vmwgfx                442368  0
videobuf2_common       77824  4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops
rfkill                 40960  10 iwlmvm,asus_wmi,bluetooth,cfg80211
drm_ttm_helper         12288  1 vmwgfx
ttm                   106496  2 vmwgfx,drm_ttm_helper
drm_kms_helper        266240  3 vmwgfx,nvidia_drm,gud
nvme                   57344  5
nvme_core             196608  6 nvme
t10_pi                 20480  2 sd_mod,nvme_core
drm                   765952  19 vmwgfx,drm_kms_helper,drm_shmem_helper,nvidia,drm_ttm_helper,nvidia_drm,ttm,gud
mkubecek commented 1 year ago

First crude attempt: commit b049eda89ec1. Note that I still have only vague idea what the returned PFNs are used for so the get_user_pages flags are quite likely wrong. On the hand, I was able to build and load the module and run a quick test with a VM on top of a 6.5-rc7 kernel so I may be on the right track after all.

TL;DR: use on your risk. :-)

playervalley commented 1 year ago

can confirm this on kernel 6.5.0-1.

xevilstar commented 1 year ago

I got it working with your latest b049eda git no risk involved.

latest mainline 6.5.0 no rc kernel compiled with make -j16 bindeb-pkg Linux ghost 6.5.0 #2 SMP PREEMPT_DYNAMIC Mon Aug 28 12:19:05 CEST 2023 x86_64 GNU/Linux

It was a bit of a hassle to get the latest vmmon-only and vmnet-only workstation-17.0.2-k6.5 If I humbly may it would be easier for me to just have the whole thing with just a git clone (but I am a nobody heheheh)

JoeSalmeri commented 1 year ago

@mkubecek , @xevilstar

FWIW, I just updated one of my opensuse TW test machines to TW build 20230911 and it is using kernel 6.5.2.1 and I'm seeing the same issue.

Here's the compile log in case it has other info that will help:

AppLoader] GLib does not have GSettings support. make: Entering directory '/tmp/modconfig-iPjRpu/vmmon-only' Using kernel build system. /usr/bin/make -C /lib/modules/6.5.2-1-default/build/include/.. M=$PWD SRCROOT=$PWD/. \ MODULEBUILDDIR= modules make[1]: Entering directory '/usr/src/linux-6.5.2-1-obj/x86_64/default' CC [M] /tmp/modconfig-iPjRpu/vmmon-only/linux/driver.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/linux/driverLog.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/linux/hostif.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/apic.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/comport.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/cpuid.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/crosspage.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/memtrack.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/moduleloop.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/phystrack.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/sharedAreaVmmon.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/statVarsVmmon.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/task.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/common/vmx86.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/bootstrap/bootstrap.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/bootstrap/monLoader.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/bootstrap/monLoaderVmmon.o CC [M] /tmp/modconfig-iPjRpu/vmmon-only/bootstrap/vmmblob.o LD [M] /tmp/modconfig-iPjRpu/vmmon-only/vmmon.o MODPOST /tmp/modconfig-iPjRpu/vmmon-only/Module.symvers ERROR: modpost: "pte_offset_map" [/tmp/modconfig-iPjRpu/vmmon-only/vmmon.ko] undefined! make[3]: [/usr/src/linux-6.5.2-1/scripts/Makefile.modpost:150: /tmp/modconfig-iPjRpu/vmmon-only/Module.symvers] Error 1 make[2]: [/usr/src/linux-6.5.2-1/Makefile:2001: modpost] Error 2 make[1]: *** [../../../linux-6.5.2-1/Makefile:234: sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-6.5.2-1-obj/x86_64/default' make: *** [Makefile:117: vmmon.ko] Error 2 make: Leaving directory '/tmp/modconfig-iPjRpu/vmmon-only' make: Entering directory '/tmp/modconfig-iPjRpu/vmnet-only' Using kernel build system. /usr/bin/make -C /lib/modules/6.5.2-1-default/build/include/.. M=$PWD SRCROOT=$PWD/. \ MODULEBUILDDIR= modules make[1]: Entering directory '/usr/src/linux-6.5.2-1-obj/x86_64/default' CC [M] /tmp/modconfig-iPjRpu/vmnet-only/driver.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/hub.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/userif.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/netif.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/bridge.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/procfs.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/smac_compat.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/smac.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/vnetEvent.o CC [M] /tmp/modconfig-iPjRpu/vmnet-only/vnetUserListener.o LD [M] /tmp/modconfig-iPjRpu/vmnet-only/vmnet.o MODPOST /tmp/modconfig-iPjRpu/vmnet-only/Module.symvers CC [M] /tmp/modconfig-iPjRpu/vmnet-only/vmnet.mod.o LD [M] /tmp/modconfig-iPjRpu/vmnet-only/vmnet.ko BTF [M] /tmp/modconfig-iPjRpu/vmnet-only/vmnet.ko Skipping BTF generation for /tmp/modconfig-iPjRpu/vmnet-only/vmnet.ko due to unavailability of vmlinux make[1]: Leaving directory '/usr/src/linux-6.5.2-1-obj/x86_64/default' /usr/bin/make -C $PWD SRCROOT=$PWD/. \ MODULEBUILDDIR= postbuild make[1]: Entering directory '/tmp/modconfig-iPjRpu/vmnet-only' make[1]: 'postbuild' is up to date. make[1]: Leaving directory '/tmp/modconfig-iPjRpu/vmnet-only' cp -f vmnet.ko ./../vmnet.o make: Leaving directory '/tmp/modconfig-iPjRpu/vmnet-only' Unable to install all modules. See log for details.

rgadsdon commented 1 year ago

I had also posted this issue on the VMware Forum for the Tech Preview (W/S 18), and just received the following suggested fix, from comphilip:

In vmmon-only/include/pgtbl.h, replace pte_offset_map with pte_offset_kernel

I have tested this briefly with kernel 6.5 and the Tech Preview, and also with 6.5.3 and 6.6-rc1 and the standard 17.0.2 patchset (not the tmp version) and this compiles OK and seems to work..

mkubecek commented 1 year ago

I really don't like the trick with pte_offset_kernel(), even if I wouldn't be too surprised if it ended up being what VMware comes with later. I guess there is no point waiting any more, I'll add the patch using get_user_pages() to regular branches later today, we can always change it later if any issues are found.

Anthirian commented 12 months ago

I had also posted this issue on the VMware Forum for the Tech Preview (W/S 18), and just received the following suggested fix, from comphilip:

In vmmon-only/include/pgtbl.h, replace pte_offset_map with pte_offset_kernel

I have tested this briefly with kernel 6.5 and the Tech Preview, and also with 6.5.3 and 6.6-rc1 and the standard 17.0.2 patchset (not the tmp version) and this compiles OK and seems to work..

This workaround appears to work for me as well running OpenSUSE Tumbleweed with kernel 6.5.3-1.

jin2w commented 11 months ago

@mkubecek

is it working To apply the patch you provided to the 6.5.0-kali1-amd64 kernel in Python, you can use the following script:

Python import subprocess

def download_patch(): """Downloads the patch file."""

subprocess.run(["wget", "https://raw.githubusercontent.com/vmware/open-vm-tools/main/patches/vmmon-only/include/pgtbl.h.patch"])

def unzip_patch(): """Unzips the patch file."""

subprocess.run(["unzip", "patch_file.patch"])

def apply_patch(): """Applies the patch to the kernel source directory."""

subprocess.run(["patch", "-p1", "<", "patch_file.patch"], cwd="/lib/modules/6.5.0-kali1-amd64/build/")

def compile_kernel(): """Compiles the kernel."""

subprocess.run(["make", "-j", str(subprocess.check_output(["nproc"]).decode("utf-8"))], cwd="/lib/modules/6.5.0-kali1-amd64/build/")

def install_kernel(): """Installs the kernel."""

subprocess.run(["sudo", "make", "modules_install"], cwd="/lib/modules/6.5.0-kali1-amd64/build/") subprocess.run(["sudo", "update-grub"]) subprocess.run(["sudo", "reboot"])

if name == "main": download_patch() unzip_patch() apply_patch() compile_kernel() install_kernel()

josemaX commented 11 months ago

In vmmon-only/include/pgtbl.h, replace pte_offset_map with pte_offset_kernel

This works for me:

Workstation pro 15.5.7 build-17171714 Kernel: 6.5.5-200.fc38.x86_64

Thanks!

l0veormiss commented 11 months ago

This is very good

Workstation pro: 17.0.2 Kernel: Debian 6.5.3-kali

Thanks

chipnetics commented 11 months ago

Wow lots of recent traffic here, just shows how in demand this repo is. Also using the patch at https://github.com/mkubecek/vmware-host-modules/commit/b049eda89ec1245a33c22f5d114f2d0396d5be65 I got it working....

Debian 12 with kernel 6.5.0-1-amd64 using vmplayer 17.0.2

Thanks a lot for maintaining this repository. It would be terrifying to update kernels otherwise.

F423 commented 11 months ago

This works on 6.5.0-kali1-amd64 / Debian 6.5.3-1kali1 Thanks for the legendary repo!

mkubecek commented 11 months ago

Pushed to all active branches, together with some minor hacks for 15.5.7, 14.1.7 and 12.5.9. Everything should build and work up to kernel 6.6-rc3 now. Closing.

Santuccic commented 11 months ago

Confirmed working on physical machine with

Linux fedora 6.5.5-200.fc38.x86_64 Workstation Pro 17.0.2 build-21581411

hwimmer1 commented 11 months ago

Confirmed working on physical machine with

Linux fedora 6.5.5-200.fc38.x86_64 Workstation Pro 17.0.2 build-21581411

So what exactly do I have to do? I follow the normal procedure below, I get the latest from Kube's repo and it didn't work. Could I be getting a wrong version somehow. It seems it would be incorporated into the repo? I am afraid to re-install the 6.5.4 kernel as I have to be able to run VMware...Am I missing something stupid?

  1. download latest from github then follow this

tar -cf vmmon.tar vmmon-only tar -cf vmnet.tar vmnet-only sudo cp -v vmmon.tar vmnet.tar /usr/lib//vmware/modules/source/ sudo vmware-modconfig --console --install-all

Santuccic commented 11 months ago

Confirmed working on physical machine with Linux fedora 6.5.5-200.fc38.x86_64 Workstation Pro 17.0.2 build-21581411

So what exactly do I have to do? I follow the normal procedure below, I get the latest from Kube's repo and it didn't work. Could I be getting a wrong version somehow. It seems it would be incorporated into the repo? I am afraid to re-install the 6.5.4 kernel as I have to be able to run VMware...Am I missing something stupid?

1. download latest from github then follow this

tar -cf vmmon.tar vmmon-only tar -cf vmnet.tar vmnet-only sudo cp -v vmmon.tar vmnet.tar /usr/lib//vmware/modules/source/ sudo vmware-modconfig --console --install-all

you wanna be sure you are not using the previous folder. Basically before to issue the sequence of commands, be sure that the tar you are downloading is the one you are executing, in my case initially i had a previous patch saved as tar, and the one i downloaded called out a "-1" at the end. So verify that in the folder (would be in home) you don't have a previous copy, and after run the command

mkubecek commented 11 months ago

Sometimes you hope to be wrong... this is how VMware addressed the pte_offset_map() issue in Workstation 17.5.0. :-(

Anon-Exploiter commented 10 months ago

Fixes based on the comment: 

cd /tmp
git clone https://github.com/mkubecek/vmware-host-modules
cd vmware-host-modules
git checkout 'tmp/workstation-17.0.2-k6.5' # change the branch name according to your version
make
sudo make install

Using vmware-modconfig

tar -cf vmnet.tar vmnet-only
tar -cf vmmon.tar vmmon-only
sudo mv vmnet.tar /usr/lib/vmware/modules/source/
sudo mv vmmon.tar /usr/lib/vmware/modules/source/
sudo vmware-modconfig --console --install-all

Restart vmware service just in case

sudo /etc/init.d/vmware restart

Now open vmware and it should open normally: 

vmware
hwimmer1 commented 9 months ago

@xevilstar You are a life saver

These zip files saved me! Thank you so much. I would like to ask you how you did this but I can't contact you via github. If you read this can you email me guitarnut at yahoo dot com

I really appreciate this. I don't know why it isn't posted with the original downloads. I downloaded the latest from Kubecek and it still doesn't work. I saw your zip files and downloaded them instead and magically I am back up and running in VMware.

I would like to know how I can avoid this in the future...

ckrath commented 8 months ago

Fixes based on the comment:

cd /tmp
git clone https://github.com/mkubecek/vmware-host-modules
cd vmware-host-modules
git checkout 'tmp/workstation-17.0.2-k6.5'
make
sudo make install

Using vmware-modconfig

tar -cf vmnet.tar vmnet-only
tar -cf vmmon.tar vmmon-only
sudo mv vmnet.tar /usr/lib/vmware/modules/source/
sudo mv vmmon.tar /usr/lib/vmware/modules/source/
sudo vmware-modconfig --console --install-all

Restart vmware service just in case

sudo /etc/init.d/vmware restart

Now open vmware and it should open normally:

vmware

Hey dude... This really worked for me... Only change is git checkout workstation-17.0.2

syslogic commented 3 months ago

@mkubecek This now also fails since roughly kernel 5.14.0-427.16.1.el9_4.x86_64. I just can't tell the exact version number, where it still worked, because I can't downgrade any further. It's just the same, except that it also complains about: CrossPage_CodeEnd(): can't find starting instruction.

make -C vmmon-only 
make[1]: Entering directory 'vmware-host-modules/vmmon-only'
Using kernel build system.
make -C /lib/modules/5.14.0-427.18.1.el9_4.x86_64/build/include/.. M=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[2]: Entering directory '/usr/src/kernels/5.14.0-427.18.1.el9_4.x86_64'
  CC [M]  vmware-host-modules/vmmon-only/linux/driver.o
  CC [M]  vmware-host-modules/vmmon-only/linux/driverLog.o
  CC [M]  vmware-host-modules/vmmon-only/linux/hostif.o
  CC [M]  vmware-host-modules/vmmon-only/common/apic.o
  CC [M]  vmware-host-modules/vmmon-only/common/comport.o
  CC [M]  vmware-host-modules/vmmon-only/common/cpuid.o
  CC [M]  vmware-host-modules/vmmon-only/common/crosspage.o
vmware-host-modules/vmmon-only/common/crosspage.o: warning: objtool: CrossPage_CodeEnd(): can't find starting instruction
  CC [M]  vmware-host-modules/vmmon-only/common/memtrack.o
  CC [M]  vmware-host-modules/vmmon-only/common/moduleloop.o
  CC [M]  vmware-host-modules/vmmon-only/common/phystrack.o
  CC [M]  vmware-host-modules/vmmon-only/common/sharedAreaVmmon.o
  CC [M]  vmware-host-modules/vmmon-only/common/statVarsVmmon.o
  CC [M]  vmware-host-modules/vmmon-only/common/task.o
  CC [M]  vmware-host-modules/vmmon-only/common/vmx86.o
  CC [M]  vmware-host-modules/vmmon-only/bootstrap/bootstrap.o
  CC [M]  vmware-host-modules/vmmon-only/bootstrap/monLoader.o
  CC [M]  vmware-host-modules/vmmon-only/bootstrap/monLoaderVmmon.o
  CC [M]  vmware-host-modules/vmmon-only/bootstrap/vmmblob.o
  LD [M]  vmware-host-modules/vmmon-only/vmmon.o
  MODPOST vmware-host-modules/vmmon-only/Module.symvers
ERROR: modpost: "__pte_offset_map" [vmware-host-modules/vmmon-only/vmmon.ko] undefined!
make[3]: *** [scripts/Makefile.modpost:134: vmware-host-modules/vmmon-only/Module.symvers] Error 1
make[3]: *** Deleting file 'vmware-host-modules/vmmon-only/Module.symvers'
make[2]: *** [Makefile:1848: modules] Error 2
make[2]: Leaving directory '/usr/src/kernels/5.14.0-427.18.1.el9_4.x86_64'
make[1]: *** [Makefile:117: vmmon.ko] Error 2
make[1]: Leaving directory 'vmware-host-modules/vmmon-only'
make: *** [Makefile:21: vmmon-only] Error 2

Just seen, that this had already been reported: issue #244 (duplicate).

Update: It builds with the current kernel 5.14.0-427.22.1.el9_4.x86_64, when changing all the version-checks in vmmon-only/include/pgtbl.h from:

#if COMPAT_LINUX_VERSION_CHECK_LT(6, 5, 0)

to:

#if COMPAT_LINUX_VERSION_CHECK_LT(5, 14, 0)

The result still has warnings:

/vmmon-only/common/crosspage.o: warning: objtool: CrossPage_CodeEnd(): can't find starting instruction
...
Skipping BTF generation for /vmmon-only/vmmon.ko due to unavailability of vmlinux

Also "Could not open /dev/vmmon" ...

hwimmer1 commented 3 months ago

Thank you for the heads up. I will backup my machine and disable updates. When my VMWare goes down I can't do anything. I wish VMWare was more committed to the product but thank god Kukecek has our backs!

On Thu, Jun 6, 2024 at 9:27 AM Martin Zeitler @.***> wrote:

This now also fails with kernel 5.14.0-427.18.1.el9_4.x86_64.

It's just the same, except that it also complains about: CrossPage_CodeEnd(): can't find starting instruction.

make -C vmmon-only make[1]: Entering directory 'vmware-host-modules/vmmon-only' Using kernel build system. make -C /lib/modules/5.14.0-427.18.1.el9_4.x86_64/build/include/.. M=$PWD SRCROOT=$PWD/. \ MODULEBUILDDIR= modules make[2]: Entering directory '/usr/src/kernels/5.14.0-427.18.1.el9_4.x86_64' CC [M] vmware-host-modules/vmmon-only/linux/driver.o CC [M] vmware-host-modules/vmmon-only/linux/driverLog.o CC [M] vmware-host-modules/vmmon-only/linux/hostif.o CC [M] vmware-host-modules/vmmon-only/common/apic.o CC [M] vmware-host-modules/vmmon-only/common/comport.o CC [M] vmware-host-modules/vmmon-only/common/cpuid.o CC [M] vmware-host-modules/vmmon-only/common/crosspage.o vmware-host-modules/vmmon-only/common/crosspage.o: warning: objtool: CrossPage_CodeEnd(): can't find starting instruction CC [M] vmware-host-modules/vmmon-only/common/memtrack.o CC [M] vmware-host-modules/vmmon-only/common/moduleloop.o CC [M] vmware-host-modules/vmmon-only/common/phystrack.o CC [M] vmware-host-modules/vmmon-only/common/sharedAreaVmmon.o CC [M] vmware-host-modules/vmmon-only/common/statVarsVmmon.o CC [M] vmware-host-modules/vmmon-only/common/task.o CC [M] vmware-host-modules/vmmon-only/common/vmx86.o CC [M] vmware-host-modules/vmmon-only/bootstrap/bootstrap.o CC [M] vmware-host-modules/vmmon-only/bootstrap/monLoader.o CC [M] vmware-host-modules/vmmon-only/bootstrap/monLoaderVmmon.o CC [M] vmware-host-modules/vmmon-only/bootstrap/vmmblob.o LD [M] vmware-host-modules/vmmon-only/vmmon.o MODPOST vmware-host-modules/vmmon-only/Module.symvers ERROR: modpost: "__pte_offset_map" [vmware-host-modules/vmmon-only/vmmon.ko] undefined! make[3]: [scripts/Makefile.modpost:134: vmware-host-modules/vmmon-only/Module.symvers] Error 1 make[3]: Deleting file 'vmware-host-modules/vmmon-only/Module.symvers' make[2]: [Makefile:1848: modules] Error 2 make[2]: Leaving directory '/usr/src/kernels/5.14.0-427.18.1.el9_4.x86_64' make[1]: [Makefile:117: vmmon.ko] Error 2 make[1]: Leaving directory 'vmware-host-modules/vmmon-only' make: *** [Makefile:21: vmmon-only] Error 2

— Reply to this email directly, view it on GitHub https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2152492991, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKG7EFF7YW46KMCLE57LMDZGBPUZAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJSGQ4TEOJZGE . You are receiving this because you commented.Message ID: @.***>

syslogic commented 2 months ago

@hwimmer1 Sticking with the currently installed kernel version is probably the least effort, because downgrading all the kernel packages is quite a hassle. The mere problem is, that the RPM repository only holds the last four versions, which means this approach is only temporarily valid: https://unix.stackexchange.com/a/779213/110101

The problem is just, it also happens with 5.14.0-427.16.1.el9_4.x86_64.

hwimmer1 commented 2 months ago

I installed timeshift. Ubuntu forces an update by nagging. In the update I don't usually see something labeled kernel but after the update I'm screwed which is why i installed timeshift. I tested time shift in the research lab but not my production machine. Hopefully i won't have to or kubecek will have a VMware update. I'm seriously considering my next computer to be windows based and run Ubuntu in a VM as opposed to the other way around.

Now that VMware made workstation free I'm assuming we'll see even less support but i don't know what is less than zero and non-negative hahahahaha.

On Sat, Jun 29, 2024, 8:14 AM Martin Zeitler @.***> wrote:

@hwimmer1 https://github.com/hwimmer1 Sticking with the currently installed kernel version is probably the least effort, because downgrading all the kernel packages is quite a hassle: https://unix.stackexchange.com/a/779213/110101

— Reply to this email directly, view it on GitHub https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2198130565, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKG7EET3KWNKY7NENIHOJLZJ2QJVAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGEZTANJWGU . You are receiving this because you were mentioned.Message ID: @.***>

JoeSalmeri commented 2 months ago

Hi Hayden,

Another option you might consider is switching from VMWare to KVM.

I was a long time VMWare user but got tired of the constant issues.

I detailed my journey to switch to KVM in this comment which you might find useful:

https://github.com/mkubecek/vmware-host-modules/issues/228#issuecomment-2101259344

Now several months after that reply, I moved my other VM host machine to KVM and have no plans to go back to vmware even with the new free vmware pro.

Just my $0.02.

Joe

On 6/29/24 10:19 AM, Hayden wrote:

I installed timeshift. Ubuntu forces an update by nagging. In the update I don't usually see something labeled kernel but after the update I'm screwed which is why i installed timeshift. I tested time shift in the research lab but not my production machine. Hopefully i won't have to or kubecek will have a VMware update. I'm seriously considering my next computer to be windows based and run Ubuntu in a VM as opposed to the other way around.

Now that VMware made workstation free I'm assuming we'll see even less support but i don't know what is less than zero and non-negative hahahahaha.

On Sat, Jun 29, 2024, 8:14 AM Martin Zeitler @.***> wrote:

@hwimmer1 https://github.com/hwimmer1 Sticking with the currently installed kernel version is probably the least effort, because downgrading all the kernel packages is quite a hassle: https://unix.stackexchange.com/a/779213/110101

— Reply to this email directly, view it on GitHub

https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2198130565, or unsubscribe

https://github.com/notifications/unsubscribe-auth/ABKG7EET3KWNKY7NENIHOJLZJ2QJVAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGEZTANJWGU . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2198210544, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKAPGF5V7GD4VTBW5JOJDATZJ265RAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGIYTANJUGQ. You are receiving this because you commented.Message ID: @.***>

-- Regards,

Joe

hwimmer1 commented 2 months ago

Joe,.

I'm looking into this. This fall i may get an intern or student worker in my lab to test it out. I tried to move to virtual box but it doesn't have the same networking capabilities as VMware...at least not that I could find. I currently have 8 different VMNets... can i setup multiple networks in kvm?

(Virtual box suffers from some similar issues where an update of Ubuntu breaks it...after an update it was broken and i didn't figure out why).

Thanks for the lead. That is is compatible with VMware (the virtual disk) is important. With the broadcom thing I'm guessing we'll see less support from VMware (not that we got any anyway) and wouldn't be surprised to see the Linux version go away. My next machine will be Windows and I'll VM my Ubuntu instead of the other way around.

On Mon, Jul 8, 2024, 10:36 AM JoeSalmeri @.***> wrote:

Hi Hayden,

Another option you might consider is switching from VMWare to KVM.

I was a long time VMWare user but got tired of the constant issues.

I detailed my journey to switch to KVM in this comment which you might find useful:

https://github.com/mkubecek/vmware-host-modules/issues/228#issuecomment-2101259344

Now several months after that reply, I moved my other VM host machine to KVM and have no plans to go back to vmware even with the new free vmware pro.

Just my $0.02.

Joe

On 6/29/24 10:19 AM, Hayden wrote:

I installed timeshift. Ubuntu forces an update by nagging. In the update I don't usually see something labeled kernel but after the update I'm screwed which is why i installed timeshift. I tested time shift in the research lab but not my production machine. Hopefully i won't have to or kubecek will have a VMware update. I'm seriously considering my next computer to be windows based and run Ubuntu in a VM as opposed to the other way around.

Now that VMware made workstation free I'm assuming we'll see even less support but i don't know what is less than zero and non-negative hahahahaha.

On Sat, Jun 29, 2024, 8:14 AM Martin Zeitler @.***> wrote:

@hwimmer1 https://github.com/hwimmer1 Sticking with the currently installed kernel version is probably the least effort, because downgrading all the kernel packages is quite a hassle: https://unix.stackexchange.com/a/779213/110101

— Reply to this email directly, view it on GitHub

< https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2198130565 , or unsubscribe

< https://github.com/notifications/unsubscribe-auth/ABKG7EET3KWNKY7NENIHOJLZJ2QJVAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGEZTANJWGU

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2198210544>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AKAPGF5V7GD4VTBW5JOJDATZJ265RAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGIYTANJUGQ . You are receiving this because you commented.Message ID: @.***>

-- Regards,

Joe

— Reply to this email directly, view it on GitHub https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2214254529, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKG7ECMT3QVOCNDPXBVIYTZLKPWTAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUGI2TINJSHE . You are receiving this because you were mentioned.Message ID: @.***>

JoeSalmeri commented 2 months ago

@hwimmer1

I also looked at virtual box way back but decided against it.

Yes, you can have multiple different types of networks with KVM.

When I used VMWare I always used Bridged networking because I wanted all my VMs on the same network as the host and everything else.

Out the box, by default KVM uses NAT ( just like VMWare defaults too ).

You can use bridged networking with KVM but you have to manually configure it as it is not a selection like it was in VMWare. There are some basic articles out there which talk about how to do that but it is someone environment specific.

KVM does offer one network option that doesn't appear in the other products which is to setup an Macvtap device for your VM.

Similar to Bridged networking, the vm will appear on the local network and can be accessed by anything there with ONE EXCEPTION.

When using macvtap, communication is not possible via the macvtap device between the HOST and the GUEST vm. As previously mentioned communication between the GUEST vm and OTHER GUEST vms and even other physical machines on the same network is fine, it is just communication between the HOST and guests using macvtap.

macvtap is a simple configuration similar to the checkbox for bridged networking in vmware vs the more complicated ( but possible ) manual setup of bridged networking on the host.

The reason for the limitation between HOST and GUEST using macvtap has to do with how it hooks into the networking stack. There is an article on the libvirt website which talks about that and which also provides a work around.

If you use macvtap and need communication between the HOST and GUEST, then add a second network interface to the GUEST vm ( you can make it an isolated network just for the HOST and GUEST communication ) and then make sure that on the HOST the DNS for those guest machines resolves to the 2nd ip address instead of the first one ( which would be used by all the other guests and physical machines on that network ).

I tried the manual bridge networking setup sometime last year and it worked but I went with macvtap for the simplicity in setup and just added an extra NIC to the guests where I needed HOST and GUEST communications.

If you are cmdline oriented then KVM / QEMU is also nice because you can use the virsh command to do pretty much anything to the guest vm. There is also a service which can be setup which will automatically suspend and resume VMs when the host is shutdown ( which seems to work great ).

Unlike VMware where you have an open window whenever a VM is booted, with KVM you can close the GUEST window and the virtual machine manager window ( list of all vms on the host ) so if you were not careful you might reboot / shutdown the host without doing a proper shutdown of the vms.

I tended to always leave the guest window minimized for my vms so I didn't make the host reboot / shutdown mistake but it is nice and easy to setup that service to protect yourself. Any vms by default that were running when the host is shutdown / rebooted will be restarted with the host and you can also configure vms to always boot when the host boots.

Another really nice feature of Virtual Machine Manager is that you can configure a libvirt connection over SSH to view and/or manage virtual machines which are on a different host machine.

I have a headless server that is running KVM and has multiple vms and I manage those vms from my main desktop.

When I was using vmware after that server went headless that was another issue I needed a solution for because although I could RDP into the headless server ( running openSUSE Tumbleweed ) if you tried to start a vmware guest there it would fail to start because there was no physical display.

KVM does not have that issue and works fine to allow me to remotely connect to and run the VMs located there.

My recommendation would be to copy your VMDK file ( like I did in the other post ) and test things out. That way if you have an issue you can easily boot the vmware vm from the original vmdk file.

If you decide to switch though, I would recommend converting the vmdk files to qcow2 files ( which is trivial using qemu-img convert ).

FWIW, I used Windows since the Windows 3.0 days and spent my working career ( 25 + years ) on very large networks in 1 of 3 main roles, a Database Administrator, Windows Administrator, and software developer ( mainly system / backend programming ).

I originally started with a Windows Host but after building my openSUSE Tumbleweed Linux vm and moving my entire workload ( with 1 exception program ) to that VM it made no sense to me for Windows to be the host anymore.

I now run that 1 exception workload in a Windows 10 VM and I will never go back to Windows full time.

Linux is so much easier to manage and maintain AND some of the decisions MS continues to make with Windows are things that I don't want or desire.

Linux leaves you in control. I cannot tell you how many times I was remotely connected to a customer website doing work that needed to run overnight that I was monitoring where Windows decided that it wanted to install updates and that the time was now outside my normal working ours and decided to install and reboot.

Linux lets me determine when I want to install updates and when I want to reboot my machine.

Just my $0.02 but I'll never go back.

Hope that we helpful !

Joe

hwimmer1 commented 1 month ago

Thank you for the detailed information. I have done some reading and it seems a viable solution. I can't believe i never heard of this product before.

On Sat, Jul 13, 2024 at 4:39 PM JoeSalmeri @.***> wrote:

@hwimmer1 https://github.com/hwimmer1

I also looked at virtual box way back but decided against it.

Yes, you can have multiple different types of networks with KVM.

When I used VMWare I always used Bridged networking because I wanted all my VMs on the same network as the host and everything else.

Out the box, by default KVM uses NAT ( just like VMWare defaults too ).

You can use bridged networking with KVM but you have to manually configure it as it is not a selection like it was in VMWare. There are some basic articles out there which talk about how to do that but it is someone environment specific.

KVM does offer one network option that doesn't appear in the other products which is to setup an Macvtap device for your VM.

Similar to Bridged networking, the vm will appear on the local network and can be accessed by anything there with ONE EXCEPTION.

When using macvtap, communication is not possible via the macvtap device between the HOST and the GUEST vm. As previously mentioned communication between the GUEST vm and OTHER GUEST vms and even other physical machines on the same network is fine, it is just communication between the HOST and guests using macvtap.

macvtap is a simple configuration similar to the checkbox for bridged networking in vmware vs the more complicated ( but possible ) manual setup of bridged networking on the host.

The reason for the limitation between HOST and GUEST using macvtap has to do with how it hooks into the networking stack. There is an article on the libvirt website which talks about that and which also provides a work around.

If you use macvtap and need communication between the HOST and GUEST, then add a second network interface to the GUEST vm ( you can make it an isolated network just for the HOST and GUEST communication ) and then make sure that on the HOST the DNS for those guest machines resolves to the 2nd ip address instead of the first one ( which would be used by all the other guests and physical machines on that network ).

I tried the manual bridge networking setup sometime last year and it worked but I went with macvtap for the simplicity in setup and just added an extra NIC to the guests where I needed HOST and GUEST communications.

If you are cmdline oriented then KVM / QEMU is also nice because you can use the virsh command to do pretty much anything to the guest vm. There is also a service which can be setup which will automatically suspend and resume VMs when the host is shutdown ( which seems to work great ).

Unlike VMware where you have an open window whenever a VM is booted, with KVM you can close the GUEST window and the virtual machine manager window ( list of all vms on the host ) so if you were not careful you might reboot / shutdown the host without doing a proper shutdown of the vms.

I tended to always leave the guest window minimized for my vms so I didn't make the host reboot / shutdown mistake but it is nice and easy to setup that service to protect yourself. Any vms by default that were running when the host is shutdown / rebooted will be restarted with the host and you can also configure vms to always boot when the host boots.

Another really nice feature of Virtual Machine Manager is that you can configure a libvirt connection over SSH to view and/or manage virtual machines which are on a different host machine.

I have a headless server that is running KVM and has multiple vms and I manage those vms from my main desktop.

When I was using vmware after that server went headless that was another issue I needed a solution for because although I could RDP into the headless server ( running openSUSE Tumbleweed ) if you tried to start a vmware guest there it would fail to start because there was no physical display.

KVM does not have that issue and works fine to allow me to remotely connect to and run the VMs located there.

My recommendation would be to copy your VMDK file ( like I did in the other post ) and test things out. That way if you have an issue you can easily boot the vmware vm from the original vmdk file.

If you decide to switch though, I would recommend converting the vmdk files to qcow2 files ( which is trivial using qemu-img convert ).

FWIW, I used Windows since the Windows 3.0 days and spent my working career ( 25 + years ) on very large networks in 1 of 3 main roles, a Database Administrator, Windows Administrator, and software developer ( mainly system / backend programming ).

I originally started with a Windows Host but after building my openSUSE Tumbleweed Linux vm and moving my entire workload ( with 1 exception program ) to that VM it made no sense to me for Windows to be the host anymore.

I now run that 1 exception workload in a Windows 10 VM and I will never go back to Windows full time.

Linux is so much easier to manage and maintain AND some of the decisions MS continues to make with Windows are things that I don't want or desire.

Linux leaves you in control. I cannot tell you how many times I was remotely connected to a customer website doing work that needed to run overnight that I was monitoring where Windows decided that it wanted to install updates and that the time was now outside my normal working ours and decided to install and reboot.

Linux lets me determine when I want to install updates and when I want to reboot my machine.

Just my $0.02 but I'll never go back.

Hope that we helpful !

Joe

— Reply to this email directly, view it on GitHub https://github.com/mkubecek/vmware-host-modules/issues/202#issuecomment-2227098117, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKG7EEYOFOD7JARIPP2FG3ZMGF7BAVCNFSM6AAAAAA222JW3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXGA4TQMJRG4 . You are receiving this because you were mentioned.Message ID: @.***>

JoeSalmeri commented 1 month ago

@hwimmer1

Sure no problem, glad it was helpful. Good luck with your evaluation of KVM.