Hi,

In another thread you're pondering out loud why nobody replies.

Well.. we have not enough data to even start guessing..

For example: define slow... some people think 20 second boots are slow, others will say the same for a 10 second boot.
It is not a very common issue, or it would be reported all over the forum.
Also note that most VMware employees have been on PTO over the past 2 weeks (so the ones that did reply, did so in their spare time)

I was thinking of suggesting to you to turn off memory integrity, but that is only relevant for Windows 10 guests.
You report the problem is with all your VM's, including Windows 7.

How about by starting with a recent vmware.log file from your VM. That might not give a direct hint at what is wrong, but it should at least help us not having to ask a lot of questions about your hardware & VM configuration.

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva

Thanks! This was the first answer in 2 Ubuntu Forums and VMware Forum after a week or so.

You actually gave out relevant information for my tests: a) this IS supposed to be supported (Ubuntu 20.04.1). According to some Google threads, it was unclear and I did specifically ask about this support in my question, b) holiday season is the reason for no answers. Information that this combination IS supported would have helped.

I didn't say it was "slow". I said it is "very very slow and unusable". As a description of events, it is so slow that when selecting a username in Windows login, it doesn't seem to proceed at all.

Based on your answer, I will test with different BIOS setup combinations for virtualization. It's a bit cumbersome, because VM must be killed - no ordinary shutdown is possible because of the slowness - and thus VM can be broken at some point. I will test with Windows 7 VM, which I now use with Windows 10 Host on a (theoretically) identical workstation without any issues.

If I find nothing, I will give you a fresh vmware.log for analysis.

I tried to find something specific in BIOS-settings, but couldn't find anything.

If this is not a common problem, I find it possible that there is something in the workstation that VMware does not understand when running in Ubuntu 20.04.1 (I have not tried now with previous versions of Ubuntu). While this was a fine i7/Asus -computer at the time and is still pretty fast, it is rather old. As stated above, in Windows 10, it runs OK with VMware.

Here is the vmware.log. Mind you that this is a failed attempt to start Windows 7 VM. It took minutes to get into the "background page of Windows start" and then, after another several minutes, there was still no login page for Windows 7.

As stated before, all the other VMs, Win10 and Win7, fresh or old, give a similar issue on Ubuntu 20.04.1 Host. Windows 10 Host works fine in all cases.

Message to add more swap to Linux, I have ignored. RAM is 16 GB and should be enough for everything. Perhaps there is some memory allocation problem in VMware, but I don't know how to solve that. VM is NOT allocated to take too much or too little memory (perhaps under 10 GB currently).

If this is a memory allocation problem, I need advice. I have used VMware Workstation Pro (or Player) for 15+ years on Windows and Ubuntu, and used easily over 100-200 DIFFERENT VMware computers and never had something like this. So this is new to me. I was even able to run a 3D CAD-application with SQL Server on VM on a 1 GB Asus/Linux minicomputer in VMware - it is the only one that was equally slow, but it did work. This, I'm not sure if it even works.

EDIT: In case you are wondering, I did rename username and diskname in the vmware.log.

As mentioned before, in Ubuntu 16.04.1 VMware Player works as it always has worked.

Other tests, on the same computer, mentioned above:

- Linux Mint 20.1. No surprise there, it doesn't work since Mint is based on Ubuntu

- Fedora 33 (latest). It does work as it should for a Win7 VM.

- Fedora 33. With Win10 VM, it seems to work, but at some point hangs the entire computer, not just VM. This may have to do with "memory management", which is mentioned elsewhere for Win10. Also VM-computer BIOS has one more option with the case of Win10. This may be a some kind of a configuration issue.

So, there seems to be something very wrong with VMware Player on Linux. It may be hardware specific, details are presented above in length, or kernel specific or Ubuntu specific. I would have expected that testing of VMware Player/Workstation, involves a fresh Ubuntu install with patches and explicit confirmation where it did work. I have now done 4 different fresh installs for verification. The solution may be a simple prerequisite or configuration issue, which just isn't documented anywhere. With Ubuntu 16.04 and before, there was nothing specific that should have been noted - it worked as expected.

Hi,

Sorry have been busy and while I tend to be rather active at these forums, it still is a volunteer thing, not a paid job, so my apologies for the slow reply.

So you're saying that VMware Player 16.1 works OK on Ubuntu 16.04, but not on any of the later versions of Ubuntu?
That certainly is peculiar and does make me wonder if it is a kernel configuration issue or perhaps a Intel meltdown or Spectre patch in the later versions of ubuntu making things a lot slower.
Also that it seems to work on Fedora 33, until it bumps into a lockup issue.

re. your hardware. You are correct, your CPU is rather old and that might indeed be the main reason.

I was going to look for clues in your attached vmware.log file, but as it was exported to pdf... sorry to say that that made it become unreadable to me, line breaks where they should not be.. sorry.. got a headache after a minute of looking at that.
If you still want me to look at that then you'll have to provide it in the original format (.log aka plain text) and zip it up to attach it here (not sure if the new forum accepts a .log file without zipping it yet)

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva

Thanks for the reply. Yes, log files were not allowed, but I am now attaching a ZIP that has both log files.

You are correct that Ubuntu 16.04 works just fine, but later versions don't. There are new prerequisites, as mentioned previously, for later versions of Ubuntu to even compile VMware Player at the start up, but they don't help.

As for Fedora33 - Win 7 VM has always worked just fine. With later tests, Win 10 VM has also worked - during the first test, I think something unrelated was the reason why it locked up - strange, but I don't think we need to discuss that more because that didn't happen again.

Can anybody verify that this is even supposed to work? Has anybody got Debian-based, new OS version, to work with VMware Player or Workstation? I haven't got any relevant reply to this on any Forum - mutual lack of interest, I suppose. VMware is not interested in various versions of Linux but Windows only and Ubuntu users are not interested in VMware but VirtualBox.

As for the question, "does it work", the requirement is of course a clean version of Debian-based - takes 1 hour to install. At this point, this could be about missing prerequisites.

I can, of course, build new hardware to check, but before I do, I would like to verify that this even can be hardware specific.

Hi,

There are two things in the log file that stand out to me.

First one is that your CPU is a tad old, an intel i7-2600K, is from 2011 and as such does not have the best features anymore for fast VM's. Though while this might make a VM a bit laggy, it should still be usable.

The other thing that stands out to me is that the disk from your host does not appear to be very responsive. There's read actions in there that take almost 30 seconds. That certainly isn't expected.

In your scenario I would test and see if the VM responds better from an external disk (or another disk in your host if it has multiple disks)

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva

Thanks Wila! You were right in drawing the attention to the hard disk. However, it is not that simple - no surprise there, because if it would have been simple, the problem would have been solved, perhaps before logging it in here.

Summary: I now know, what to do, to make it work in Ubuntu 20.04.1. The way is to avoid older technology hard disks and USB-2 interface. As such, these should be avoided in heavy VMware use anyway, but they were expected to work in simple testing. I haven't tested every possible combination, because of the time required. A failing test, often means a broken VM (because any realistic way to stop the test involves "kill process").

Longer reply with some results:

There is nothing wrong in the workstation as such. VMware is not really CPU intensive, but it is disk speed intensive. So, with an older CPU you can achieve good performance, if you just have fast disks. Only using the VM OS for something CPU intensive, requires a fast CPU - VMware itself as a virtualization system, does not need that. To get conflicting results to the above, means bad testing, where you test old workstations with slow disks - you should separate the matters, which really make good or bad performance for VMware.

However, there is something wrong in the way how newer versions of Linux handle old hard disks, as VMware has implemented it. I say Linux, meaning that Debian-based Ubuntu and Fedora 33, both have this problem. I have not verified how it is with Windows 10, but it appears to be OK, since no problems have arisen. This problem is also with USB-2 interface, no matter if the disk is SSD, it is still not possible to use VMware through that interface.

To make the above a bit clearer, let me say what is working OK:

- the hard disk itself does not give any indication of being broken. The basic SMART-test does not give a problem. (This isn't, of course, 100% test, but read forward)

- Ubuntu 16.04.1 does NOT have a problem with the said hard disk in VM (Win7). SAME VM.

- Ubuntu 20.04.1 does NOT have a problem with a new hard disk (6 TB to give an indication of its technology and age). Same VM and also a brand new Win 10 VM, created in that environment (= this 6 TB disk), no problems arise.

- Win7 and Win10 VMs do not seam to make a difference, although virtualization setups in VM, are by default different

So, there is something wrong in the way how VMware handles hard disks in new versions of Ubuntu/Fedora. The problem arises with older hard disks, not with a new technology, 6 TB, hard disk. Whether the underlaying problem is with Linux (kernel), Linux distro or VMware is hard to say, but it has definitely slipped in Certification (or whatever the release tests are called for VMware) of VMware. Since this was already present in Ubuntu version 18.04.1, with an older kernel, this slip has been a continuous one.

There are of course left many question marks for the operability, but I will skip them, because they are not relevant to me, at this point. Things like: USB-3 interface SSD/Nvme H.2 disks, internal SSD-disks, cross-checking with Windows 10 Host with the same HDD, a more exact HDD study, using newer Host hardware, using different SATA-interfaces of the motherboard.

But anyway, thanks a lot for the help!

I did some further testing with hard disks. As said, Ubuntu 16.04.1 didn't have these problems with the same hard disk that Ubuntu 18.04.1/20.04.1 had.

However, this wasn't about hard disk itself. This was about the file system. The problems arise when using NTFS-filesystem. With the normal Ubuntu filesystem, ext4, everything works fine.

I also tested with a SSD-disk connected to USB-3 interface. It works fine and is rather quick, with ext4 filesystem, as it should be. This is important, because that is the way how to use a larger number of VMs on a laptop, where internal disk space is always limited. On a workstation, you have other options.

I cannot speculate where this problem arises: 1. Ubuntu distro (works in 16.04.1, not in later versions), 2. Linux kernel (also Fedora is affected), or 3. VMware implementation (the disk itself works fine with files, copying 110 GB VM works always as expected).

If you have more information, I am interested. As such, this problem is solved for me.