I forgot to note the vm was only set to use 4GB so it should have had plenty of memory available.
If I am reading the vmware.log correctly it appears to show that VMMEM was only able to reserve 1840MB for some reason even though 28056MB was available.
2017-10-03T08:44:34.831-05:00| vmx| I125: OvhdMem_PowerOn: initial admission: paged 460150 nonpaged 5756 anonymous 5155 2017-10-03T08:44:34.831-05:00| vmx| I125: VMMEM: Initial Reservation: 1840MB (MainMem=4096MB)
2017-10-03T08:44:34.831-05:00| vmx| I125: MemSched_PowerOn: balloon minGuestSize 209715 (80% of min required size 262144)
2017-10-03T08:44:34.831-05:00| vmx| I125: MemSched: reserved mem (in MB) min 128 max 28056 recommended 28056
2017-10-03T08:44:34.831-05:00| vmx| I125: MemSched: pg 460150 np 5756 anon 5155 mem 1048576
2017-10-03T08:44:34.831-05:00| vmx| I125: MemSched: numvm 1 locked pages: num 0 max 0
2017-10-03T08:44:34.831-05:00| vmx| I125: MemSched: locked Page Limit: host 0 config 7182336 dynam -1
2017-10-03T08:44:34.831-05:00| vmx| I125: MemSched: minmempct 50 minalloc 0 admitted 0
2017-10-03T08:44:34.831-05:00| vmx| I125: Msg_Post: Error
2017-10-03T08:44:34.831-05:00| vmx| I125: [msg.memsched.preNotEnoughMem] Not enough physical memory is available to power on this virtual machine with its configured settings.
2017-10-03T08:44:34.831-05:00| vmx| I125: [msg.memsched.notEnoughMemHostMemVal] To fix this problem, increase the amount of physical memory for all virtual machines to 2123 MB or adjust the additional memory settings to allow more virtual machine memory to be swapped.
2017-10-03T08:44:34.831-05:00| vmx| I125: [msg.memsched.hostUnderDuress] It is possible that native applications and/or services have locked down memory which could be preventing the virtual machine from launching. Shutting down unnecessary applications or services may free enough memory to launch this virtual machine.
2017-10-03T08:44:34.831-05:00| vmx| I125: [msg.memsched.postNotEnoughMem] If you were able to power on this virtual machine on this host computer in the past, try rebooting the host computer. Rebooting may allow you to use slightly more host memory to run virtual machines.
2017-10-03T08:44:34.831-05:00| vmx| I125: ----------------------------------------
2017-10-03T08:45:09.780-05:00| vmx| I125: Module 'MemSched' power on failed.
Can you please attach a full vmware.log ?
I would like to see the settings you use in /etc/vmware/config
The contents of /etc/vmware/config are the defaults and are as follows:
.encoding = "UTF-8"
VMCI_CONFED = "yes"
NETWORKING = "yes"
initscriptdir = "/etc/init.d"
VMBLOCK_CONFED = "yes"
authd.fullpath = "/usr/sbin/vmware-authd"
gksu.rootMethod = "su"
VSOCK_CONFED = "yes"
libdir = "/usr/lib/vmware"
bindir = "/usr/bin"
vmware.fullpath = "/usr/bin/vmware"
vix.libdir = "/usr/lib/vmware-vix"
installerDefaults.componentDownloadEnabled = "yes"
installerDefaults.autoSoftwareUpdateEnabled.epoch = "8273760757"
vix.config.version = "1"
player.product.version = "14.0.0"
installerDefaults.dataCollectionEnabled.epoch = "5480593862"
installerDefaults.dataCollectionEnabled = "no"
installerDefaults.transferVersion = "1"
installerDefaults.autoSoftwareUpdateEnabled = "yes"
product.buildNumber = "6661328"
authd.client.port = "902"
authd.proxy.nfc = "vmware-hostd:ha-nfc"
product.version = "14.0.0"
workstation.product.version = "14.0.0"
product.name = "VMware Workstation"
Please try to add
prefvmx.allVMMemoryLimit = "20000"
to the config file and restart WS.
That used to work but I cant say if it still works in WS 14
I was looking through old forum posts and noticed other people complained what looks to be similar issues with 12.5.7 and kernel 4.13, which is what I am using (14.0.0 and 4.13). I wonder if its just a partial incompatibility with the new kernel. In the past when Workstation didn't work correctly with the kernel it was much more obvious since the modules wouldn't build and it would complain about that.
In case no one has posted it already, look at the answer under:
arch linux - VMWare Workstation - not enough physical memory since last update - Super User
I've tried it on Fedora 26, VMware Workstation 14 Player, kernel 4.13.4-200.x86_64 and can confirm it works!
Below is what I did based on the above. I hope it helps someone else.
cd /usr/lib/vmware/modules/source
tar xf vmmon.tar
cd vmmon-only/linux
edit vmmon-only/linux/hostif.c
...
#include "versioned_atomic.h"
--- BEGIN ADD ---
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0)
# define global_zone_page_state global_page_state
#endif
static unsigned long get_nr_slab_unreclaimable(void)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 13, 0)
return global_node_page_state(NR_SLAB_UNRECLAIMABLE);
#else
return global_page_state(NR_SLAB_UNRECLAIMABLE);
#endif
}
static unsigned long get_nr_unevictable(void)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0)
return global_node_page_state(NR_UNEVICTABLE);
#else
return global_page_state(NR_UNEVICTABLE);
#endif
}
static unsigned long get_nr_anon_mapped(void)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0)
return global_node_page_state(NR_ANON_MAPPED);
#else
return global_page_state(NR_ANON_PAGES);
#endif
}
--- END ADD ---
...
unsigned int reservedPages = MEMDEFAULTS_MIN_HOST_PAGES;
unsigned int hugePages = (vm == NULL) ? 0 :
BYTES_2_PAGES(vm->memInfo.hugePageBytes);
--- BEGIN REPLACE ---
unsigned int lockedPages = global_page_state(NR_PAGETABLE) +
global_page_state(NR_SLAB_UNRECLAIMABLE) +
global_page_state(NR_UNEVICTABLE) +
hugePages + reservedPages;
unsigned int anonPages =
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0)
global_page_state(NR_ANON_MAPPED);
#else
global_page_state(NR_ANON_PAGES);
#endif
--- WITH ---
unsigned int lockedPages = global_zone_page_state(NR_PAGETABLE) +
get_nr_slab_unreclaimable() +
get_nr_unevictable() +
hugePages + reservedPages;
unsigned int anonPages = get_nr_anon_mapped();
--- END REPLACE ---
cd ../..
tar cf vmmon.tar vmmon-only
rm -rf vmmon-only # cleanup
# Lastly, we need to rebuild the patched module
sudo vmware-modconfig --console --install-all
Your solution works!
I urge the support of vmware to share this info on their technical solutions for problems.
I'm confident alot of people (at least Fedora 26 with the latest kernel) run into issues because of this 'memory' bug
@vmware-support: Please build a patch for it! Thanks in advance.
Again: Thank you @chrislovessoccer
Good! Solved my problems with Workstation 14.0 on Ubuntu 17.10 (4.13.0 kernel) host. Thanks!
Also works for 4.13.9, thank you very much!
Please, tell me in detail how to fix this error? I have Ubuntu 17.10 x64. I did everything under this instruction, which is placed above, it is impossible to start the virtual machine.
Worked like a charm for me. (Debian 4.13.0-kali1-amd64)
You're a genius!
Thanks
This fixed my issue on Linux Mint 18.x using Kernel 4.13.x with Workstation Pro 14.0
In case no one has posted it already, look at the answer under:
arch linux - VMWare Workstation - not enough physical memory since last update - Super User
I've tried it on Fedora 26, VMware Workstation 14 Player, kernel 4.13.4-200.x86_64 and can confirm it works!
Thanks chrislovessoccer
This is wonderful! Thanks!
Using Ubuntu 17.10 kernel 4.13.0-16-generic x86_64
VMware Workstation 14.0.0
This was super! Thanks!
I had issues with Player V12 after updating my kernel to 4.14 (Ubuntu). I installed Player V14 but still had issues building VMMON and followed guidance in Kernel – 4.14-rc1 Released – Breaks VMware and NVIDIA.. GPL Errors Again.. | Adventures With Linux ™ to replace all instances of 'global_page_state’ with ‘global_numa_state’ in hostif.c. The build worked but starting a Win10 instance failed because I had not enabled virtualization support in the AMD processor (although previous versions worked without it enabled) - this was quickly resolved but then starting the VM got this physical memory error. Making the changes described here restored a working VMWare.
In my view, Win10 is now running CONSIDERABLY faster (due to AMD virtualization enable in BIOS or due to code improvements in VMWare?) and my CPU monitor shows a HUGE improvement (drop in usage).
Great response, your fix worked for my situation.
Linux 4.13.0-kali1-amd64 #1 SMP Debian 4.13.4-2kali1 (2017-10-16) x86_64 GNU/Linux
VMware Workstation 14
That tip worked for me. Ubuntu 17.10, with VMware Workstation 12.5.8
I can confirm that this solution also was required for:
Host: Ubuntu 16.04 LTS running kernel 4.13.0-26
Workstation v12.5.9
Applying the patch manually as described worked great, thanks!