nice to see you here - how are things going at bootland ?
it would help to see the vmware.log of that VM that feels so slow
We are working intensely as usual at the www.reboot.pro . Virtualization technology is very helpful to me on this subject. And I always use the vmware program. Because it is very usefull than other software. But there is a problem with the new version of the vmware. And I do not understand why this stems. The pc system is becoming like remain motionless to a period of time. Even the display adapter and the sound card is disabled for a moment. System is normalized by bios screen of the vmware later. This problem sometimes can take 15-30 second in time to first start. This problem can be annoying to people like me. I mean, I know you understand me very well. Therefore, I think may be the solution to the log file for the problem. So I would like it to share with you. I hope
Thank you in advance for your help and solution ways. Kind regards
Have a look at your config.ini in
installerDefaults.autoSoftwareUpdateEnabled = "yes"
installerDefaults.componentDownloadEnabled = "yes"
installerDefaults.dataCollectionEnabled = "yes"
This settings will result in a delay at startup - set those to "no"
Please let me know if that fixes it
I read your post again ...
The suggestion from last post only fixes delays at startup of Workstation.
It does not fix lags during regular use.
Unfortunately I see no hints in the log you attached because that VM was only in use fora very short time.
Please attach logs from VMs that were busy for longer time periods.
Please dont archive the logs - attach them as they are - makes reading them easier
Hi again continuum
Hmm. I do not think it would be a solution. The problem may be much deeper. I did a video shoot. But it is not so good quality. So I hope you forgive me for that. Best regards
ah - you mean THAT problem.
This type of problems exist since version 8.
They are tricky to fix as the issues dont happen all the times and the behaviour is pretty inconsistent.
I learned how to work around it most of the times - but explaining how to do so will need a longer howto ...
Give me some time - I sum it up for you
the problems you see were introduced with WS 8.
With WS 8 I have seen suspend or shutdown times of a VM upto one hour myself.
Many other users reported similar problems.
We have discussed this in many posts and found no way to work around it in a reliable way.
Up to version 7 we had tweaks to tune the behaviour of Workstation in two directions:
- run a few VMs with optimized performance
- run many VMs
This tweaks no longer produce predictable results in version 8 or 9.
Users of powerful hosts occasionally have to use tweaks to allow the usage of more than 1/3 or 1/4 of the available RAM.
That never was necessary on older versions.true
On a Windows host tweaking the general behaviour is done in the config.ini
To run one or two VMs with best performance we would use:
prefvmx.useRecommendedLockedMemSize = "true"
prefvmx.minVmMemPct = "100"
mainmem.useNamedFile = "false"
To run many VMs or allow to assign more virtual RAM than your host has we would use:
prefvmx.useRecommendedLockedMemSize = "FALSE"
prefvmx.minVmMemPct = "0"
mainmem.useNamedFile = "true"
Since version 8 this tweaks no longer produce predictable results so you have to test yourself what works best in your case.
Also check if
mainMem.writeZeros = "TRUE"
mainMem.writeZeros = "false"
Check whether the vmem-file inside the VM-directory is highly fragemented.
I have seen this since version 8.
Either defragment the vmem-files regularly or test if
mainmem.useNamedFile = "false"
gives you better results
Since version 8 I use the following pre-cautions to avoid these lags:
avoid using very large growing vmdks - with very large I mean larger than 950 Gb.
avoid using vmdks stored on eSATA drives - this may produce surprisingly slow results
avoid starting / suspending / resuming / stopping more than one VM at the same time - allow 5 minutes or more between such operations
never try to suspend a VM that is busy - allow at least 5 minutes of being idle before you suspend it
defragment the drives where you store your VMs as often as possible
shrink your VMs regularly
do not allow Antivirus-tools to scan vmdks
avoid using more than 2 vCPUs per VM
do not assign too much RAM to VMs
Honestly I must say that this tweaks and avoiding strategy does not always work.
I had to kill WS 9 a few times my self.
If you need a reliable workhorse for developing LiveCDs and do not need Windows 8 as a guest I would even suggest to use the latest WS 7 release.
My impression is that WS 9 was rushed out of the door so we hopefully see improvements and fixes in the next version
Hmm. Your descriptions and guidelines are very nice. I've tried them all. But the result has not changed. Interesting, but I am not encountering the same problem at the Windows 7 x64 Edition. I've reinstalled the windows 7 32-bit ultimate operating system. But the result has not changed. I thought the physical memory can not be used in full by the 32-bit operation system. So I installed the Windows 2008 Server Enterprise 32-bit Edition. Bucause it supports the 64 GB physical memory. But the result has not changed.
But it was a topic that caught my attention. The vmware workstation 9 does not create the *.vmem file at the windows 7 64-bit edition. But I do not think it would cause a problem, though. So I think the problem stems from the program entirely. Even more weird side of problem, didn't nobody live with this problem like me ?