Hi
VMWare states Workstation Pro is compatible with any versions of Ubuntu hosts above 14.04 version but 20.04 version being just released does it work well on it without any problems ? out of the existing crash bug when you suspend a guest system (problem i have already in ubuntu 18.04).
Someone has been able to test Workstation Pro on Ubuntu 20.04 ?
Thanks
Vincèn
Yes, it doesn't support it. Ubuntu 20.04 was literally just released. Give it some time.
Give it some Time ? it has been in beta during months so developpers could adapt/check their apps are compatible with that new version ! Very disappointed to see that VMWare is not ready for that yet All the more with the very confusing statement on their website indicating that Workstation is compatible with all ubuntu versions above 14.04......
Don't know what to tell you. I don't make the product nor do I work for VMware. If you want an official response, open a ticket.
The detailed list of supported host OSes: VMware Knowledge Base
Thanks for the list that confirms VWWare use (removed by moderator) marketing verbiage on its main website stating all versions from ... are supported ! First software manufacturer that uses such non-sense verbiage !
Looks like we'll have to wait that VMWare discovers that Ubuntu 20.04 has been released and support it....
GM - I upgraded my PopOS to 20.04 this morning and now I cannot open Workstation Pro. It tells me I need to compile and load into the kernel several modules. The modules are vmmon and vmnet. They crash with the following error message unable to install all modules. see log/tmp/.... I guess I should have waited to upgrade
Hello from another update victim. I was very surprised if my VMware WS14 runs unter Ubuntu LTS 20.04 well after automatically compiling the mention modules 'vmmon' and 'vmnet'. But only until the Ubuntu-Updater install Kernel 5.4.x-xx, under this Kernel the compiling of 'vmnet' fails.
Kernel 5.3. x-xx works, 5.4 no longer because apparently some libraries in 5.4 changed which will use for 'vmnet' compiling.
Temporary work-around for me if I must use VMware, select in Grub the older Kernel or change to VortualBox. Maybe it helps.
Greets Ulrich
2020-05-14 21:58 Update
Solved !
I used the actual module releases from mkubecek at Github.com for my enviroment --> Release w14.1.7-k5.5: vmnet: work around skb_frag_t build failure for SLE15-SP2 and openSUS… · mkube...
Copy this module tarballs as mention in older work arounds and now vmware ws14.1.7 runs. Maybe this information helps for other installations.
Greets Ulrich
Briefly: I installed VMWare Workstation Pro 15.5 in Ubuntu 20.04LTS in late March. Both Ubuntu and VMWare are clean installs on a 2016 Dell Inspiron 15-3567 that came with Windows 10. I tried Windows 10, really. No go - separate topic.
So far I have the following issues:
1) Cannot install VMWare Tools in DOS 6.2.2 and Windows 95. I think these are old issues. The last report I've found of successful installation in Windows 95 required Workstation virtual machine 4, which is not offered in Workstation 15.5. I did try with the oldest virtual machine listed - V5.x - but without success - it still reports "SETUP caused an exception c06d007fH in module KERNEL32.DLL at 0137Lbff9a07c.
2) After considerable work, was able to provide the sound driver /dev/dsp to guest DOS 6.2.2, but VMWare cannot open it - reports an I/O error
3) Although the Dell and Ubuntu 20.04 supports 3d Graphics, according to glxinfo and glxgears, no guest OS does. I have installed (multiple times) VMWare tools in Windows XP Pro and WIndows 7 Pro, and have enabled 3D support for Direct X on both guests. Hardware acceleration yes - 3D no.
I plan to collect logs to open a case with VMWare, starting with issue (3) since that one relates to my reason for getting Workstation in the first place.
I can try to answer the VMware Tools and sound parts of your post.
I don't think we have ever provided VMware Tools for MS-DOS.
We do have VMware Tools for Win95 and it theoretically should work, but Win9x is not renowned for its general stability... Failures installing system software were regrettably commonplace. I have managed to get it to install recently, but success probably depends on the precise version/update of Win95 in use.
For the sound problem... I have been working on improving our sound support in legacy OSes (Sound Blaster 16 on VMware Workstation 15.5 and VMware Fusion 11.5) so if your virtual machine is configured with a Sound Blaster 16 (i.e. sound.virtualDev = "sb16" in its .vmx file) you might be able to use the instructions in the linked document to enable sound on your Ubuntu 20.04 LTS host. If your VM is configured with an Ensoniq ES1371 (sound.virtualDev is absent or set to "es1371"), it should end up using ALSA support (rather than OSS via /dev/dsp). (I am working on upgrading that virtual device as well... but we are not there yet.)
Thanks,
--
Darius
Darius,
Thanks so much for your response.
Your article is one of those I researched while bird-dogging the sound issue in DOS. So far I am using just the GUI to configure guest hosts - and the DOS guest gui did not offer ALSA drivers as an option. I had to run down OSS emulation packages in Ubuntu to even define a /dev/dsp there. But you've given me more things to try - thanks for that.
For now I will be focusing on the 3d graphics issue - didn't see that one coming since the guest installs seemed to be going well up to that point.
One step at a time . . .
Best regards,
Bob
Well, I did check a bit on the DOS sound issue. Collected the following bits, in case they afford any illumination:
=======> DOS 6.2.2 startup config <=========
Rem DOS 6.2.2 - config.sys
DEVICE=C:\DOS\SETVER.EXE
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\NEC_IDE.SYS /D OEMCD001
DOS=HIGH
FILES=60
BUFFERS=20,0
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /p
DEVICE=C:\SB16\DRV\CTSB16.SYS /UNIT=0 /BLASTER=A:220 I:5 D:1 H:7
DEVICE=C:\SB16\DRV\CTMMSYS.SYS
Rem - autoexec.bat
@ECHO OFF
SET BLASTER=A220 I5 D1 H7 P330 T6
C:\DOS\SMARTDRV.EXE
MSCDEX.EXE /D:OEMCD001 /L:D
PROMPT $p$g
PATH C:\DOS
SET TEMP=C:\DOS
SET SOUND=C:\SB16
C:\SB16\DIAGNOSE /S
C:\SB16\MIXERSET /P
=======> Find “sound” in MS-DOS.vmx: <=========
sound.autoDetect = "TRUE"
sound.virtualDev = "sb16"
sound.present = "TRUE"
=======> Find “sound” in vmware.log: <=========
2020-05-16T13:04:59.940-04:00| vmx| I125: DICT sound.autoDetect = "TRUE"
2020-05-16T13:04:59.940-04:00| vmx| I125: DICT sound.virtualDev = "sb16"
2020-05-16T13:04:59.940-04:00| vmx| I125: DICT sound.present = "TRUE"
. . .
2020-05-16T13:04:59.940-04:00| vmx| I125: DICT tag.soundConfig = "devices_sound.htm"
. . .
2020-05-16T13:04:59.973-04:00| vmx| I125: SOUNDLIB: SoundLib_CreatePulseBackend: waiting for connection to Pulse server
. . .
2020-05-16T13:05:00.255-04:00| vcpu-0| W115: SB16 doesn't have ALSA sound support. Falling back to OSS: /dev/dsp.
2020-05-16T13:05:00.255-04:00| vcpu-0| I125: Opening sound device for the first time.
2020-05-16T13:05:00.263-04:00| vcpu-0| I125: Opened (maybe) sound device for the first time.
2020-05-16T13:05:00.263-04:00| vcpu-0| I125: Msg_Post: Warning
2020-05-16T13:05:00.263-04:00| vcpu-0| I125: [msg.sound.dspopen] /dev/dsp: Input/output error.
2020-05-16T13:05:00.263-04:00| vcpu-0| I125: [msg.device.startdisconnected] Virtual device 'sound' will start disconnected.
Yeah, starting from that configuration, if you set sound.opl3.enabled = TRUE in your .vmx file, your SB16 will magically acquire compatibility with host ALSA and host PulseAudio, and should no longer attempt to use the ridiculously-outdated OSS Open Sound System support. Everything else there looks fine although it's been a while since I poked around the innards of configuring the MS-DOS SB16 support drivers. All the ports/IRQs/DMAs look correct. :smileycool:
Let me know if that helps!
--
Darius
I had the same issue and resolved it by upgrading Workstation Pro to version 15.5.2.
Darius,
I don't find my email response in the thread - not sure why. But yes - inserting sound.opl3.enabled = TRUE does indeed enable DOS to connect to the host audio.
Thanks again for your help.
Best regards,
Bob Kelly
When did you update?
From my DOS log:
2020-05-16T18:30:39.427-04:00| vmx| I125: Log for VMware Workstation pid=60045 version=15.5.2 build=build-15785246 option=Release
When I request updates, no new updates are found.
So, Looking through the log for one of the guests that fails to recognize 3d graphics - Windows 7 in this instance - I found the following gem:
2020-05-17T02:00:34.137-04:00| mks| I125: GLHostX11: DISPLAY: ":0" has a blacklisted driver.
2020-05-17T02:00:34.137-04:00| mks| I125: GLHostX11: GLX ClientString: Mesa Project and SGI
2020-05-17T02:00:34.137-04:00| mks| I125: GLHostX11: Disabling 3D on this display due to presence of an unsupported graphics driver.
2020-05-17T02:00:34.137-04:00| mks| I125: GLHostX11: Set the config option mks.gl.allowBlacklistedDrivers=TRUE to override.
I inserted
mks.gl.allowBlacklistedDrivers=TRUE
in the .vmx file, started Windows 7, and now dxdiag reports all accelerations enabled - including 3d graphics.
It's a good first step, but now I need to research why VMware blacklisted Mesa Project and SGI, do I now have a stable host, what alternative driver may be preferred, etc. etc. etc.
Also, apropos of the original post, is this driver part of the Ubuntu 20.04 build or did I bring it in when chasing OSS sound emulation for DOS.
I'll try to post updates as the research unfolds.
25 May, 2020
I'm ready to close out my contribution to this thread.
I don't believe my experience with Workstation Pro 15 greatly illuminates the issue of compatibility with Ubuntu 20.04. It installs ok, and accepts guest OS's ok, The issues I encountered are particular to my hardware, and may not relate to the original poster's question. In particular, the sound driver issue for DOS likely exists in prior Workstation releases as well. Hopefully the fix provided by Darius will be offered as an explicit option in future releases. The graphics issue very much appears to be a pissing contest between the Mesa Project SGI and VMware developers. My test case is Syberia. With the blacklist overridden, guest Windows XP allowed Syberia to install and play. But one wouldn't want to. The mouse left trails, and scene changes failed as often as they succeeded. On the other hand, the same Syberia binaries installed in Crossover - so using the native host graphics drivers - work very well. So, not a host graphics issue.
Since I made only clean installs, those upgrading may encounter very different issues. Those with different hardware the same.
So from my viewpoint, the question remains - "it depends!"
I have been using 15.5.5 under Ubuntu 20.04 since 15.5.5 came out. I didn't have to do anything special, just a basic installation.
The following KB article says "yes", and is datestamped for last update as of today. Not sure to see when it was originally posted/created.
I feel your pain, though, since
- the WS Pro 16 docs point to the VMware Compatibility Guide online (but provide no link in the _online_ doc),
- the Comp Guide points to an old KB article for v11 and older,
- then it took some effort in searching to find the v12.x-15.5 KB article, which
- (finally) has a link to this v16 KB article.
NO reason this information should be so hard to get.
RMW